To raczej nie wina forum, a tego, że IP trafiło prawdopodobnie do kogoś, kto ma PC-zombie.

A z tego, co pamiętam, to TP wykupiła kiedyś pulę IP dla neozdrady, która była wcześniej intensywnie wykorzystywana do włamów. [;

Tak się zastanawiam...
jeśli strona ma geta np id=1, jeśli dopiszemy mu 1' sql /* to nie zareaguje,
ale jeśli mu dam id=aaa to wypluje warning ... czy taka strona jest podatna na sql injection ?
Pytam bo widzę taką stronkę i zastanawiam się czy zawracać gitarę adminowi , dodatkowo ciekawość

Tak. Jeśli dla stringa wypluwa warninga to wielce prawdopodobne jest, że zapytanie jest zbudowane tak:

[SQL] pobierz, plaintext 
SELECT a FROM b WHERE id = $zmienna
[SQL] pobierz, plaintext 

Integery nie muszą być w cudzysłowiach, natomiast stringi tak. A np. zapytanie

[SQL] pobierz, plaintext 
SELECT a FROM b WHERE id = 1' sql /*
[SQL] pobierz, plaintext 

nie wywołuję błędu bo po stronie php są wykrywane pewne niebezpieczne ciągi np. sekwencja "/*" i zmienna jest ignorowana etc.

Jednoznacznie nie da się określić czy taka strona jest podatna na jakiś atak z grupy SQLI. Ja sprawdziłbym ataki typu DoS z grupy SQLI. Sprawdzałbym inne wejścia bo raczej podane przez Ciebie jest popularne.

Taka wskazówka, każdy atak SQLI zaczyna się od wydedukowania zapytania.

Mam pewne pytanie, odnośnie wypowiedzi erixa dotyczącej mysql_escape_string:



Kiedy może się coś takiego stać? Powiedzmy że przez $_POST idzie ciąg, po którym szukam czegoś w bazie w polu typu varchar.
Ciąg z założenia powinien być obrobiony tzn. bez znaków diaktrycznych itp. więc nie muszę się martwić o problemy z nimi.

Chodzi o to, że mysql_real_escape_string działa znacznie wolniej niż wersja bez sprawdzania charsetu.

Np. przy korzystaniu z UTF-8.

Wszystko jest przecież napisane:


A tak poza tym, dla mysql_escape_string" title="Zobacz w manualu PHP" target="_manual:

Hej,

Już raz wspominałem o zastosowaniu zmiennych związanych, ale jakoś widzę wątek dalej rozwija się
w stronę doktoryzacji nad zupełnie prostym problemem. W telegraficznym skrócie:
Zmienne związane mają 2 główne zastosowania:
1) optymalizacja działania aplikacji poprzez jednokrotną interpretację zapytania, a w każdym
następnym jego uruchomieniu tylko podmienianie samych danych. MySQL optymalizuje sobie
niestety takie zapytanie tylko w obrębie sesji. Inne bazy takie jak ORACLE przechowują plan wykonania
zapytania.
2) Oddzielenie treści zapytania od parametrów załatwia przy okazji właśnie problem MySQL Injection.
W zasadzie w 100% ponieważ dane nie wpływają na treść zapytania, która już wcześniej została sparsowana.

Przykład SQLa:

[SQL] pobierz, plaintext 
SELECT * FROM tabela WHERE pole = :parametr
[SQL] pobierz, plaintext 

takie zapytanie parsuje sobie baza, a dopiero potem przekazujemy (bindujemy) wartość
zmiennej "parametr".

Jeszcze raz link do manuala PHP:
PDO::prepare
oraz jak kto woli:
mysqli_prepare

Oczywiście warunkiem jest PHP5 oraz MySQL 4.1, ale to chyba już w tej chwili standard.

Z tego co zauważyłem to ile osób tyle rozwiązań przed tego typu atakami. A jeżeli ktoś opracuje jakiś uniwersalny kod - to posypie się sporo wypowiedzi negatywnych. Wiec z tego nasuwa się jeden wniosek, jakie zabezpieczenie by nie było i tak nie jest dobre.

Z tego co czytałem ten wątek i jemu podobne w sieci. To nasuneły mi sę takie spostrzeżenia:
Przed atakami XSS najlepiej się bronić stosując htmlspecialchars lub htmlentities - dla danych wyświetlanych (np z BD).


