SQL Injection/Insertion, Jak zapobiec włamaniu na stronę. Opcje

[pyro]

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ł?

Nie, nie masz racji, nie o tym jest temat . Moje posty o tyle wnoszą do tematu, że starają się skorygować Twoje .

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!

Właśnie chodzi o to, że nie ułatwiłeś rozwiązania zagadnienia, a jedynie pominąłeś jego większą część. Teraz jak ktoś wejdzie w temat i popatrzy sobie na Twój post(y), to może sobie pomyśleć, że w ten sposób należy zabezpieczać się przed SQL Injection. Przez to potem będzie miał w swojej aplikacji zjawisko zwane "serem szwajcarskim".

[aio]

Nie, nie masz racji, nie o tym jest temat . Moje posty o tyle wnoszą do tematu, że starają się skorygować Twoje .



Właśnie chodzi o to, że nie ułatwiłeś rozwiązania zagadnienia, a jedynie pominąłeś jego większą część. Teraz jak ktoś wejdzie w temat i popatrzy sobie na Twój post(y), to może sobie pomyśleć, że w ten sposób należy zabezpieczać się przed SQL Injection. Przez to potem będzie miał w swojej aplikacji zjawisko zwane "serem szwajcarskim".

OK, skoro nie przekonują Cię moje argumenty, pomińmy więc proszę polemikę ad persona. Możesz podać przykład SQL Injection włamującego się do mojego kodu, bez literackich spostrzeżeń a propos mojej osoby?

PS.
To tak jakbym zaprojektował i zbudował drewniany most i orzekł, że możecie wszyscy wejść na niego a się nie zawali. Na to pyro, zamiast wejść i skakać i kopać po moście, buduję swój most obok, na pierwszy rzut oka podobny, wchodzi na niego a ten się wali. Mam nadzieję, że analogia jest czytelna.

Podobnego porównania można użyć jeśli chodzi o używanie String, jako zagadnienienia estetycznego. To tak jakby twierdzić, że ponieważ na elementy rozciągane najlepiej nadaje się stalowa lina, a na elementy ściskane (lepiej od liny) drewno, zatem most w całości wykonany z drewna musi być brzydki, będąc wynikiem złej praktyki budowlanej. Mam nadzieję, że ta analogia zadziała z mocą supernowej pośród przepastnego odmętu wszechświata

@pyro
Konkludując i w odwecie polemizując z pyro, proszę o wejście na mój most i zburzenie go, a nie udowadnianie, że gdzieś, kiedyś widziano most, który się zawalił To simple to prove it?

Pozdrawiam

[Crozin]

No przecież już dostałeś przykład:

[PHP] pobierz, plaintext 
$sql = "SELECT * FROM video WHERE id = $id;";
[PHP] pobierz, plaintext 

Gdzie $id to zmienna przefiltrowana Twoim sposobem. Konieczność pamiętania by każdorazowo (nawet tam gdzie jest to po prostu pozbawione sensu) ..."$id"... jest największą wadą Twojego rozwiązania.

[pyro]

Ehh... no to dwie rzeczy:

1. Wskaż mi choć jedno miejsce, w którym piszę coś propo Twojej persony. Nawiązuję jedynie do Twoich postów, a nie Ciebie.

2. Skoro już zaczęliśmy się bawić w opowiadanie historyjek, to ja opowiem prawdziwą:

Przedstawiłeś się jako konstruktor mostów. Masz swoje narzędzie - młotek firmy `aoi` (którym w tym wypadku jest podana przez Ciebie funkcja). Udało Ci się zbudować stabilny most na betonowym podłożu (którym w tym wypadku jest podane zapytanie). Teraz inni budowniczy (forumowicze) użyją tego młotka, żeby zbudować swoje mosty, ale zbudują je na przykład na piaszczystym, czy też bagnistym podłożu i będą wadliwe, przy skakaniu zawalą się. Twoja rola jako twórcy odpowiedniego młotka do budowy mostów nie powiodła się.

Prościej już nie wiem jak Ci to wytłumaczyć.

[aio]

No przecież już dostałeś przykład:

[PHP] pobierz, plaintext 
$sql = "SELECT * FROM video WHERE id = $id;";
[PHP] pobierz, plaintext 

Gdzie $id to zmienna przefiltrowana Twoim sposobem. Konieczność pamiętania by każdorazowo (nawet tam gdzie jest to po prostu pozbawione sensu) ..."$id"... jest największą wadą Twojego rozwiązania.

