Atak skrócenia SQL

Podatność na obcięcie SQL występuje, gdy baza danych ściska wejście użytkownika z powodu ograniczenia długości. Atakujący mogą gromadzić informacje o długości pola krytycznego (takiego jak nazwa użytkownika) i wykorzystać te informacje, aby uzyskać nieautoryzowany dostęp. Atakujący mogą logować się jako inny użytkownik, taki jak admin, z własnym zarejestrowanym hasłem.

Podatność na obcięcie SQL zwykle istnieje w bazach danych MySQL. Ta podatność została po raz pierwszy opisana w CVE-2008-4106, która była związana z WordPress CMS.

Jak działają ataki obrotowe SQL

Ten atak działa z powodu obcięcia danych wejściowych użytkownika w bazach danych za pomocą funkcji „Wybór” i „Wstawienie”.

• Gdy wejście jest podane w polu formularza, funkcja „Wybierz” sprawdza nadmiarowość odpowiadającą wejściom w bazie danych.
• Po sprawdzeniu redundancji funkcja „wstawienia” sprawdza długość wejścia, a wejście użytkownika obcinnie, jeśli długość przekroczy.

Załóżmy, że programista tworzy tabelę „użytkowników” za pomocą następującego zapytania:

Utwórz użytkowników tabeli (
user_id int not null auto_increment,
User_name varchar (20) nie null,
Hasło varchar (40) nie null,
Klucz podstawowy (user_id)
);

Korzystając z tego schematu, jeśli programista tworzy konto administracyjne z następującymi:

User_name = 'admin' '
hasło = „Secret_P4SSW0ord”

Oczywiście te referencje nie są publiczne. W bazie danych jest tylko jedno konto administracyjne, a jeśli atakujący próbuje zarejestrować inne konto w nazwie użytkownika „administratora”, atakujący zawiedzie z powodu kontroli nadmiarowości bazy danych. Atakujący może nadal ominąć tę kontrolę nadmiarowości, aby dodać kolejne konto administratora, wykorzystując podatność na obcięcie SQL. Załóżmy, że atakujący rejestruje inne konto z następującym wejściem:

User_name = 'adminxxxxxxxxxxxxxxxxrandom'
(x to przestrzenie)
I
Hasło = ”RandomUser”

Baza danych weźmie „nazwę_ser_name” (26 znaków) i sprawdzi, czy już to istnieje. Następnie wejście nazwa_ser_name zostanie obcięte, a „admin” („admin” z przestrzenią) zostanie wprowadzony w bazie danych, w wyniku czego dali dwóch zduplikowanych użytkowników administratora.

Atakujący jest w stanie utworzyć użytkownika „administratora” z własnym hasłem. Teraz baza danych ma dwa wpisy administratora „użytkownika_name”, ale z różnymi hasłami. Atakujący może zalogować się z nowo utworzonymi poświadczeniami, aby uzyskać panel administracyjny, ponieważ zarówno „admin” i „administrator” użytkownika, jak i „administrator” są równe dla poziomu bazy danych. Teraz spojrzymy na przykładowy atak praktyczny.

Przykładowy atak

W tym przykładzie weźmiemy scenariusz ze strony witryny Overterwire.org. Społeczność OvermeWire zapewnia Wargame CTF, na których możemy praktykować nasze koncepcje bezpieczeństwa. Scenariusz obcięcia SQL występuje na poziomie gry Natas 26-> 27. Możemy uzyskać dostęp do poziomu za pomocą następujących czynności:

URL: http: // natas27.Natas.laboratoria.OvermeWire.org
Nazwa użytkownika: NATAS27
Hasło: 55TBJPZUUJGVP5B3BNBG6ON9UDPVZCJ

Ten poziom jest dostępny pod adresem: https: // obciąża.org/wargames/natas/natas27.html. Zostaniesz wyświetlona strona logowania, która jest podatna na atak obrotowy SQL.

Po sprawdzeniu kodu źródłowego zobaczysz, że długość nazwy użytkownika wynosi 64, jak pokazano poniżej.

