Każde pole w tabeli MySQL ma określony typ. Dla varchar możemy zdefiniować maksymalną długość przechowywanego tekstu. Ale co w przypadku, gdy użytkownik prześle dłuższy ciąg? #od0dopentestera
W przypadku konstrukcji INSERT dane zostaną automatycznie przycięte do maksymalnej długości danego pola. To nic odkrywczego, ale mało kto wie, że standardowo baza ignoruje spacje na końcu wyrazu:
SELECT * FROM users WHERE login = "admin "
Dostaniemy takie same wyniki jak dla zapytania bez białych znaków na końcu. Te dwie ciekawostki połączone razem mogą doprowadzić do błędu SQL Truncation. Chociażby podczas logowania użytkowników.
Załóżmy, że maksymalna długość pola login to 10 znaków. Podczas tworzenia nowego użytkownika najpierw sprawdzamy, czy osoba o takich danych już nie istnieje w bazie. Jeżeli nie - tworzymy nowy rekord.
Nie możemy użyć wartości admin ze spacjami, ponieważ są one ignorowane w konstrukcji SELECT. A taki użytkownik już istnieje. A co gdyby spróbować dłuższy rekord? Taki, którego pierwsze 10 znaków kończy się spacjami a reszta to nieistotne dane? Chociażby **admindalszy_ciąg**? Wspomniany wyżej SELECT nie zwróci żadnego rekordu dla takiego loginu. Podczas dodawania wpisu natomiast zostanie on przycięty do 10 znaków.
Tym samym pojawią się dwa rekordy admin - jeden z białymi znakami drugi bez. Jeżeli teraz aplikacja sprawdza uprawnienia użytkowników na podstawie loginu - istnieje spora szansa, że również ignoruje spacje. Możemy zatem zalogować się jako administrator używając swojego hasła.
Jak można rozwiązać ten problem? Używać indeksu UNIQUE, który zapewnia brak duplikatów.
@Lehu31: @DrwalPuchacz: mowilem tylko i wylacznie o spacji po stringu tez wiekszosc aplikacji uzywa ORM ktory sam z siebie dba o takie rzeczy (czy to entity czy hibernate)
Dla
varcharmożemy zdefiniować maksymalną długość przechowywanego tekstu.Ale co w przypadku, gdy użytkownik prześle dłuższy ciąg? #od0dopentestera
W przypadku konstrukcji
INSERTdane zostaną automatycznie przycięte do maksymalnej długości danego pola.To nic odkrywczego, ale mało kto wie, że standardowo baza ignoruje spacje na końcu wyrazu:
SELECT * FROM users WHERE login = "admin "
Dostaniemy takie same wyniki jak dla zapytania bez białych znaków na końcu.
Te dwie ciekawostki połączone razem mogą doprowadzić do błędu SQL Truncation.
Chociażby podczas logowania użytkowników.
Załóżmy, że maksymalna długość pola
loginto 10 znaków.Podczas tworzenia nowego użytkownika najpierw sprawdzamy, czy osoba o takich danych już nie istnieje w bazie.
Jeżeli nie - tworzymy nowy rekord.
Nie możemy użyć wartości
adminze spacjami, ponieważ są one ignorowane w konstrukcjiSELECT.A taki użytkownik już istnieje. A co gdyby spróbować dłuższy rekord?
Taki, którego pierwsze 10 znaków kończy się spacjami a reszta to nieistotne dane?
Chociażby **admindalszy_ciąg**?
Wspomniany wyżej SELECT nie zwróci żadnego rekordu dla takiego loginu.
Podczas dodawania wpisu natomiast zostanie on przycięty do 10 znaków.
Tym samym pojawią się dwa rekordy
admin- jeden z białymi znakami drugi bez.Jeżeli teraz aplikacja sprawdza uprawnienia użytkowników na podstawie loginu - istnieje spora szansa, że również ignoruje spacje.
Możemy zatem zalogować się jako administrator używając swojego hasła.
Jak można rozwiązać ten problem?
Używać indeksu
UNIQUE, który zapewnia brak duplikatów.Interesujesz się bezpieczeństwem? Posłuchaj podcastu na Google i Apple Podcasts oraz Spotify i Anchor.
Subskrybuj kanał na YouTube
Masz pytanie na temat security? Zadaj je na grupie od 0 do pentestera na Facebooku.
Jeżeli chcesz być wołany do podobnych wpisów na Mirko dodaj się do Mirkolisty.
#bezpieczenstwo #programowanie #informatyka #it #nauka #technologia #ciekawostki #podcast #swiat #gruparatowaniapoziomu #biznes #security
tez wiekszosc aplikacji uzywa ORM ktory sam z siebie dba o takie rzeczy (czy to entity czy hibernate)