Nie no super, nie wiedziałem, że SQL Injection polega na umieszczaniu dowolnego kodu php na serwerze! Jeśli tak to po co w ogóle robić zapytanie do mysql! Nie lepiej od razu dać: echo "My login & password is: ...."; Konieczność pamiętania... Wadą? A jak zapomnisz przekonwertować każdorazowo na liczbę to co się stanie? Jakiś problem aby funkcja _P zwracała quoted String? Wybaczy Pan...

Ehh... no to dwie rzeczy:

1. Wskaż mi choć jedno miejsce, w którym piszę coś propo Twojej persony. Nawiązuję jedynie do Twoich postów, a nie Ciebie.

2. Skoro już zaczęliśmy się bawić w opowiadanie historyjek, to ja opowiem prawdziwą:

Przedstawiłeś się jako konstruktor mostów. Masz swoje narzędzie - młotek firmy `aoi` (którym w tym wypadku jest podana przez Ciebie funkcja). Udało Ci się zbudować stabilny most na betonowym podłożu (którym w tym wypadku jest podane zapytanie). Teraz inni budowniczy (forumowicze) użyją tego młotka, żeby zbudować swoje mosty, ale zbudują je na przykład na piaszczystym, czy też bagnistym podłożu i będą wadliwe, przy skakaniu zawalą się. Twoja rola jako twórcy odpowiedniego młotka do budowy mostów nie powiodła się.

Prościej już nie wiem jak Ci to wytłumaczyć.

Dzięki, że wytłumaczyłeś swój brak zrozumienia mnie. Otóż technika budowania mostów polega na nauce sposobu projektowania i wykonania, a nie zrobieniu jednego młotka i podejmowaniu próby budowy wszystkiego tym samym młotkiem. W moim przypadku techniką, którą przedstawiłem jest natywna obsługa Stringu w sql co zapobiega konieczności dodatkowej obsługi, co by było gdyby był UNION, a może DELETE, itd. Panu obok może się nie podobać String, ale nie zauważa, że konwertując na liczbę, potem i tak konwertuje na String, co później znowu jest konwertowane na liczbę.... o rzeczywiście, jakie ładne

Ten post edytował aio 2.03.2010, 17:17:10

[pyro]

Otóż technika budowania mostów polega na nauce sposobu projektowania i wykonania, a nie zrobieniu jednego młotka i podejmowaniu próby budowy wszystkiego tym samym młotkiem.

To czemu pokazałeś tylko ten jeden młotek? Widzę, że zaczynasz zaprzeczać samemu sobie.

@aoi, @Crozin ma rację

Ten post edytował pyro 2.03.2010, 17:55:20

[Crozin]

Tak trudno to pojąć, że w sytuacji gdzie użyłbyś takiego zapytania jak ja podałem byłbyś błędnie przekonany o skuteczności owej filtracji (która jak mniemam ma służyć do filtrowania wszystkiego)? Co się czepiasz, że ktoś podaje przykład, w którym użyto innej - bardziej sensownej, czytelnej, "poprawnej" konstrukcji w której to filtrowanie o kant d..y rozbić można, a jej występowanie jest powszechne - jeśli nawet nie u Ciebie, to u dużej części programistów?

Ten wątek ma służyć m. in. promowaniu dobrych praktyk, a Twoja jest wręcz naganna i może doprowadzić innych użytkowników do sytuacji opisanej czy to przeze mnie czy przez pyro.

Panu obok może się nie podobać String, ale nie zauważa, że konwertując na liczbę, potem i tak konwertuje na String, co później znowu jest konwertowane na liczbę.... o rzeczywiście, jakie ładne

Jak mniemam również uważasz zapisy typu:

[PHP] pobierz, plaintext 
$obj->getId() == "123";
$abc = "123413";
$def = abc() + "4" + 2 - def();
toSth("321", "true - bo przecież z rzutuje na boolean'owskie TRUE");
[PHP] pobierz, plaintext 

Za czytelniejsze/bardziej sensowne? Już nie wspominając o tym, że przykładowe ID (użyte w przykładach ilustrujących ułomność Twojej metody) wykorzystujemy tylko w zapytaniach?

PS. Z mojej strony to tyle - nie ciągnę więcej tego wątku.

