Wyobraź sobie – masz serwis internetowy, ktoś włamuje się do Twojej bazy danych, a następnie wykrada wrażliwe dane Twoich klientów. Pierwszą rzeczą jaką musisz zrobić to znaleźć źródło problemu. Czyli inaczej mówiąc jakąś lukę/wyrwę, którą wykorzystał haker by włamać się na Twoją stronę.
SQL injection nie jest żadną nowością i towarzyszy nam już od ponad 10 lat, większość firm inwestuje ogromne środki w systemy wykrywania i zapobiegania włamaniom do sieci, firewalle, bramki bezpieczeństwa oraz oprogramowanie antywirusowe. Częstotliwość ataków na aplikacje webowe rośnie w zastraszającym tempie i większość zespołów odpowiedzialnych w firmach za bezpieczeństwo skupia się na ochronie sieci, a nie kluczowych danych biznesowych, które faktycznie znajdują się w bazach danych. Oczywiście do czasu kiedy nastąpi włamanie.
Na czym polega SQL injection?
SQL injection to bardzo prosta i łatwa do wykonania forma ataku. Zasadniczo, polega ona na tym, że atakujący wprowadza instrukcję SQL w odpowiednim polu internetowego formularza kontaktowego i próbuje dzięki niej zmodyfikować, wydobyć, dodać lub usunąć informacje znajdujące się w bazie danych.
Michael Giagnovoco wykorzystuje prostą analogię: idziemy do sądu, gdzie rejestrujemy swoje imię jako „Krzysztofie, jesteś wolny, możesz wyjść”. Kiedy więc sędzia zwraca się do nas po imieniu „Krzysztofie, jesteś wolny, możesz wyjść”, pomocnik sądowy wypuszcza nas z sali, gdyż sędzia dał mu właśnie do zrozumienia, że może to uczynić.
W tym przykładzie instrukcja „jesteś wolny, możesz wyjść” została wstrzyknięta (ang. „injection”) do pola w formularzu, które zostało przeznaczone do przechowywania jedynie informacji o imieniu. Spowodowało to, że niepożądane dane zinterpretowano jako instrukcję, którą należy wykonać. Tak właśnie wygląda idea, na której opiera się działanie ataków typu SQL injection.
Atak, co dalej?
Przełamywanie zabezpieczeń aplikacji metodą SQL injection może być traktowane jako sposób na pozyskanie danych, ale może także stanowić wstęp do innych działań. Przykładem może być przejęcie kontroli nad aplikacją i zmiana publikowanych tam treści. Aby takie działanie było możliwe, witryna musi być podatna nie tylko na wykonywanie zainfekowanych poleceń SELECT. Trzeba znaleźć też sposób na wprowadzenie „z zewnątrz” poleceń INSERT lub UPDATE.
Prześledźmy bez zagłębiania się w zbytnie szczegóły scenariusz innego wykorzystania SQL injection. Naszym celem jest nie tyle bezpośrednia eksploracja danych dzięki uzyskaniu nieautoryzowanego dostępu do bazy. Chcemy raczej otworzyć sobie drogę do dalszych hakerskich działań. W pierwszym kroku haker modyfikuje zapytanie SQL – tak, aby dodać do wybranych pól tekstowych bazy danych element IFRAME HTML. IFRAME zawiera przekierowanie do serwera zawierającego potrzebne hakerowi do dalszych działań elementy złośliwego oprogramowania (malware). W chwili gdy użytkownik zainfekowanej aplikacji odczyta z bazy zmodyfikowaną zawartość pola tekstowego, nieświadom niczego ściągnie na swój komputer Trojana lub oprogramowanie rejestrujące pracę klawiatury. Dalsze działania hakera będą zależały oczywiście od celu ataku, ale droga do pozyskania wszystkich informacji „przepływających” przez nasz komputer stoi otworem. Niestety wszystkie te działania są dla użytkownika zupełnie „niewidoczne”. W czasie gdy Web browser renderuje stronę HTML, którą chcieliśmy wyświetlić, niejako „w tle” pobieramy również złośliwe oprogramowanie, które udaje część niezbędną do wyświetlenia oczekiwanej przez nas strony. Innym sposobem ataku „skojarzonego” z SQL injection jest Denial of Service (DoS). Konsekwencją takiego ataku może być zajęcie bazy jakimś dużym zapętlonym zapytaniem lub nawet wydanie bazie polecenia SHUTDOWN. Generalnie rzecz biorąc, celem takiego ataku jest zatrzymanie bazy danych
Jak się bronić?
Trzeba sprawdzać szczelność zabezpieczeń i "łatać dziury". Może nie brzmi to optymistyczne, ale działanie takie wydaje się wykonalne – pod warunkiem, że nasza firma posiada kody użytkowane aplikacji lub może taką pracę zlecić firmie będącej autorem rozwiązania. Mniej optymistyczne jest natomiast to, że jest to proces ciągły. Zabezpieczenie się przed jednym typem podatności wywołuje wynalezienie innego sposobu, przed którym znów musimy się bronić. Jest to zatem proces absorbujący sporo sił i środków, wymagający cyklicznego przygotowywania i wgrywania kolejnych poprawek. Nieco prościej jest, jeśli nasza aplikacja jest produktem „z półki”. Wtedy możemy oczekiwać, że praca ta zostanie wykonana po stronie jej twórców, a my jako klienci otrzymamy możliwie szybko kolejne patche.
Bezsprzecznie bardziej zaawansowanym technologicznie rozwiązaniem są pakiety chroniące przed SQL injection bez konieczności przejścia etapu „uczenia”, czyli ręcznego strojenia zasad filtracji. Jest to możliwe dzięki jednoczesnemu zastosowaniu modelu białych i czarnych list (dynamic positive – white list i dynamic negative – black list). Skutecznym środkiem prewencji jest również jednoczesne stosowanie pakietu SecureSphere; jest to rozwiązanie wielowarstwowe, poszukujące śladów prób włamania na wielu płaszczyznach: walidacji HTTP, sygnatur IPS, czy mechanizmów Dynamic Profiling. Dla przykładu: zadaniem modułu Dynamic Profiling jest śledzenie aktywności użytkowników i tworzenie schematów poprawnego wykorzystywania aplikacji. Schematy te służą następnie jako baza do porównania zapytań kierowanych do bazy i wyłapywania takich, jakie jeszcze nigdy nie były wykonywane – są więc potencjalnie niebezpieczne. Oczywiście moduł ten uczy się ciągle i reaguje na ewentualne zmiany w funkcjonalności monitorowanej aplikacji.
.jpeg)
