SQL injection w formularzu zapisu

SQL injection w formularzu zapisu to luka pozwalająca wstrzyknąć złośliwe polecenie przez niefiltrowane pole danych.

Jak powstaje SQL injection w formularzu zapisu

SQL injection w formularzu zapisu występuje wtedy, gdy dane wpisane przez użytkownika trafiają do zapytania SQL w sposób pozwalający zmienić jego strukturę. Problem nie polega na samym użyciu formularza, lecz na niebezpiecznym połączeniu wartości wejściowej z tekstem zapytania. Przykładem może być formularz rejestracji, logowania, dodawania komentarza, zapisu adresu kontaktowego albo wyszukiwania rekordu. Jeżeli aplikacja buduje zapytanie przez konkatenację ciągów znaków, fragment danych może zostać potraktowany jako składnia SQL, a nie jako zwykły tekst.

Podatność może dotyczyć pola tekstowego, identyfikatora, adresu poczty elektronicznej, numeru zamówienia lub innej wartości przesyłanej metodą GET albo POST. Samo filtrowanie znaków, takich jak apostrof, nie stanowi pewnej ochrony, ponieważ skuteczność takiego rozwiązania zależy od kontekstu zapytania, sposobu kodowania danych i konkretnego sterownika bazy. Dodatkowym problemem jest używanie jednego mechanizmu do wielu miejsc, w których dane są umieszczane w różnych częściach instrukcji SQL.

Skutki zmiany zapytania przez dane formularza

Zakres skutków zależy od uprawnień konta bazy danych, rodzaju wykonywanego zapytania oraz sposobu obsługi błędów przez aplikację. W najprostszym przypadku atakujący może obejść warunek wyszukiwania albo uzyskać rekordy, które powinny być dostępne dopiero po poprawnym uwierzytelnieniu. W formularzu zapisu może również dojść do dopisania nieautoryzowanych wartości, zmiany istniejących danych lub przerwania instrukcji przez wprowadzenie znaków powodujących błąd składni.

Jeżeli aplikacja wykonuje więcej niż jedno polecenie w ramach jednego żądania i sterownik na to pozwala, podatność może mieć szerszy zasięg. Nie oznacza to jednak automatycznie możliwości wykonania dowolnej operacji: ograniczenia wynikają między innymi z uprawnień użytkownika bazy, konfiguracji połączenia oraz sposobu parametryzacji. Błąd może być widoczny jako komunikat składni SQL, kod odpowiedzi HTTP 500, nieoczekiwane przekierowanie albo zapis danych różniących się od wartości przesłanych w formularzu. Brak komunikatu błędu nie potwierdza bezpieczeństwa, ponieważ aplikacja może ukrywać szczegóły i zwracać tylko ogólny komunikat.

Parametryzacja i walidacja jako właściwa ochrona

Podstawową metodą usunięcia SQL injection jest używanie zapytań parametryzowanych, w których instrukcja SQL i wartości wejściowe są przekazywane osobno. Sterownik bazy danych może wtedy rozpoznać wartość jako dane, nawet gdy zawiera apostrof, średnik lub ciąg znaków przypominający składnię SQL. Parametryzacja powinna obejmować każde pole pochodzące z formularza, także wartości pozornie niegroźne, takie jak identyfikator lub nazwa kategorii. Nie należy zastępować jej ręcznym dopisywaniem cudzysłowów i usuwaniem wybranych znaków.

Walidacja danych pełni inną funkcję. Powinna sprawdzać typ, długość, wymagany format oraz zakres wartości, na przykład czy identyfikator jest liczbą całkowitą, a pole daty ma oczekiwany zapis. Walidacja ogranicza błędne i niepożądane dane, lecz sama nie zastępuje parametrów zapytania. Nazwy kolumn, tabel lub kierunki sortowania, których nie można przekazać jako zwykłych parametrów, powinny być wybierane z zamkniętej listy dozwolonych wartości. Pomocne są również ograniczone uprawnienia konta aplikacyjnego, jednolita obsługa błędów oraz rejestrowanie nieudanych operacji bez ujawniania składni SQL użytkownikowi.

Sprawdzenie formularza po zmianie kodu

Diagnostyka powinna obejmować analizę miejsca, w którym dane z formularza są odbierane, przekształcane i przekazywane do warstwy dostępu do bazy. Należy sprawdzić wszystkie warianty zapisu, walidację po stronie serwera, ścieżki obsługi wyjątków oraz zapytania wykonywane pośrednio przez biblioteki lub własne funkcje pomocnicze. Szczególną uwagę trzeba zwrócić na pola używane w filtrach, sortowaniu, wyborze tabeli i budowaniu warunków, ponieważ mogą być obsługiwane inaczej niż zwykłe wartości tekstowe.

Testy bezpieczeństwa powinny potwierdzić, że znaki specjalne i ciągi przypominające instrukcję SQL są zapisywane albo odrzucane jako dane, a nie interpretowane jako polecenie. Warto sprawdzić także pustą wartość, bardzo długi tekst, nieprawidłowy typ, wielokrotne kodowanie oraz żądania wysłane bez interfejsu graficznego. Po wdrożeniu poprawki należy przejrzeć logi aplikacji i bazy pod kątem powtarzających się błędów składni, nietypowych wzorców żądań oraz nieoczekiwanych zmian w tabelach. W przypadku podejrzenia rzeczywistego wykorzystania podatności potrzebne jest odtworzenie zakresu zdarzenia na podstawie dostępnych logów, kopii zapasowych i historii zmian, a nie tylko usunięcie pojedynczego komunikatu błędu.