EDIT:
Zapomniałem dodać: Jak prezentujesz jakieś rozwiązania, to albo opisz, że należy je stosować wyłącznie w określonych przypadkach, albo chociaż zwróć uwagę na to, że w pewnych są kompletnie nieskuteczne.

Ten post edytował Crozin 2.03.2010, 18:04:34

[aio]

Tak trudno to pojąć, że w sytuacji gdzie użyłbyś takiego zapytania jak ja podałem byłbyś błędnie przekonany o skuteczności owej filtracji (która jak mniemam ma służyć do filtrowania wszystkiego)? Co się czepiasz, że ktoś podaje przykład, w którym użyto innej - bardziej sensownej, czytelnej, "poprawnej" konstrukcji w której to filtrowanie o kant d..y rozbić można, a jej występowanie jest powszechne - jeśli nawet nie u Ciebie, to u dużej części programistów?

Ten wątek ma służyć m. in. promowaniu dobrych praktyk, a Twoja jest wręcz naganna i może doprowadzić innych użytkowników do sytuacji opisanej czy to przeze mnie czy przez pyro.

Jak mniemam również uważasz zapisy typu:

[PHP] pobierz, plaintext 
$obj->getId() == "123";
$abc = "123413";
$def = abc() + "4" + 2 - def();
toSth("321", "true - bo przecież z rzutuje na boolean'owskie TRUE");
[PHP] pobierz, plaintext 

Za czytelniejsze/bardziej sensowne? Już nie wspominając o tym, że przykładowe ID (użyte w przykładach ilustrujących ułomność Twojej metody) wykorzystujemy tylko w zapytaniach?

PS. Z mojej strony to tyle - nie ciągnę więcej tego wątku.

EDIT:
Zapomniałem dodać: Jak prezentujesz jakieś rozwiązania, to albo opisz, że należy je stosować wyłącznie w określonych przypadkach, albo chociaż zwróć uwagę na to, że w pewnych są kompletnie nieskuteczne.

No raczej trudno pojąć, skoro składnia ze stringiem występuje celowo właśnie po to aby filtrować zarówno number jak i string i wykorzystać natywny support dla osiągnięcia konkretnego celu. Skoro moje zapytanie przechodzi przez parser sql to chyba nie jest aż tak do dupy jak się koledze wydaje

Panowie. Po co wklejacie jakiś kod (błędny zresztą) nie związany z tematem i wmawiacie mi, że na pewno tak uważam i żeby rzekomo dowieźć swojej racji dumnie ogłaszacie EOT! Jedną linijkę kodu, którą napisałem na siłę mi zmieniacie i mówicie, że musi być zmieniona, czytaj źle napisane zapytanie i wtedy nie będzie działać. Pytam po co? Napisaliście, że nie rozwiązuje to nawet połowy problemów zw. z SQL Injection. Super. Ale na litość boską może chociaż jeden przykład!? Jak ja mówię, że w pewnym przypadku naprzemienna konwersja string<->number jest niekoniecznie potrzebna bo ma inne zalety, to mi się wyjeżdża z argumentem, że gdyby tak było to pisało by się "4" + 2 we wszystkich innych zastosowaniach (sic!)! Czy na prawdę tak trudno sobie wyobrazić sytuację odwrotną: Wy napisaliście kod zabezpieczający. A ja zmienię coś w tym kodzie i będę się upierał, że nie działa Wasz kod! No jest tu sens? Czy istnieje jakikolwiek kod, którego nie da się tak "poprawić" aby go zepsuć? Odpowiedzcie szczerze.

"...albo chociaż zwróć uwagę na to, że w pewnych są kompletnie nieskuteczne" - w jakich? Że jak celowo zrobisz lukę (w tym wypadku usunięty cudzysłów) to będzie luka? Kiedy jest nieskuteczne przy prawidłowym użyciu wg podanego przeze mnie przykładu? Proszę uprzejmie, czekam, bez klęcia, epitetów i wywnętrzania się.

To czemu pokazałeś tylko ten jeden młotek? Widzę, że zaczynasz zaprzeczać samemu sobie.

@aoi, @Crozin ma rację

Jaki młotek? Podałem sposób a Wy ten sposób na siłę zmieniacie i udowadniacie, że nie działa. No to udowodniliście, że Wasza metoda jest do niczego. Ok. Widzę.