Natomiast przed SQL Injecton, to albo zapoznać się z jakimś interfejsem np PDO i konstruować zapytania w stylu prepare, execute. 
Ale jeżeli ktoś chce zostać przy standardowym konstruowaniu zapytań do BD (np nie chce mu się przebudowywać istniejącego serwisu pod PDO), to czy nie wystarczy dane (zewnętrzne) czy to z POST czy GET poddawać najpierw np htmlentities potem zastosować sprawdzanie wyrażeniami regularnymi (lub stosować funkcje ctype, is_numeric itp.), a na końcu w zapytaniu do BD zastosować mysql_real_escape_string

Jest wiele opini na temat czy to htmlentities, addslashes, strip_tags. Ale które nalepsze? 

strip_tags - wycina(eliminuje) znaczniki HTML,
- nie warty zachodu, jeżeli dane które mają być przetworzone, zapisane w BD a potem wyświetlane w serwisie (stracą formatowanie). 
- jednak są sytuacje w których może się przydać.


addslashes - Dodaje znak ucieczki przed znakami niebezpiecznymi jak: apostrof, cudzysłów, backslash i NUL

htmlentities - konwertuje wszystkie znaki HTML na encje, gdzie htmlspecialchars tylko znaki specjalne. 

Wiec jeżęli ciag zostanie przeformatowany przez htmlentities - to spokonie można sprawdzić np wyrażeniami regularnymi czy zawiera to co powinnien i odpowiednią długość znaków, a następnie przekazać do bazy danych. Ale czy warto wtedy stosować mysql_real_escape_string? - moim zdaniem warto na wypadek gdy wyrażenia regularne nie będą zbyt ścliśle określone i przepuszczą coś w stylu  UNION, SELECT ... Wówczas jeżeli dobrze rozumie powyższa komenda to wyeliminuje.

Ale nie jestem specem w tej dziedzinie i miło mi będzie jeżeli ktoś to sprostuje.

Wszystkie pytania o SQL Injection powinny się kończyć jednym zdaniem: "Używaj prepared statements, lub jeśli uważasz, że nigdy nie zapomnisz tego zrobić, dodawaj znaki ucieczki odpowiednie dla twojej bazy". Koniec, kropka. Podobnie XSS - "usuwasz cały html albo escape podczas wyświetlania".
Tymczasem w tym wątku co chwila pojawiają się jakieś dziwne pomysły, które co najwyżej wprowadzają zamieszanie i w sumie nie wiem czemu ten wątek ma służyć. Może lepiej przyciąć to do jednego postu z informacją co i jak i tylko go zostawić przypiętym?

Zgadzam się. Jak czytam niektóre z tych wymysłów to aż głowa boli. Potem się przyszła ekipa źle nauczy.

ja bym dodał świadomie bo korzystając z PS też można dać ciała

1 obraz > 1000 słów

[PHP] pobierz, plaintext 
function _P($sql) { return mysql_real_escape_string(get_magic_quotes_gpc()?stripslashes($sql):$sql); }
[PHP] pobierz, plaintext 

Przykładowe użycie:

[PHP] pobierz, plaintext 
$query = "SELECT * FROM `login` WHERE `login`='"._P($_POST['login'])."'";
[PHP] pobierz, plaintext 

jak ktoś to shakuje to wysyłam mu Moet!

[PHP] pobierz, plaintext 
function _P($sql) { return mysql_real_escape_string(get_magic_quotes_gpc()?stripslashes($sql):$sql); }
mysql_query('SELECT id,name FROM videos WHERE `video_id` = '._P($_GET['video_id']));
[PHP] pobierz, plaintext 

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

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.

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ą

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

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



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.

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

trudniejsze czy nie, to generalnie kwestia czasu, po prostu nie można sobie pozwolić na to, żeby taka miała miejsce



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).



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.



To zdanie jest również (według mnie) fałszywe. Można pisać tak, żeby nie popełniać błędów.

czasami wlasnie ten czas dziala na twoja korzysc oznacza to im dluzej ktos prubuje wlamac tym masz lepsze zabezpieczenia


Moze sie i pisze ale widzialem ludzi ktorzy trzymaja hasla i w sesji jak i w cookie



Nie jestes w stanie tak napisac kodu zeby nie popelnic bledu. Inaczej nie bylo by wlamow do najwikszych instytucji Polsce i na swiecie.

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.

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.



Zaryzykuje to stwierdzenie, ale jestem. A już przynajmniej od strony SQL Injection, o którym jest temat.

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

http://php.net/manual/en/pdo.prepare.php


To powinno załatwić sprawę.

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.

Oczywiście... w JPortalu już czegoś takiego próbowali i miałem dzięki temu dużo "zabawy" .

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

@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.

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



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

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

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.

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ć.

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...



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

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

@aoi, @Crozin ma rację

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ę.





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.

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.

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

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

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.



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.





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ść...


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

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

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ą...

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

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...

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

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?

Tak.