Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

22 Stron V  < 1 2 3 4 5 > »   
Reply to this topicStart new topic
> SQL Injection/Insertion, Jak zapobiec włamaniu na stronę.
Jarod
post 8.05.2005, 19:08:08
Post #41





Grupa: Zarejestrowani
Postów: 1 190
Pomógł: 27
Dołączył: 23.04.2005

Ostrzeżenie: (0%)
-----


Cytat(Peter Riley @ 2005-05-08 17:43:03)
oczywiscie pozostaje sprawdzenie czy nadeslane dane mieszcza sie w dozwolonym zakresie, ale to juz inna historia.

Możesz rozwinąć?


--------------------
”Godzina nauki w życiu nowoczesnego apostoła jest godziną modlitwy.”
(św. Josemaría Escrivá, Droga, 335)
Go to the top of the page
+Quote Post
Peter Riley
post 8.05.2005, 19:47:55
Post #42





Grupa: Zarejestrowani
Postów: 18
Pomógł: 0
Dołączył: 7.05.2005

Ostrzeżenie: (0%)
-----


Cytat(J4r0d @ 2005-05-08 18:08:08)
Cytat(Peter Riley @ 2005-05-08 17:43:03)
oczywiscie pozostaje sprawdzenie czy nadeslane dane mieszcza sie w dozwolonym zakresie, ale to juz inna historia.

Możesz rozwinąć?

Po prostu musimy sprawdzic, czy przeslane wartosci maja odpowiedni przedzial, czyli np. wpisana ilosc sztuk nie przekracza stanu magazynu. W przypadku wartosci tekstowych mozna porownac wyszukac ciagu w zadeklarowanej wczesniej tablicy lub uzyc switch of. Jednak to wszystko nie ma nic wspolnego ze sql injection, przed ktorym pelna obrone zapewnia defaultowa konfguracja php, a jesli wylaczymy magic quote, pozostanie addslashes.
Go to the top of the page
+Quote Post
sobstel
post 8.05.2005, 22:14:33
Post #43





Grupa: Zarejestrowani
Postów: 853
Pomógł: 25
Dołączył: 27.08.2003
Skąd: Katowice

Ostrzeżenie: (0%)
-----


Cytat(Peter Riley @ 2005-05-08 18:43:03)
addslash lub magic quote zalatwia calkowicie sprawe sql injection

smiem twierdzic ze jest to zbyt odwazne stwierdzenie. wyobraz sobie taka sytuace :

URL: www.strona.php?articleid=12
filtrujemy: $id = addslashes($_GET['articleid'])
wstawiamy w zapytanie : query = 'SELECT * FROM articles WHERE id='.$id;

i teraz np. URL www.strona.php?articleid=12 OR 1

jak widzisz w tym przykladzie (co prawda dosc naiwnym) addslashes nie zalatwilo sprawy...


--------------------
"If debugging is the process of removing bugs, then programming must be the process of putting them in..."
sobstel.org
Go to the top of the page
+Quote Post
Kinool
post 9.05.2005, 00:14:50
Post #44





Grupa: Zarejestrowani
Postów: 560
Pomógł: 0
Dołączył: 15.07.2003
Skąd: Kwidzyn

Ostrzeżenie: (0%)
-----


panowie!!!!

juz ktos pisal o tym ze wiemy co "spodziewamy" sie otrzymac jesli chodzi o liczby to nie addslashes tylko intval() lub settype()

$id = intval($_GET['articleid']);

i jesli gosc wklepie tam cokolwiek to i tak bedzie zutowane na liczbe
nawet ze wzglegow optymalizacji lepiej jest wykonac zapytanie
SELECT * FROM table WHERE id=10
niz
SELECT * FROM table WHERE id='10'
poniewaz MySQL nie musi robic konwersji

addslashes uzywamy jesli mamy doczynienia z wartosciami textowymi lub mieszanymi

tak na marginesie to zadna funkcja nie zwalnia od myslenia!

Ten post edytował Kinool 9.05.2005, 00:20:28


--------------------
Go to the top of the page
+Quote Post
Peter Riley
post 9.05.2005, 01:28:44
Post #45