W czym sobie zaprzeczyłem? Pokazałem sposób - narzędzie + przykład użycia. Rozwiązanie ze stringiem działa zarówno dla number jak i string, z kolejną jeszcze niewymienioną zaletą, że gdyby było dozwolone 0 jako input, to trzeba by było jeszcze dodatkowo uwzględnić wypadek, gdy input (który zawsze jest stringiem) był rzutowany do zera, trzeba by dodatkowo sprawdzać czy string... naprawdę muszę to pisać?

Wyobraźcie sobie: to tak jakbyście słusznie mówili, że żeby zrzutować do integer trzeba napisać $int = (int)$str; a na to ja przychodzę i mówię: no tak, ale jak się napisze $int = (string)$str; to nie będzie działać, więc Wasz kod jest do dupy. Nie na tym przypadkiem polega Wasze udowadnianie?

Może dla odmiany, zamiast orzekać co ja uważam, i że tak bardzo się mylę, może się doczekam tego haku? Szampan wciąż czeka.

Pozdrawiam Szanownych Interlokutorów.

[pyro]

Jaki młotek? Podałem sposób a Wy ten sposób na siłę zmieniacie i udowadniacie, że nie działa. No to udowodniliście, że Wasza metoda jest do niczego. Ok. Widzę.

Nie zmieniłem nawet jednej literki. Użyłem dokładnie tego sposobu, który Ty podałeś. I ci przykładowo udowodniłem, że Twój sposób jest nieskuteczny.

W czym sobie zaprzeczyłem? Pokazałem sposób - narzędzie + przykład użycia.

I Ci właśnie pokazałem, używając tego samego narzędzia, na innym przykładzie, że sposób jest zawodny.

Rozwiązanie ze stringiem działa zarówno dla number jak i string,

Ehhh... kolejny raz piszę, że podałem Ci przykład, w którym Twój sposób na liczbę nie działa.

z kolejną jeszcze niewymienioną zaletą, że gdyby było dozwolone 0 jako input, to trzeba by było jeszcze dodatkowo uwzględnić wypadek, gdy input (który zawsze jest stringiem) był rzutowany do zera, trzeba by dodatkowo sprawdzać czy string... naprawdę muszę to pisać?

Czy z inputa czy nie, tak czy inaczej zawiedzie...

w jakich? Że jak celowo zrobisz lukę (w tym wypadku usunięty cudzysłów) to będzie luka?

Twoje zabezpieczenie nawet z cudzysłowami nie w jednym przypadku zawiedzie. A wymuszanie ich używania na użytkowniku jest co najmniej nie na miejscu, chociażby ze względów wydajnościowych. Dodatkowo piszący kod może o nich zapomnieć ich użycia dla danych numerycznych, bo ma taki dobry nawyk i skrypt dalej dziurawy.

[erix]

~aio, a przeczytałeś ten wątek od początku?

[thek]

Ja właśnie za to, iż PHP jest tak "nieokreślony" z początku podchodziłem do niego hurraoptymistycznie. Fajnie, w końcu nie martwię się o typy danych i wiele innych aspektów, które wyniosłem z nauki C++. Tyle że ta dowolność w wypadku www i ataków jest największym zagrożeniem. Co z tego, że baza mi w locie zamieni string na liczbę czy na odwrót. Skoro ja oczekuję od usera danych o określonym formacie to taki ma do skryptu trafić i koniec, kropka. Ma to być string, to niech bedzie, nawet jeśli z cyfr złożony. Ale niech mi baza tego nie przerabia na int bo może to dla mnie nie być to co chcę. ma być liczba? To filtruję i wywalam wszystko co nie jest cyframi lub na etapie walidacji choćby jeden znak nie będzie cyfrą to od razu user jest na cenzurowanym. Dla mnie mysql_real_escape_string, filter_var i czasem preg_match to niezbędne minimum. Dziś nawet jak się okazało zabezpieczenia pchnąłem na taki poziom w swoim panelu, że szef zgłupiał Jakim sposobem? tak miałem skonstruowany kod, że jedyne modyfikacje rekordów w bazie mogła wykonać osoba je zakładająca, gdyż wszystko wiązało się z kontrolą działań użytkownika przy współdziałaniu bazy danych oraz zmiennych sesyjnych. W efekcie tylko bezpośrednie modyfikacje rekordów w bazie odnosiły sukces. Nawet osoba z uprawnieniami administratora w serwisie mogła jedynie na to patrzeć z boku, gdyż skrypt nie pozwalał mu modyfikować danych innych userów Tak bowiem był skonstruowany by blokować wszelkie próby ingerencji użytkowników w dane innych użytkowników. A admin to też user :] No ale tak to jest z custom made skryptami. Niektórzy mają dziury i mają to gdzieś, a inni przesadzą przypadkiem w druga stronę i user jest w 100% zabezpieczony. Nawet przed administratorem

