Ataki typu SQL Injection stanowią olbrzymie zagrożenie dla aplikacji internetowych, które zależą od zaplecza bazy danych w celu generowania dynamicznej zawartości. W tego typu atakach hakerzy manipulują aplikacją sieci Web próbując wstrzyknąć własne komendy SQL do tych wydanych przez bazę danych. Aby zapoznać się z przykładem, zobacz artykuł Atakowanie iniekcyjne SQL w bazach danych. W tym artykule przyjrzymy się kilku sposobom testowania aplikacji internetowych w celu określenia, czy są one podatne na ataki SQL Injection.
Automatyczne skanowanie iniekcji SQL
Jedną z możliwości jest użycie automatycznego narzędzia do skanowania aplikacji internetowych, takiego jak WebInspect firmy HP, aplikacja AppScan firmy IBM lub program Hailstorm firmy Cenzic. Wszystkie te narzędzia umożliwiają łatwe, zautomatyzowane analizowanie aplikacji internetowych pod kątem potencjalnych luk SQL Injection. Są one jednak dość drogie i wynoszą nawet 25 000 USD na miejsce.
Ręczne testy SQL Injection
Co powinien zrobić biedny programista? Możesz przeprowadzić kilka podstawowych testów, aby ocenić aplikacje internetowe pod kątem luk SQL Injection, używając jedynie przeglądarki internetowej. Po pierwsze, należy zachować ostrożność: testy, które opisujemy, wyszukują tylko podstawowe błędy SQL Injection. Nie będą wykrywać zaawansowanych technik i są dość męczące w użyciu. Jeśli możesz sobie na to pozwolić, skorzystaj ze skanera automatycznego. Jeśli jednak nie możesz sobie z tym poradzić, testowanie ręczne to świetny pierwszy krok.Najprostszym sposobem oceny, czy dana aplikacja jest podatna na ataki, jest eksperymentowanie z nieszkodliwymi atakami, które nie zaszkodzą twojej bazie danych, jeśli ci się uda, ale dostarczą dowodów, że potrzebujesz rozwiązania problemu. Załóżmy na przykład, że masz prostą aplikację internetową, która wyszukuje osoby w bazie danych i w rezultacie podaje informacje kontaktowe. Ta strona może używać następującego formatu adresu URL: http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike
Możemy założyć, że ta strona wykonuje wyszukiwanie w bazie danych, używając zapytania podobnego do następującego: WYBIERZ telefon
Z katalogu
WHERE lastname = 'chapple' i firstname = 'mike'
Spróbujmy trochę tego eksperymentować. Z naszym założeniem powyżej możemy dokonać prostej zmiany adresu URL, który testuje ataki SQL injection: http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1
Jeśli aplikacja internetowa nie została odpowiednio zabezpieczona przed iniekcją SQL, po prostu podłącza to fałszywe imię do instrukcji SQL, którą wykonuje względem bazy danych, co skutkuje: WYBIERZ telefon
Z katalogu
WHERE lastname = 'chapple' i firstname = 'mike'
AND (wybierz liczbę (*) z fałszywego)> 0
OR "1" = "1"
Zauważysz, że powyższa składnia jest nieco inna niż w oryginalnym adresie URL. Wykorzystaliśmy zmienną URL-ową dla ich odpowiedników ASCII, aby ułatwić podążanie za przykładem. Na przykład% 3d to kodowanie URL dla znaku "=". Dodaliśmy również kilka linii podziału dla podobnych celów. Test przychodzi, gdy próbujesz wczytać stronę z podanym wyżej adresem URL. Jeśli aplikacja internetowa jest dobrze zachowana, usunie pojedyncze cudzysłowy z danych wejściowych przed przekazaniem zapytania do bazy danych. Spowoduje to po prostu dziwne wyszukiwanie dla kogoś z imieniem, które zawiera kilka SQL. W aplikacji pojawi się komunikat o błędzie podobny do poniższego: Błąd: nie znaleziono użytkownika o mike + AND + (wybierz + count (*) + from + fake) +% 3e0 + OR + 1% 3d1
Chapple!
Z drugiej strony, jeśli aplikacja jest podatna na iniekcje SQL, przekazuje ją bezpośrednio do bazy danych, co daje jedną z dwóch możliwości. Po pierwsze, jeśli twój serwer ma włączone szczegółowe komunikaty o błędach (których nie powinieneś), zobaczysz coś takiego: Microsoft OLE DB Provider dla sterowników ODBC błąd "80040e37"
Microsoft Sterownik ODBC SQL Server Serwer SQL Niepoprawna nazwa obiektu "fałszywy".
/directory.asp, wiersz 13
Z drugiej strony, jeśli serwer WWW nie wyświetla szczegółowych komunikatów o błędach, pojawi się bardziej ogólny błąd, na przykład: Wewnętrzny błąd serweraSerwer napotkał błąd wewnętrzny lub błędną konfigurację i nie był w stanie ukończyć żądania.
Skontaktuj się z administratorem serwera, aby poinformować o czasie wystąpienia błędu i o wszystkim, co mógłbyś zrobić, co mogło spowodować błąd.
Więcej informacji o tym błędzie może być dostępnych w dzienniku błędów serwera.
Jeśli otrzymasz jeden z dwóch powyższych błędów, Twoja aplikacja będzie podatna na atak SQL injection. Niektóre kroki, które można podjąć w celu ochrony aplikacji przed atakami SQL Injection obejmują: Ocena wyników
