SQL Injection/Insertion, Jak zapobiec włamaniu na stronę. |
SQL Injection/Insertion, Jak zapobiec włamaniu na stronę. |
4.02.2010, 23:38:51
Post
#261
|
|
Grupa: Zarejestrowani Postów: 28 Pomógł: 4 Dołączył: 13.11.2009 Ostrzeżenie: (0%) |
1 obraz > 1000 słów
Przykładowe użycie:
jak ktoś to shakuje to wysyłam mu Moet! |
|
|
13.02.2010, 12:28:23
Post
#262
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
Kod http://strona.pl?video_id=-1 UNION SELECT username,password FROM users LIMIT 1 Wyślij mi Moet, cokolwiek to jest. Ten post edytował pyro 13.02.2010, 12:30:17 -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
24.02.2010, 14:37:34
Post
#263
|
|
Grupa: Zarejestrowani Postów: 260 Pomógł: 34 Dołączył: 22.02.2010 Ostrzeżenie: (0%) |
Kod http://strona.pl?video_id=-1 UNION SELECT username,password FROM users LIMIT 1 Wyślij mi Moet, cokolwiek to jest. podwarunkiem ze tablea users istnieje o polach username, password a co bys zrobils jak by sie okazalo ze hasla trzymane sa w innej bazie o glupiej nazwie z glupia kolmna?? wiec w obrebie polaczenia tego zapytania wyzej byc nic nie uzyskal.. a przy logowaniu leci POST a nie GET plus ta funkcja co pisal kolega do filtrowania danych |
|
|
24.02.2010, 14:39:55
Post
#264
|
|
Grupa: Moderatorzy Postów: 36 457 Pomógł: 6297 Dołączył: 27.12.2004 |
Cytat podwarunkiem ze tablea users istnieje o polach username, password Jakie istnieją tabele i jakie mają kolumny też bez problemu dzieki tej dziurze można wykryc... wystarczy ze ktos umozliwia dziure i juz jestesmy w domu.
-------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
24.02.2010, 14:48:58
Post
#265
|
|
Grupa: Zarejestrowani Postów: 305 Pomógł: 25 Dołączył: 27.01.2007 Ostrzeżenie: (0%) |
podwarunkiem ze tablea users istnieje o polach username, password a co bys zrobils jak by sie okazalo ze hasla trzymane sa w innej bazie o glupiej nazwie z glupia kolmna? ? wiec w obrebie polaczenia tego zapytania wyzej byc nic nie uzyskal.. Skoro dziurawy skrypt otrzymuje dane to i haker dostałby te dane. Nie musi znać dokładnej struktury tabeli - może działać metodą prób i błędów. To zadanie można też zautomatyzować i myślę, że osoby bawiące się w tych tematach takowe już posiadają |
|
|
24.02.2010, 14:57:42
Post
#266
|
|
Grupa: Zarejestrowani Postów: 260 Pomógł: 34 Dołączył: 22.02.2010 Ostrzeżenie: (0%) |
Dodajac replace na UNION + kilka innych , ustalenie jakie tabele i kolumny jest raczej bardzo trudne
do tego mozna zrobic tak jak mowilem zeby trzymac hasla i uzytkownikow i pare innych poufnych danych w innej bazie to daje tyle ze w obrebie poruszanaia sie po serwisie operujemy tylko na danych wyswietlanych a nie poufnych... chyba ze mozna to obejsc ja nie wiem jak.. wydaje mi sie byc to dobrym pomyslem Oczywiscie ze dla hakera nie ma rzeczy nie mozliwych, tylko ze wtedy nie ma tak latwo Nie jestem expertem.. sam chce sie w miare dobrze przed tym zabiezpieczyc Ten post edytował wiiir 24.02.2010, 15:00:39 |
|
|
24.02.2010, 15:29:50
Post
#267
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
podwarunkiem ze tablea users istnieje o polach username, password a przy logowaniu leci POST a nie GET plus ta funkcja co pisal kolega do filtrowania danych Drogi @wiiir, podane tabele to były najzwyklejsze przykłady, mogłem równie dobrze też napisać tabele asfjaiofjadfo oraz asjfhkjasdkjas. Też byś wtedy napisał `wątpię, żeby jakiś serwis miał pola i tabele o takich nazwach`? A czy według Ciebie SQL Injection może mieć miejsce tylko w skrypcie logowania? Jak taki błąd ma miejsce na przykład w newsach na tej samej stronie to mogę tak samo z tego miejsca wyciągnąć nazwy użytkowników i ich hasła Cytat(wiiir) wiec w obrebie polaczenia tego zapytania wyzej byc nic nie uzyskal.. Nie warto się zastanawiać, co mógłby zrobić potencjalny włamywacz w związku z istniejącym błędem. Ważne, żeby zadbać o to, żeby go nie było. -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
24.02.2010, 15:51:48
Post
#268
|
|
Grupa: Zarejestrowani Postów: 260 Pomógł: 34 Dołączył: 22.02.2010 Ostrzeżenie: (0%) |
jakis bys napisal ze masz nazwy takich tabl i kolumn to bym sie nie zdzwil bo ja czesto stosuje cos takiego.. moze nie taki random jak podales.. albo cos podobnego, wiem ze odpowiesz ze jest to do ustalenia.. .ale osoba ktora pisze sobie taki skrypty zazwyczaj stosuje standardowe nazwy tabel ktore znajdzie w tutakach, a hakerowi to jest nareke, inne nazwy rozne prefixy itd daja tyle ze juz trzeba cos zrobic wiecej ..
Wiadomo ze w pierwszej kolejnosci nalezy zabiezpieczyc skrypt pod w zgledem otrzymywanych danych.. ale wiadomo ze o czyms mozna zapomniec.. a sam id uzytkownika tez duzo nie daje takie dane mozna z cockie zebrac, a zeby odnalesc haslo musisz zainicjowac nowe polaczenie do drugiej bazy, zeby to zrobic trzeba byc juz naprawde niezlym gosciem To o logowaniu to tak na marginesie bo tam jest popelniany 1 blad Temat ten mozna by cignac w nieskonczonosc a i tak znalazby sie haker ktory by znalazl dziurke |
|
|
24.02.2010, 16:15:38
Post
#269
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
jakis bys napisal ze masz nazwy takich tabl i kolumn to bym sie nie zdzwil bo ja czesto stosuje cos takiego.. moze nie taki random jak podales.. albo cos podobnego, wiem ze odpowiesz ze jest to do ustalenia.. .ale osoba ktora pisze sobie taki skrypty zazwyczaj stosuje standardowe nazwy tabel ktore znajdzie w tutakach, a hakerowi to jest nareke, inne nazwy rozne prefixy itd daja tyle ze juz trzeba cos zrobic wiecej .. trudniejsze czy nie, to generalnie kwestia czasu, po prostu nie można sobie pozwolić na to, żeby taka miała miejsce Wiadomo ze w pierwszej kolejnosci nalezy zabiezpieczyc skrypt pod w zgledem otrzymywanych danych.. ale wiadomo ze o czyms mozna zapomniec.. a sam id uzytkownika tez duzo nie daje takie dane mozna z cockie zebrac, a zeby odnalesc haslo musisz zainicjowac nowe polaczenie do drugiej bazy, zeby to zrobic trzeba byc juz naprawde niezlym gosciem Pisze się w cookies. No, chyba że sugerujesz, że ludzie przetrzymują nazwy użytkowników w kutaskach . Niestety takie rozwiązanie mogłoby być uciążliwe dla damskiej części użytkowników. Bardzo rzadko id użytkownika przetrzymuje się w cookies. A żeby nawet go wyciągnąc stamtąd, trzeba by było znaleźć inną lukę (XSS). To o logowaniu to tak na marginesie bo tam jest popelniany 1 blad No to równie dobrze mogłeś napisać coś o hardware, bo to również wiąże się z komputerami, na których się pisze kod. Temat ten mozna by cignac w nieskonczonosc a i tak znalazby sie haker ktory by znalazl dziurke To zdanie jest również (według mnie) fałszywe. Można pisać tak, żeby nie popełniać błędów. -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
24.02.2010, 16:47:36
Post
#270
|
|
Grupa: Zarejestrowani Postów: 260 Pomógł: 34 Dołączył: 22.02.2010 Ostrzeżenie: (0%) |
trudniejsze czy nie, to generalnie kwestia czasu, po prostu nie można sobie pozwolić na to, żeby taka miała miejsce czasami wlasnie ten czas dziala na twoja korzysc oznacza to im dluzej ktos prubuje wlamac tym masz lepsze zabezpieczenia Pisze się w cookies. No, chyba że sugerujesz, że ludzie przetrzymują nazwy użytkowników w kutaskach . Niestety takie rozwiązanie mogłoby być uciążliwe dla damskiej części użytkowników. Bardzo rzadko id użytkownika przetrzymuje się w cookies. A żeby nawet go wyciągnąc stamtąd, trzeba by było znaleźć inną lukę (XSS). Moze sie i pisze ale widzialem ludzi ktorzy trzymaja hasla i w sesji jak i w cookie To zdanie jest również (według mnie) fałszywe. Można pisać tak, żeby nie popełniać błędów. Nie jestes w stanie tak napisac kodu zeby nie popelnic bledu. Inaczej nie bylo by wlamow do najwikszych instytucji Polsce i na swiecie. |
|
|
24.02.2010, 17:21:59
Post
#271
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
Cytat Nie jestes w stanie tak napisac kodu zeby nie popelnic bledu. Jest, jest. Na świecie powstaje cała masa bezpiecznego (w pełni) kodu. Problemy pojawiają się przy pisaniu skomplikowanych programów/skryptów jak i przy wykorzystywaniu oprogramowania firm trzecich - co jest właściwie... nieuniknione.Ale napisanie programu/skryptu do którego nie da się włamać bezpośrednio jest możliwe. Ten post edytował Crozin 24.02.2010, 17:22:29 |
|
|
24.02.2010, 23:11:24
Post
#272
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
czasami wlasnie ten czas dziala na twoja korzysc oznacza to im dluzej ktos prubuje wlamac tym masz lepsze zabezpieczenia Niestety ten czas niewiele działa na korzyść, bo prędzej czy później minie Lepsze zabezpieczenia? Na litość boską, to wcale nie znaczy o lepszych zabezpieczeniach. Nie jestes w stanie tak napisac kodu zeby nie popelnic bledu. Inaczej nie bylo by wlamow do najwikszych instytucji Polsce i na swiecie. Zaryzykuje to stwierdzenie, ale jestem. A już przynajmniej od strony SQL Injection, o którym jest temat. Ten post edytował pyro 24.02.2010, 23:13:45 -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
25.02.2010, 08:34:14
Post
#273
|
|
Grupa: Zarejestrowani Postów: 260 Pomógł: 34 Dołączył: 22.02.2010 Ostrzeżenie: (0%) |
Niestety ten czas niewiele działa na korzyść, bo prędzej czy później minie Do tego mnie nie przekonasz, porownanie np: bo przeciez to ze nie miales wypadku nie oznacza ze kiedys i tak bedziesz "musial" miec, no i wcale nie musisz a mozesz tak samo z wlamem moze byc taka sytuacja ze jest dziura, ale koles probuje probuje i nic az wkoncu daje sobie spokuj.. Ucieklismy od temau ups Tak ogolnie patrzac na twoje stwierdzenie zrob nam dekalog dobrego zabezpieczenia SQL Injection ktore stosujesz Ten post edytował wiiir 25.02.2010, 08:57:16 |
|
|
25.02.2010, 08:46:38
Post
#274
|
|
Grupa: Zarejestrowani Postów: 305 Pomógł: 25 Dołączył: 27.01.2007 Ostrzeżenie: (0%) |
Tak ogolnie patrzac na twoje stwierdzenie zrob nam dekalog dobrego zabezpieczenia SQL Injection ktore stosujesz http://php.net/manual/en/pdo.prepare.php To powinno załatwić sprawę. |
|
|
25.02.2010, 10:25:02
Post
#275
|
|
Grupa: Zarejestrowani Postów: 300 Pomógł: 32 Dołączył: 31.07.2006 Ostrzeżenie: (0%) |
Dodajac replace na UNION + kilka innych , ustalenie jakie tabele i kolumny jest raczej bardzo trudne Podałbym przykład jak ominąć takie pseudozabezpieczenie w postacie replace ale podejrzewam, że zacząłbyś po prostu dokładać kolejne warunki brnąc w ślepą uliczkę. Nazwy tabel i pól można pobierać zwykłymi zapytaniami, przecież większość ORMów właśnie to robi nie mówiąc o np. phpMyAdminie. |
|
|
25.02.2010, 20:48:47
Post
#276
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
Dodajac replace na UNION + kilka innych Oczywiście... w JPortalu już czegoś takiego próbowali i miałem dzięki temu dużo "zabawy" . -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
1.03.2010, 23:04:44
Post
#277
|
|
Grupa: Zarejestrowani Postów: 28 Pomógł: 4 Dołączył: 13.11.2009 Ostrzeżenie: (0%) |
@pyro
szampan się nie należy! zmodyfikowałeś mój kod, tworząc lukę ( zlikwidowałeś cudzysłów ), więc shakowałeś swój kod, mój pozostał nietknięty Kto następny? |
|
|
1.03.2010, 23:33:47
Post
#278
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
@aio: Traktowanie liczb jako tekstu (tj.: id = "123", zamiast normalnego id = 123) jest brzydkim/złym zwyczajem - chociaż w tym przypadku (o ile wszędzie wszystkie dane traktowałbyś jako tekst) ratuje Cię to przed potencjalnym atakiem.
|
|
|
2.03.2010, 00:12:13
Post
#279
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
@pyro szampan się nie należy! zmodyfikowałeś mój kod, tworząc lukę ( zlikwidowałeś cudzysłów ), więc shakowałeś swój kod, mój pozostał nietknięty Kto następny? Ale co Ty w takim razie chciałeś zrobić? Pokazać jak napisałeś dwie linijki kodu, których nie da się tknąć? Zobacz o czym jest wątek. Jest on o zabezpieczaniu przed SQL Injection/Insertion, a nie o zabezpieczaniu jednego, konkretnego, prostego zapytania. Z Twojego posta można było jedynie wywnioskować, że odkryłeś "cudowną funkcję", która zabezpiecza przed SQL Injection. Niestety NIEWIELE ona zabezpiecza i ktoś posługując się nią prawdopodobnie miałby luki w swoim serwisie/stronie. To co napisałeś nie rozwiązuje nawet w połowie zagrożenia SQL Injection. Jestem niemal pewien, że nawet jakbyś teraz rozbudował te "logowanie" o parę linijek kodu do rejestracji, to już by była podatna na atak. A wino mi się w takim razie należy chociażby za Twojego nic nie wnoszącego do tematu posta Ten post edytował pyro 2.03.2010, 00:13:28 -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
2.03.2010, 11:58:22
Post
#280
|
|
Grupa: Zarejestrowani Postów: 28 Pomógł: 4 Dołączył: 13.11.2009 Ostrzeżenie: (0%) |
Ale co Ty w takim razie chciałeś zrobić? Pokazać jak napisałeś dwie linijki kodu, których nie da się tknąć? Zobacz o czym jest wątek. Jest on o zabezpieczaniu przed SQL Injection/Insertion, a nie o zabezpieczaniu jednego, konkretnego, prostego zapytania. Z Twojego posta można było jedynie wywnioskować, że odkryłeś "cudowną funkcję", która zabezpiecza przed SQL Injection. Niestety NIEWIELE ona zabezpiecza i ktoś posługując się nią prawdopodobnie miałby luki w swoim serwisie/stronie. To co napisałeś nie rozwiązuje nawet w połowie zagrożenia SQL Injection. Jestem niemal pewien, że nawet jakbyś teraz rozbudował te "logowanie" o parę linijek kodu do rejestracji, to już by była podatna na atak. A wino mi się w takim razie należy chociażby za Twojego nic nie wnoszącego do tematu posta Chyba się nie rozumiemy. Nie chodziło mi o atak literacki mnie na forum! Na serwerze jako haker, jesteś w stanie tknąć kod? Nie! Hakujesz wejściem poprzez REQUEST! Zrozumiałem że o tym mowa w tym wątku, nieprawdaż? Utwórz taki REQUEST (_GET), żeby shakować mój kod. Nie chcę być niegrzeczny ale czy nie mam przypadkiem racji? Czy uważasz, że Twój post cokolwiek wniósł? Pozdrawiam @aio: Traktowanie liczb jako tekstu (tj.: id = "123", zamiast normalnego id = 123) jest brzydkim/złym zwyczajem - chociaż w tym przypadku (o ile wszędzie wszystkie dane traktowałbyś jako tekst) ratuje Cię to przed potencjalnym atakiem. Do enginu mysqla wysyłasz String. 123 przy parsowaniu jest konwertowane na Number. Tak samo '123' będzie konwertowane do Number, z tą zaletą że poprzez szybszy natywny engine mysql i tylko JEDEN raz, a nie dodatkowe linijki kodu php z większym ryzykiem popełnienia błędu. Jakaż jest przewaga (np wydajności) skryptu z uprzednią konwersją na Number, skoro trzeba przewidzieć i dopisać ochronę w innych przypadkach? Czy zatem jest coś brzydszego od konwertowania po kilka razy tej samej wartości w kółko na dziesięć sposobów rzekomo utrudniających atak? . Że typ String jest brzydki jako taki? To jest ten argument? I najważniejsze, bo może nie doczytałem czegoś, ten wątek jest o utrudnianiu czy ułatwianiu rozwiązania zagadnienia? Np. kolega wyżej zamiast dokonać włamu, opracował lukę i dumnie obwieścił, że udowodnił, że się umie włamać - SIC! PS. Wiem, że wyżej gdzieś ktoś pisał, że jak podamy liczbę jako String, to ma wpływ na performance, ale chyba się zgodzimy wszyscy, że nie dotyczy to tego przypadku? Pozdrawiam |
|
|
Wersja Lo-Fi | Aktualny czas: 28.04.2024 - 03:33 |