[aio]

~aio, a przeczytałeś ten wątek od początku?

Witam, ale co masz na myśli, bo nie będę się upierał, że niczego nie pominąłem, bo sam chyba przyznasz, że mimo różnych rozwiązań, co ileś postów (o dziwo po moim również) na nowo pojawia się wątek z a to INTEGEREM, a to UNION... itd (!), co sprawia, że przeglądanie postu gdy kolejny raz widzę, że zawiera w sobie słowo UNION, powoduje, że nawet nie czytam Jeśli to w jakimś stopniu kogoś uraziło, to pragnę przeprosić. Z kolei autor wątku edytując pierwszy post, jak sądzę, starał się dokonać pewnego streszczenia zagadnienia, a pytanie w takim razie do Ciebie, czy zauważyłeś czym różni się moje rozwiązanie od proponowanych tutaj? Szczegół, którego tutaj, jeśli się nie mylę nikt nie poruszył (nawet koledzy, którzy udowadniają mi dodupowość tego skompresowanego semantycznie do jedniej linii algorytmu)? I żeby była jasność - nigdzie nie napisałem, że ta linijka kodu jest genialna i mam nadzieje, że nigdzie się nie wywyższyłem ponad kogokolwiek z Was, ale naprawdę, jeśli ktoś wykażę się wiedzą otrzyma nagrodę a ja się czegoś nauczę, słowo dałem i dotrzymam.

Ja właśnie za to, iż PHP jest tak "nieokreślony" z początku podchodziłem do niego hurraoptymistycznie. Fajnie, w końcu nie martwię się o typy danych i wiele innych aspektów, które wyniosłem z nauki C++. Tyle że ta dowolność w wypadku www i ataków jest największym zagrożeniem. Co z tego, że baza mi w locie zamieni string na liczbę czy na odwrót. Skoro ja oczekuję od usera danych o określonym formacie to taki ma do skryptu trafić i koniec, kropka. Ma to być string, to niech bedzie, nawet jeśli z cyfr złożony. Ale niech mi baza tego nie przerabia na int bo może to dla mnie nie być to co chcę. ma być liczba? To filtruję i wywalam wszystko co nie jest cyframi lub na etapie walidacji choćby jeden znak nie będzie cyfrą to od razu user jest na cenzurowanym. Dla mnie mysql_real_escape_string, filter_var i czasem preg_match to niezbędne minimum. Dziś nawet jak się okazało zabezpieczenia pchnąłem na taki poziom w swoim panelu, że szef zgłupiał Jakim sposobem? tak miałem skonstruowany kod, że jedyne modyfikacje rekordów w bazie mogła wykonać osoba je zakładająca, gdyż wszystko wiązało się z kontrolą działań użytkownika przy współdziałaniu bazy danych oraz zmiennych sesyjnych. W efekcie tylko bezpośrednie modyfikacje rekordów w bazie odnosiły sukces. Nawet osoba z uprawnieniami administratora w serwisie mogła jedynie na to patrzeć z boku, gdyż skrypt nie pozwalał mu modyfikować danych innych userów Tak bowiem był skonstruowany by blokować wszelkie próby ingerencji użytkowników w dane innych użytkowników. A admin to też user :] No ale tak to jest z custom made skryptami. Niektórzy mają dziury i mają to gdzieś, a inni przesadzą przypadkiem w druga stronę i user jest w 100% zabezpieczony. Nawet przed administratorem

Zgadzam się w całej rozciągłości. Czegoś nie jesteśmy pewni, róbmy filtry i obudowujmy nasz skrypt. W końcu jeśli user ma podać integer a podał '4abc' to też wypadałoby go za to opierniczyć i samo (int) nie wystarczy, prawda? Do żadnych, hiper wypasionych, wielopoziomowych walidacji nic nie mam. Mam nadzieje, że się rozumiemy. Przedstawiłem tylko pewien trick, który jest bardziej wynikiem świadomości tego co się dzieje na poziomie cpp (opisałem to wyżej), niż tego co daje nieokreśloność php. W końcu wątek jest o SQL Injection i już chyba bardziej na temat napisać nie mogłem i mam nadzieję, że się nie rozwlekam jeśli nie muszę. Otrzymałem zarzut, że ... no już nie będę cytował. Pytam więc, z ciekawości: da się ominąć? - pokażcie.

