Systemy bezpieczeństwa chronią przed atakami typu SQL injection tylko w ograniczonym zakresie. Na rynku pojawiły się już specjalizowane narzędzia do tego typu zabezpieczeń.

W poprzednim numerze Computerworld opisano technikę ataku na aplikacje internetowe sprzężone z bazą danych. Przypomnijmy: atak typu SQL injection polega na manipulacji parametrami dostępnymi np. w adresie URL, formularzu HTML/XML czy nagłówkach HTTP poprzez wprowadzenie do zapytania do bazy danych spreparowanego ciągu znaków. Mogą to być: gotowe wyrażenie SQL, sekwencja komend specyficznego dla danej bazy/platformy języka DML (Data Manipulation Language) lub odwołanie do procedury składowanej. Skutkiem ataku jest nieautoryzowany odczyt, modyfikacja lub wykasowanie danych w bazie, a nawet zmiana sposobu działania aplikacji.

Skromne środki obrony

Czy atakom typu SQL injection można zapobiegać? Tak, ale przede wszystkim na etapie projektowania i kodowania aplikacji. Podstawowe wskazówki dla twórców aplikacji i skryptów zawarto w poprzednim artykule. Jeżeli jednak aplikacja nie została odpowiednio zabezpieczona przez programistów, administratorzy gotowego rozwiązania mają bardzo ograniczone możliwości przeciwdziałania zagrożeniu. Zwłaszcza wtedy, gdy w firmie wdrożono system, którego kodu nie można swobodnie modyfikować.

Atakom na aplikacje WWW, w tym również atakom SQL injection, nie zapobiegają typowe środki bezpieczeństwa działające na poziomie sieci IP - proste systemy zaporowe (firewall). Poza tym systemy te mogą analizować jedynie jawnie przesyłane dane, a nie dane szyfrowane, jak ma to często miejsce między serwerem WWW a przeglądarką. Z tego samego powodu problematyczne jest zastosowanie systemów typu IDS.

Wobec tego rodzaju ataków bezradne są też zwykle oparte na sygnaturach systemy antywirusowe i filtry treści. Sygnatury tworzone są bowiem dla standardowych aplikacji, a nie dla jednostkowych rozwiązań. To, że konkretne rozwiązania składają się ze standardowych komponentów, nie ma większego znaczenia. Ataki SQL injection nie wykorzystują błędów w oprogramowaniu, lecz błędy w jego konfiguracji.

Istnieje kilka sposobów, by zagrożenie atakiem SQL injection zredukować i to niezależnie od platformy systemowej/bazodanowej czy też rodzaju kodu uruchamianego na serwerze, np. JSP, ASP, PHP itp. Trzeba jednak zaznaczyć, że choć metody te podnoszą poprzeczkę dla włamywaczy, nie są one skuteczne w 100% - każda z nich ma ograniczenia. Działania zapobiegawcze zostaną przedstawione na przykładzie systemu zaporowego Check Point Firewall-1 i systemu typu application firewall NGSecureWeb.

Anatomia ataku

Wyświetlana w przeglądarce strona WWW pobiera od użytkownika dane - zwykle za pośrednictwem formularza, choć może to być także np. kliknięcie na określonej części strony lub wybranie pozycji z rozwijanego menu. Część danych może też być pobierana bez interakcji z użytkownikiem, np. wprost z nagłówków protokołu HTTP. Przekazanie wprowadzonych danych do serwera odbywa się przez wywołanie jakiegoś skryptu lub procedury po stronie serwera. Protokół HTTP udostępnia dwie podstawowe metody odwoływania się do serwera WWW: GET i POST. Podstawowa metoda komunikacji przeglądarki z serwerem to polecenie GET (pobierz). Składnia jest następująca:

GET /sciezka/plik?parametr1=wartosc1&parametr2=wartosc2

Całe wywołanie: METODA /sciezka/plik?parametry nosi nazwę URI (Universal Resource Identifier). W powyższym przykładzie jest wywoływany plik zawierający skrypt przetwarzający wprowadzone dane. Same dane są przekazywane w parametrach:

GET /search/search_form1.jsp?product=komputer&lang=pl

Druga metoda - polecenie POST (wyślij) - jest wykorzystywana, gdy zachodzi konieczność przesłania do serwera większej ilości danych. Składnia jest taka sama jak w metodzie GET, jednak po wywołaniu, skrypt po stronie serwera przyjmuje parametry również na standardowe wejście:

POST /search/search_form2.jsp

product=komputer&lang=pl

Skrypt po stronie serwera (w tym przykładzie search_form2.jsp) pobierze parametry z następnych danych przesłanych w sesji HTTP, a nie z linii parametrów. POST może pobierać parametry zarówno w powyższy, charakterystyczny dla tej metody sposób, jak i analogicznie do metody GET. Możliwe jest mieszanie tych metod, np.:

POST /search/search_form2.jsp?product=komputer

lang=pl

Wywołany skrypt lub procedura przetwarza parametry otrzymane od przeglądarki i konstruuje na ich podstawie zapytanie SQL, które baza danych wykonuje z uprawnieniami, jakie narzucił programista. Po wykonaniu operacji, jej rezultat jest ponownie przetwarzany przez skrypt wywołujący - w ten sposób powstaje zwracany do przeglądarki kod HTML. Jak widać, niewiele zależy tu od administratora - praktycznie o wszystkim decyduje programista.