Jak dobrze rozumiem wykonując to co zostało opisane na początku tego artykułu: https://krystianbrozek.pl/atak-sql-injection/
Czyli dodanie OR 1 = 1 w inpucie z hasłem sprawi, że dostaniemy hasło z bazy danych dla danego użytkownika ? Jeśli aplikacja nie jest zabezpieczona przed sql injection.
SQL Injection - wstrzyknięcie "kodu" SQL bezpośrednio do wykonania. To znaczy, że nie zabezpieczamy się właściwie i dajemy możliwość przesłania jakiegoś parametru bezpośrednio od użytkownika.
W podanym tutaj w artykule przykładzie ktoś wpisał w pole hasła OR 1 = 1 tym samym po stronie serwera wykonało się polecenie:
SELECT Id FROM Users WHERE Login = 'mój login' AND Password = '' OR '1'='1' Nie otrzymujemy więc hasła użytkownika tylko omijamy w ogóle warunek sprawdzania hasła. Artykuł IMHO ma błąd bo podaje że OR ma pierwszeństwo przed AND w SQL a w znanych mi silnikach jest odwrotnie:
https://learn.microsoft.com/en-us/sql/t-sql/language-elements/operator-precedence-transact-sql?view=sql-server-ver16
https://dev.mysql.com/doc/refman/8.0/en/operator-precedence.html
https://www.postgresql.org/docs/7.2/sql-precedence.html
Przebudujmy sobie to zapytanie dodając nawiasy tak by odtworzyć intencję autora
SELECT Id FROM Users WHERE Login = 'mój login' AND (Password = '' OR '1'='1')
Teraz zapytanie zwróci nam ID użytkownika który ma login mój login ale ze względu na dodanie logicznego OR nawet przy pustym haśle warunek ten zwróci true.
Normalnie takie ID powinno być zwrócone tylko w momencie gdy para login i hasło pasują do siebie.
Myślę, że autor chciał jak najprościej opisać zagadnienie i stąd pewne uproszczenia. Ogólnie chodzi o to by zapobiec możliwości by użytkownik był w stanie dodać cokolwiek do wykonywanych zapytań tak by dokonać ich modyfikacji.
W przypadku prawidłowo parametryzowanego zapytania co najwyżej można by uzyskać
SELECT Id FROM Users WHERE Login = 'mój login' AND Password = ' OR \'1\'=\'1\'')
A to raczej wątpliwe żeby ktoś miał hasło ' OR '1'='1 i jest to już jednoznaczne z próbą odgadnięcia hasła a nie jego pominięciem.
jurek1980 napisał(a):
SQL Injection - wstrzyknięcie "kodu" SQL bezpośrednio do wykonania. To znaczy, że nie zabezpieczamy się właściwie i dajemy możliwość przesłania jakiegoś parametru bezpośrednio od użytkownika.
W podanym tutaj w artykule przykładzie ktoś wpisał w pole hasłaOR 1 = 1tym samym po stronie serwera wykonało się polecenie:
SELECT Id FROM Users WHERE Login = 'mój login' AND Password = '' OR '1'='1'Nie otrzymujemy więc hasła użytkownika tylko omijamy w ogóle warunek sprawdzania hasła. Artykuł IMHO ma błąd bo podaje że OR ma pierwszeństwo przed AND w SQL a w znanych mi silnikach jest odwrotnie:
https://learn.microsoft.com/en-us/sql/t-sql/language-elements/operator-precedence-transact-sql?view=sql-server-ver16
https://dev.mysql.com/doc/refman/8.0/en/operator-precedence.html
https://www.postgresql.org/docs/7.2/sql-precedence.html
Przebudujmy sobie to zapytanie dodając nawiasy tak by odtworzyć intencję autoraSELECT Id FROM Users WHERE Login = 'mój login' AND (Password = '' OR '1'='1')Teraz zapytanie zwróci nam ID użytkownika który ma login
mój loginale ze względu na dodanie logicznego OR nawet przy pustym haśle warunek ten zwróci true.
Normalnie takie ID powinno być zwrócone tylko w momencie gdy para login i hasło pasują do siebie.
Myślę, że autor chciał jak najprościej opisać zagadnienie i stąd pewne uproszczenia. Ogólnie chodzi o to by zapobiec możliwości by użytkownik był w stanie dodać cokolwiek do wykonywanych zapytań tak by dokonać ich modyfikacji.
W przypadku prawidłowo parametryzowanego zapytania co najwyżej można by uzyskaćSELECT Id FROM Users WHERE Login = 'mój login' AND Password = ' OR \'1\'=\'1\'')A to raczej wątpliwe żeby ktoś miał hasło
' OR '1'='1i jest to już jednoznaczne z próbą odgadnięcia hasła a nie jego pominięciem.
@jurek1980: a jakim sposobem przy wstrzykiwaniu sql injection w zapytaniu na końcu dodawany jest apostrof ? np.
SELECT Id FROM Users WHERE Login = 'mój login' AND Password = ''; DROP TABLE Users --'
jeśli w input z hasłem wpiszemy
'; DROP TABLE USERS --
I mam jeszcze pytanie co do tego zdania:
"Nie otrzymujemy więc hasła użytkownika tylko omijamy w ogóle warunek sprawdzania hasła."
Czyli jak rozumiem użytkownik zostaje wtedy zalogowany ?
a jakim sposobem przy wstrzykiwaniu sql injection w zapytaniu na końcu dodawany jest apostrof
IMHO To znów lekkie uproszenie/literówka lub coś co zależy od danego spsosobu w jakim jest wykonywane zapytanie. Zdaje się że pisałeś coś w PHP to wyobraź sobie, że robię coś takiego:
$query = "SELECT Id FROM Users WHERE Login = 'mój login' AND Password ='".$customerInput."'";
Czyli wrzucam wszystko co jest od użytkownika między apostrofy żeby zbudować zapytanie.
"Nie otrzymujemy więc hasła użytkownika tylko omijamy w ogóle warunek sprawdzania hasła."
Czyli jak rozumiem użytkownik zostaje wtedy zalogowany ?
Tak.
Najprościej jak poeksperymentujesz. Stwórz sobie bazę i prosty formularz i do wykonywania poleceń użyj pokazanej wyżej naggannej metody.
Taka dygresja, SQL injection jest w dzisiejszych czasach możliwy do przeprowadzenia? Przecież wszystkie potężne technologie jak spring, Asp.net czy ef domyślnie są odporne na takie zaniedbania. Chyba, że ktoś klepie w PHP....
@Damian Pawelec: Niestety jest. Nie każdy podbija wersję na serwerze, albo używa funkcji do łączenia się z bazą, których nie powinno się używać np. https://www.php.net/manual/en/function.mysql-connect.php - jest usuwana dopiero w 7.0.0
Damian Pawelec napisał(a):
Taka dygresja, SQL injection jest w dzisiejszych czasach możliwy do przeprowadzenia? Przecież wszystkie potężne technologie jak spring, Asp.net czy ef domyślnie są odporne na takie zaniedbania. Chyba, że ktoś klepie w PHP....
A dlaczego nie można ciągle skleić ręcznie zapytania i wykonać? Jaki problem ominąć wszystkie parametryzacje jeśli nie wie się czym to skutkuje? Spring nie pozwala na wykonanie ręcznie zrobionych zapytań?
Damian Pawelec napisał(a):
Taka dygresja, SQL injection jest w dzisiejszych czasach możliwy do przeprowadzenia? Przecież wszystkie potężne technologie jak spring, Asp.net czy ef domyślnie są odporne na takie zaniedbania. Chyba, że ktoś klepie w PHP....
Nadal jest możliwe, bo niestety nadal spora rzesza programistów nie rozumie tego typu ataków, i jeśli ktoś pisze ręcznie query oraz nie weźmie tego pod uwagę to to jest możliwe.