Nie zmieniłem nawet jednej literki. Użyłem dokładnie tego sposobu, który Ty podałeś. I ci przykładowo udowodniłem, że Twój sposób jest nieskuteczny.



I Ci właśnie pokazałem, używając tego samego narzędzia, na innym przykładzie, że sposób jest zawodny.



Ehhh... kolejny raz piszę, że podałem Ci przykład, w którym Twój sposób na liczbę nie działa.



Czy z inputa czy nie, tak czy inaczej zawiedzie...



Twoje zabezpieczenie nawet z cudzysłowami nie w jednym przypadku zawiedzie. A wymuszanie ich używania na użytkowniku jest co najmniej nie na miejscu, chociażby ze względów wydajnościowych. Dodatkowo piszący kod może o nich zapomnieć ich użycia dla danych numerycznych, bo ma taki dobry nawyk i skrypt dalej dziurawy.

Podałem przykład użycia. Przykład jest po to aby wyjaśnić jak użyć. Jeśli naprawdę nie rozumiesz mojego przykładu to zamień sobie w moim przykładzie `login` na swoje `video_id`. A następnie włamuj się swoim (dobrym skądinąd) requestem, a później dla porównania przeklej swój. Ręczę Ci, że zajmie Ci to krócej niż kolejne wytłuszczanie poszczególnych słów w swoim poście! Dżizaz to jest takie trudne serio? Przecież zapytanie musi być dobrze napisane! Przecież to jest kwintesencja w ogóle programowania! Argument "a co jak zapomnę...?" jest takim samo dobry jak "a co jak zapomnę zamknąć drzwi od samochodu?". Jeśli nadal nie rozumiesz na podstawie jednej linijki o co w nim chodzi, to ja Ci już nie pomogę, gdyż musiałbym powtarzać objaśnienia z powyższych postów.

PS. Żartobliwie dodam, że zaczynam rozumieć też autora wątku, który prawdopodobnie znając Waszą uszczypliwość, podaje co najmniej dwa sposoby na rzutowanie typów, bo w przeciwnym razie zarzucilibyście mu, że można inaczej i że jego kod jest do... A przychylając się do prośby autora "Proszę osoby obeznane w tym temacie, aby dopisały tu własne propozycje metod zabezpieczenia się przed tym atakiem" lecz z wyłączeniem słowa "obeznane" bo się za taką nie uważam, po prostu to zrobiłem. Mało tego, pytam i sam jestem ciekaw czy ktoś jest w stanie to obejść...

Twoje zabezpieczenie nawet z cudzysłowami nie w jednym przypadku zawiedzie

Obiecałem. Podaj przykład, masz szampana.

[pyro]

Ehhh... ja się po prostu poddaję. Nie ważne ile bym nie tłumaczył, to @aoi i tak się upierasz przy swoim, nie patrząc na to obiektywnie, nie ważne jak bardzo się mylisz. @aoi, warto zwrócić uwagę, że nie tylko ja Ci próbuję to wytłumaczyć, ale także parę innych osób.

[aio]

Ehhh... ja się po prostu poddaję. Nie ważne ile bym nie tłumaczył, to @aoi i tak się upierasz przy swoim, nie patrząc na to obiektywnie, nie ważne jak bardzo się mylisz. @aoi, warto zwrócić uwagę, że nie tylko ja Ci próbuję to wytłumaczyć, ale także parę innych osób.