Grupa: Zarejestrowani
Postów: 18
Pomógł: 0
Dołączył: 7.05.2005

Ostrzeżenie: (0%)
-----


Cytat(sopel @ 2005-05-08 21:14:33)
smiem twierdzic ze jest to zbyt odwazne stwierdzenie.

To chyba oczywiste, ze musimy sprawdzic czy liczby rzeczywiscie sa liczbami, przy okazji sprawdzajac ich zakres. Zreszta pisalem o tym wyzej. Dodam tylko, ze ja sklaniam sie raczej do sprawdzania typu, a nie konwersji na sile. Jesli typ sie nie zgadza, to mail do admina i die().

Nie jest to odwazne stwierdzenie tylko fakt. Zaloze sie, ze ci co usuwaja UNION i sredniki z ciagow, na wszelki wypadek klikaja "zastosuj" w windowsowych okienkach tuz przed kliknieciem "ok" :-)

Ten post edytował Peter Riley 9.05.2005, 01:32:48
Go to the top of the page
+Quote Post
ktuvok
post 14.05.2005, 20:58:57
Post #46





Grupa: Zarejestrowani
Postów: 243
Pomógł: 0
Dołączył: 30.11.2003

Ostrzeżenie: (0%)
-----


Dorzucę się do tego wątku i powiem, że moim zdaniem najlepszym zabezpieczeniem jest:

1. ustawienie w php.ini opcji get_magic_quotes_gpc na ON