Użytkownik o imieniu „NATAS28” już istnieje. Naszym celem jest utworzenie innego użytkownika o nazwie „NATAS28” za pomocą ataku SQL_TRUNCation. Zatem wprowadzimy NATAS28, a następnie 57 przestrzeni i losowy alfabet (w naszym przypadku A), nazwa użytkownika i każde hasło. Litera „A” nie jest widoczna na zrzucie ekranu ze względu na nazwę użytkownika o długości 65 znaków. Po utworzeniu konta użytkownika będziesz mógł zobaczyćA.'

Jeśli baza danych zawiera podatność SQL_Truncation, wówczas baza danych powinna mieć teraz dwie nazwy użytkowników „NATAS28”. Jedna nazwa użytkownika będzie zawierać nasze hasło. Spróbujmy wprowadzić poświadczenia na stronie logowania.

Teraz jesteśmy zalogowani jako użytkownik „NATAS28”.

Łagodzenie

Aby złagodzić ten atak, będziemy musieli rozważyć wiele czynników.

• Nie powinniśmy zezwolić na powielanie krytycznych tożsamości, takich jak nazwa użytkownika. Powinniśmy uczynić te tożsamości podstawowe klucze.
• Funkcja obcięcia powinna być zaimplementowana dla wszystkich pól formularzy frontendowych, a także kodu zaplecza, aby bazy danych otrzymywały obcięte wejścia.
• Tryb ścisłego powinien być włączony na poziomie bazy danych. Bez włączenia trybu ścisłego bazy danych podają ostrzeżenia tylko w backendzie, ale nadal zapisują zduplikowane dane. W trybie ścisłym bazy danych podają błędy w przypadku duplikacji i unikaj zapisywania danych.

Na przykład sprawdźmy tryb ścisłego za pomocą następującego zapytania:

mysql> Wybierz @@ sql_mode

Utworzymy bazę danych i użytkowników tabeli.'

mysql> Utwórz test bazy danych
Zapytanie OK, dotknięty 1 rząd (0.02 s)
Mysql> Użyj testu
Baza danych zmieniła się
MySQL> Utwórz użytkowników tabeli (nazwa użytkownika varchar (10), hasło varchar (10));
Zapytanie OK, 0 dotkniętych wierszy (0.05 s)

Następnie utworzymy użytkownika administratora z poświadczeniami za pomocą zapytania Wstaw.

MySQL> Wstaw do wartości użytkowników („admin”, „hasło1”);
Zapytanie OK, dotknięty 1 rząd (0.01 s)

Możemy zobaczyć informacje o tabeli „Użytkownicy” za pomocą opcji „Wybierz * od użytkowników”.

Długość nazwy użytkownika to 10 znaków. Teraz spróbujemy ataku obcięcia SQL.

Kiedy próbujemy wprowadzić następujące czynności:

Nazwa użytkownika = 'adminxxxxxa'
(x to przestrzenie)
I
Hasło = „pass2”

Otrzymamy błąd, co oznacza, że ​​tryb ścisłego jest całkowicie skuteczny.

mysql> wstaw do wartości użytkowników („admin a”, „pass2”)
Błąd 1406 (22001): Dane zbyt długie dla kolumny „nazwa użytkownika” w wierszu 1

Bez włączonego trybu ścisłego baza danych wyświetli ostrzeżenia, ale nadal będzie wstawić dane w tabeli.

Wniosek

Atakerzy mogą uzyskać dostęp do konta o dużej liście, jeśli w Twojej aplikacji istnieje podatność SQL_TRunction. Atakujący może łatwo uzyskać informacje o nazwie użytkownika i długości jej bazy danych przy użyciu pól krytycznych, a następnie utworzyć tę samą nazwę użytkownika, a następnie przestrzenie i losowy alfabet po minimalnej długości, co spowodowało utworzenie wielu konta o dużej liczbie osób. Ta podatność jest krytyczna, ale można jej uniknąć, jeśli podejmiesz pewne środki bezpieczeństwa, takie jak aktywacja trybu ścisłego dla wejść użytkowników i uczynienie pola wrażliwego kluczowym kluczowym kluczem w bazie danych.