E tam poddawać się. Ważne, że już ochłonęliśmy, będzie się milej rozmawiać. Wiem, że dyskusja jest taka dlatego, że w pierwszym poście nie napisałem 1000 słów opisu, dlaczego tak a nie inaczej i szczegółowo how to do & how not. Ale na tym polegał post: 1 obraz, zero objaśnień. Oczywiście wiem, że przez to mogłem być źle zrozumiany, a propos tego na co zwrócić uwagę ale przecież po pojawieniu się wątpliwości zostało to wyjaśnione w drugim poście! Tak samo jak nie można pominąć/zapomnieć w Waszych kodach '(int)' tak samo w moim nie można pominąć "'"! I nie jest kwestią do roztrząsania tutaj czy kod jest ładny, pół-brzydki, czy para-pseudo-nie-teges! Chodzi w tym o to, że mimo bardzo obszernie przedstawianego zagadnienia ataku SQL, zadałem pytanie czy jest możliwe rozprawić się z problemem ekstremalnie prostym i banalnym zabiegiem? Czy chroni to w zupełności czy nie? Mam nadzieję, że chociaż zauważyłeś, że w kod zawiera ochronę przeciwko namnażającym się slashom, na co nikt nie zwrócił uwagi w całym wątku, a istotne jest nie tyle przy SELECT ile przy zapisie do bazy, bo może zepsuć dane, bo to jest właśnie szczegół, o którym najłatwiej zapomnieć, ale większość woli pisać super-klasy podmieniające UNION (przepraszam, że się znowu z tego nabijam - już nie będę). I tak, widzę, że wszyscy twierdzą, że się mylę. Ale przypominam, tu przecież nie chodzi o to, że mój przykład nie waliduje inputu pod każdym możliwym do wymyślenia i uniwersalnym kątem oraz nie wyświetla okienka z napisem "Dear Almighty User, please kindly note you have failed on input"; bo takie rzeczy zależą od indywidualnych potrzeb. Ale chodzi o to czy da się dokonać ataku SQL! Obojętnie czy przyjmując liczbę, string, czy odczytując czy zapisując do bazy.
Ja podałem 1 obraz, Wy macie pretensje, że nie napisałem 1000 słów. Wy piszecie 1000 słów, to pokażcie chociaż 1 obraz.

Cieszę się bardzo, że piszecie, że się mylę, że nie zadziała nawet z cudzysłowem. Nawet nie chce, żebyście mi przyznawali rację! Ale dlaczego jedyny argument to "bo nie i już"? Jestem ciekaw. Podajcie przykład.

PS. ERRATA do pierwszego postu: ewentualną nagrodę otrzymuje pierwszy łamacz! Bo znając już Waszą czepialskość, każdy skopiuje post i będzie sądownie dochodził należności

[Kużdo]

Mam pewien problem... Testuje sobie różne zabezpieczenia własnych skryptów i chciałem teraz przeprowadzić atak na skrypt bez zabezpieczeń i wyłączonym magic_quotes_gpc()... Problem w tym, że nie chce wykonać się w ogóle zapytanie... Oto one:

[SQL] pobierz, plaintext 
INSERT INTO title (title) VALUES (12) UNION SELECT title FROM title WHERE id = 1
[SQL] pobierz, plaintext 

W tej tabeli już są wpisy... Jednak MySQL wywala błąd: #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'UNION SELECT title FROM title WHERE id = 1' at line 1"
Może mi ktoś powiedzieć dlaczego jest błąd?

Edit: Dodam, że działa tylko SELECT ... UNION SELECT ... Operacje na różnych tabelach też nie działają...

Ten post edytował kuzdo 5.03.2010, 18:27:55

[bełdzio]

UNION SELECT możesz wstrzyknąć tylko w zapytania pobierające dane, czyli w innego SELECTa

[Kużdo]

Dzięki za odpowiedź... Miałem o coś jeszcze się zapytać, ale trochę pogooglowałem i znalazłem odpowiedź... Z początku myślałem, że UNION to tylko taki operator AND, a to jednak pozwala tylko na dodanie dodatkowego SELECT... Myślałem, że za pomocą UNION można wykonać każdą komendę - INSERT, DROP, TRUNCATE, itd. Jeśli jednak się mylę i można je użyć za pomocą UNION, to niech ktoś mnie poprawi...

[pyro]

UNION, jak sama nazwa mówi (z ang. złączenie) służy do łączenia pobieranych danych.

[GreeN_DG]

Witam. Chciałbym wrócić do zagadnienia "prepared stat...". Na większości anglojezycznych stron opisują, iż to najlepszy sposób zabezpieczający przed sql inj.. Czyli przy użyciu ps zmienne są całkowicie oddzielone od spreparowanego zapytania? Cokolwiek by się w nich nie pojawiło będzie zawsze interpretowane jako zmienna danego typu a nie jako cześć zapytania?

[erix]

Tak.