2. stosowana równolegle z powyższym funkcja czyszcząca otrzymane dane - od razu uprzedzam, że wbrew nazwie nie dotyczy ona tylko danych przesyłanych metodą POST:
  1. <?php
  2.  
  3. function OczyscPost($Zmienna, $Rozmiar)
  4. {
  5. {
  6. $Zmienna = stripslashes($Zmienna);
  7. }
  8. $Zmienna = trim(strip_tags(str_replace(&#092;"\"\", \"\", $Zmienna)));
  9. $Zmienna = substr(str_replace(&#092;"'\",\"\", $Zmienna),0,$Rozmiar);
  10. $Zmienna = sprintf(&#092;"%s\",$Zmienna);
  11. return $Zmienna;
  12. }
  13.  
  14. ?>


3. Funkcja zapewniająca dodatkowe filtrowanie dla identyfikatorów, przekazywanych w URL'u:
  1. <?php
  2.  
  3. function DoCyfry($Zmienna)
  4. {
  5. $Zmienna = intval($Zmienna);
  6. if(is_int($Zmienna))
  7. {
  8. return $Zmienna;
  9. }
  10. else
  11. {
  12. return 0;
  13. }
  14. }
  15.  
  16. ?>


Zastosowanie:
  1. <?php
  2.  
  3. $Nazwisko = OczyscPost($_POST['Nazwisko'], 40);
  4. $ID = DoCyfry(OczyscPost($_GET['ID'], 10));
  5.  
  6. ?>


Jakieś uwagi?

Pozdrawiam,
K
Go to the top of the page
+Quote Post
Vengeance
post 14.05.2005, 21:44:37
Post #47





Grupa: Zarejestrowani
Postów: 657
Pomógł: 2
Dołączył: 15.08.2003
Skąd: Łódź

Ostrzeżenie: (0%)
-----


Cytat(Peter Riley @ 2005-05-08 19:43:03)
Cytat(J4r0d @ 2005-05-08 16:56:50)
Bezpieczeństwo - szkoda czasu?  worriedsmiley.gif  Nie dla mnie :roll2:

A co z bezpieczenstwem ma wspolnego kasowanie ciagow typu UNION ze zmiennej, w ktorej i tak kazdy apostrof zostanie wysleszowany? Nic.
addslash lub magic quote zalatwia calkowicie sprawe sql injection, oczywiscie pozostaje sprawdzenie czy nadeslane dane mieszcza sie w dozwolonym zakresie, ale to juz inna historia.

Hyh... kompletnie się z Tobą nie zgodzę :]

Union da się wiele razy wykorzystać nie stosując nawet jednego apostrofu!
Więc samo używanie addslashes() w przypadku posiadania MySQL 4 nie jest bezpieczne !


--------------------
Go to the top of the page
+Quote Post
bolas
post 16.05.2005, 23:02:57
Post #48





Grupa: Zarejestrowani
Postów: 8
Pomógł: 0
Dołączył: 10.10.2004

Ostrzeżenie: (0%)
-----


a takie pytanko jeszcze.
czy umozliwienie stosowania wszystkich znakow np. spacji przy tworzeniu loginu podczas rejestracji jest niebezpieczne ?
Go to the top of the page
+Quote Post
bolas
post 18.05.2005, 14:56:35
Post #49





Grupa: Zarejestrowani
Postów: 8
Pomógł: 0
Dołączył: 10.10.2004

Ostrzeżenie: (0%)
-----


wszystkie znaki - oczywiscie przy wlaczanej dyrektywie gpc_magic_quotes

ktuvok - uzywam podobnego mechanizmu i na razie nie ma problemow (moze dlatego, ze nikt nie robil testow, albo nie zauwazono, ze cos jest nie tak). dodatkowo uzywam htmlspecialchars.

Ten post edytował bolas 18.05.2005, 14:58:44
Go to the top of the page
+Quote Post
kubatron
post 22.05.2005, 10:18:04
Post #50





Grupa: Zarejestrowani
Postów: 581
Pomógł: 0
Dołączył: 21.07.2003
Skąd: Jasło

Ostrzeżenie: (0%)
-----


Nie wiem czy był dawany ten link lecz jeśli nie to prosze o usunięcie postu, a takto ciekawy art do przeczytanie http://www.computerworld.pl/artykuly/31505.html


--------------------
„Człowiek jest wielki nie przez to, co posiada, lecz przez to, kim jest;
nie przez to, co ma, lecz przez to, czym dzieli się z innymi.”
Jan Paweł II
Go to the top of the page
+Quote Post
gu35t
post 29.06.2005, 19:08:01
Post #51





Grupa: Zarejestrowani
Postów: 57
Pomógł: 0
Dołączył: 15.05.2005

Ostrzeżenie: (0%)
-----


mozna sie legalnie sprawdzic:
http://peanix.ath.cx/

wiecej na:
http://forum.cc-team.org/viewtopic.php?t=6488
http://forum.cc-team.org/viewtopic.php?t=6680

sqli[taki bylejaki winksmiley.jpg]:
http://sld.org.pl/index.php?view=1&art_id=...et_id=16&rsid=4

i troche info:
http://www.microsoft.com/poland/technet/article/art008.mspx
http://www.unixwiz.net/techtips/sql-injection.html
http://www.google.pl/search?hl=pl&biw=1019...btnG=Szukaj&lr=
http://www.sitepoint.com/article/sql-injection-attacks-safe
http://www.securiteam.com/securityreviews/5DP0N1P76E.html
http://www.google.pl/search?hl=pl&biw=1019...btnG=Szukaj&lr=
http://www.google.pl/search?hl=pl&biw=1019...btnG=Szukaj&lr=
http://www.google.pl/search?hl=pl&biw=1019...btnG=Szukaj&lr=
http://www.google.pl/search?hl=pl&biw=1019...btnG=Szukaj&lr=
http://blogs.wdevs.com/colinangusmackay/ar.../09/25/652.aspx

troche o union:
http://www.really-fine.com/SQL_union.html

a tak wogule to wszystko na google jest tylko miej troche cierpliowsci i MYSL.

pozdro
Cytat
Union da się wiele razy wykorzystać nie stosując nawet jednego apostrofu!
Więc samo używanie addslashes() w przypadku posiadania MySQL 4 nie jest bezpieczne !

prawda vee smile.gif


--------------------
env: Linux Slackware 10.1 [Kernel 2.6.5], PHP 4.3.9, Apache 1.3.33.
Go to the top of the page
+Quote Post
logeen
post 6.07.2005, 13:03:21
Post #52





Grupa: Zarejestrowani
Postów: 8
Pomógł: 0
Dołączył: 6.07.2005

Ostrzeżenie: (0%)
-----


Cytat(Vengeance @ 2005-05-14 20:44:37)
Union da się wiele razy wykorzystać nie stosując nawet jednego apostrofu!
Więc samo używanie addslashes() w przypadku posiadania MySQL 4 nie jest bezpieczne !

Mam w takim razie pytanko: w jaki sposób wykonać SQL Injection w takim skrypcie:
  1. <?php
  2. // Łączenie z serwerem MySQL itd.
  3.  
  4. // Logowanie administratora:
  5. mysql_query('SELECT * FROM admins WHERE user_login = '' . (get_magic_quotes_gpc() ? $_POST['login'] : addslashes($_POST['login'])) . '' AND user_password = '' . (get_magic_quotes_gpc() ? $_POST['password'] : addslashes($_POST['password'])) . ''');
  6.  
  7. // Zmiana hasła:
  8. mysql_query('UPDATE users SET user_password = '' . (get_magic_quotes_gpc() ? $_POST['password'] : addslashes($_POST['password'])) . '' WHERE user_id = ' . abs(intval($_GET['user_id'])));
  9.  
  10. // Albo:
  11. mysql_query('UPDATE users SET user_password = '' . (get_magic_quotes_gpc() ? $_POST['password'] : addslashes($_POST['password'])) . '' WHERE user_login = '' . (get_magic_quotes_gpc() ? $_GET['login'] : addslashes($_GET['login'])) . ''');
  12.  
  13. // Operacje końcowe: zamykanie połączenia itd.
  14. ?>

Jakoś nie widzę tutaj możliwości wykorzystania UNION poprzez SQL Injection dry.gif

Ten post edytował logeen 6.07.2005, 14:32:51
Go to the top of the page
+Quote Post
Vengeance
post 7.07.2005, 19:53:24
Post #53





Grupa: Zarejestrowani
Postów: 657
Pomógł: 2
Dołączył: 15.08.2003
Skąd: Łódź

Ostrzeżenie: (0%)
-----


Wiadomym jest, że nie w każdym się da... ale są przypadki gdzie tak jest. Przecież w UNION najczęściej chodzi o wyciągnięcie danych... więc nie musisz używać apostrofu. Gdy ktoś zrobi błąd w takim miejscu, iż użycie apostrofu nie jest wymagane (a najczęściej jest właśnie tylko w dyrektywach WHERE) to droga otwarta.


--------------------
Go to the top of the page
+Quote Post
johnson
post 7.07.2005, 20:04:31
Post #54





Grupa: Zarejestrowani
Postów: 90
Pomógł: 2
Dołączył: 3.12.2004

Ostrzeżenie: (0%)
-----


Nie zapominajmy, że przy union włamywacz musi znać nazwę tabeli i pól w tabeli mysql, a w przypadku, jeśli ktoś pisze skrypty sam i nie używa gotowców, prawdopodobieństwo, że włamywacz odgadnie nazwę tabeli i pola jest IMHO bardzo małe.
Go to the top of the page
+Quote Post
Vengeance
post 7.07.2005, 20:07:40
Post #55





Grupa: Zarejestrowani
Postów: 657
Pomógł: 2
Dołączył: 15.08.2003
Skąd: Łódź

Ostrzeżenie: (0%)
-----


IMHO pokaz mi programiste co nie trzyma loginow i hasel w tabeli nazwą zblizonej do 'users' :]

Pozatym... wywolujac kontrolowane bledy SQL mozna czesto poznac spora czesc struktury bazy SQL.

Ale ogólnie to masz racje snitch.gif


--------------------
Go to the top of the page
+Quote Post
logeen
post 7.07.2005, 21:03:48
Post #56





Grupa: Zarejestrowani
Postów: 8
Pomógł: 0
Dołączył: 6.07.2005

Ostrzeżenie: (0%)
-----


Cytat(Vengeance @ 2005-07-07 18:53:24)
Gdy ktoś zrobi błąd w takim miejscu, iż użycie apostrofu nie jest wymagane (a najczęściej jest właśnie tylko w dyrektywach WHERE) to droga otwarta.

Tutaj się zgodzę, ale powiedzcie mi w takim razie, po co sztucznie wywalać UNION ze wszystkich danych podstawianych do zapytania, jeżeli można je tak zabezpieczyć, że nigdy nie będzie możliwości wykonania SQL injection (np. tak jak zaprezentowałem powyżej)? Czy to nie jest paranoja? Gdyby programiści IPB byli tak na to wyczuleni, to na tym forum w treści postów w ogóle nie dałoby się wpisać słowa "UNION" i jeszcze kilku innych, a jak widać da się smile.gif
Go to the top of the page
+Quote Post
Vengeance
post 7.07.2005, 23:35:32
Post #57





Grupa: Zarejestrowani
Postów: 657
Pomógł: 2
Dołączył: 15.08.2003
Skąd: Łódź

Ostrzeżenie: (0%)
-----


Dlatego, że w takim forum wykonuje się masę zapytań i nie zawsze wszystkie 100% sprawdzisz. Więc lepiej w jednym miejscu filtrować niebezpieczne dane... by potem mieć pewność że do każdego zapytania dotrą w odpowiedniej formie... i że nie zapomnieliśmy gdzieś czegoś filtrować.


--------------------
Go to the top of the page
+Quote Post
logeen
post 8.07.2005, 01:01:33
Post #58





Grupa: Zarejestrowani
Postów: 8
Pomógł: 0
Dołączył: 6.07.2005

Ostrzeżenie: (0%)
-----


To jasne, ale zależy, co rozumiesz przez "filtrować". Jeżeli filtrowaniem nazywamy np. używanie funkcji "addslashes" czy "intval", to OK. Ale jeżeli to ma polegać na bezcelowym usuwaniu np. wszystkich wystąpień słowa "UNION" i innych podobnych z danych przesyłanych przez użytkownika, a podstawianych do zapytania, to ja tego nie rozumiem. Po co to usuwać, skoro i tak w żaden sposób nie może zaszkodzić, jeżeli odpowiednio przefiltrujemy dane? Na dodatek przez takie postępowanie zupełnie niepotrzebnie eliminujemy sobie możliwość wstawienia do bazy danych niektórych słów, co może być akurat potrzebne. Spróbujcie napisać np. tutorial używania unii w SQL, jeżeli z każdego tekstu wstawianego do bazy będziecie czyścić to słowo ;-)

Jak ktoś nie filtruje danych, to i tak żadne usuwanie "UNION" itp. mu nie pomoże, bo SQL injection można wykonać na wiele innych sposobów, kiedy nie przefiltrujemy danych wejściowych...
Go to the top of the page
+Quote Post
Vengeance
post 8.07.2005, 01:16:42
Post #59





Grupa: Zarejestrowani
Postów: 657
Pomógł: 2
Dołączył: 15.08.2003
Skąd: Łódź

Ostrzeżenie: (0%)
-----


1. A kto mówi że strona musi traktować o czymś gdzie wystąpi UNION.
2. Zobacz ile skryptów (np. phpbb) jest podatnych na tego typu ataki


--------------------
Go to the top of the page
+Quote Post
logeen
post 8.07.2005, 02:34:26
Post #60





Grupa: Zarejestrowani
Postów: 8
Pomógł: 0
Dołączył: 6.07.2005

Ostrzeżenie: (0%)
-----


ad.1) Czyli co? Jeżeli zamierzasz zbudować np. forum dyskusyjne przeznaczone do dyskusji na temat języka SQL, to nie będzie się go dało zabezpieczyć, bo w takim przypadku usuwanie "UNION" z treści wysyłanych postów jest absolutnie nie do przyjęcia, a tylko to dałoby wystarczające zabezpieczenie?

ad.2) Skrypty są podatne, ponieważ programiści zapomnieli przefiltrować dane. Gdyby to zrobili, to by nie były podatne. Usuwanie "UNION" tutaj nic nie zmieni, ponieważ jeżeli dane wejściowe potraktujemy odpowiednio "addslashes" czy "intval", to żadne "UNION" przemycone w treści nam nie zaszkodzi. Do tego właśnie zmierzało moje pytanie, na które do tej pory nikt nie odpowiedział jasno i wyraźnie: czy jeśli stosujemy odpowiednią filtrację danych (np. taką jak zaprezentowałem), to wstawienie przez użytkownika "UNION" w danych wejściowych może się źle skończyć?
Go to the top of the page
+Quote Post

22 Stron V  < 1 2 3 4 5 > » 
Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 19.08.2019 - 07:29