Czym jest SQL injection?

Wstęp

Czym jest SQL injection?

To jedna z dość częstych i jednocześnie niebezpiecznych podatności w aplikacjach webowych (oraz niewebowych). Nie bez powodu SQL injection należy do pierwszej (A1) z dziesięciu kategorii błędów  wymienianych w dokumencie OWASP Top Ten. Już sama nazwa wskazuje na rodzaj problemu – atakujący wstrzykuje do aplikacji (nieautoryzowany) fragment zapytania SQL. Wstrzyknięcie zazwyczaj możliwe jest z jednego powodu – braku odpowiedniego sprawdzenia (walidacji) parametru przekazanego przez użytkownika. Taki parametr, gdy mamy do czynienia z SQL injection, często przekazywany jest bezpośrednio do zapytania SQL.

Czym to może skutkować?

W zależności od sytuacji możemy mieć do czynienia z:

• nieautoryzowanym dostępem w trybie odczytu lub zapisu do całej bazy danych,
• możliwością ominięcia mechanizmu uwierzytelnienia,
• możliwością odczytania wybranych plików (system operacyjny, na którym pracuje baza danych),
• możliwością tworzenia plików w systemie operacyjnym, na którym pracuje baza,
• możliwością wykonania kodu w systemie operacyjnym (uprawnienia użytkownika, na którym pracuje baza lub web serwer – w przypadku aplikacji webowych).

Przykład praktyczny

Zobaczmy, jaka jest istota tej podatności na przykładzie prostej aplikacji napisanej w języku PHP, komunikującej się z bazą danych MySQL z wyświetleniem szczegółów newsa (przy okazji zaznaczam, że podatność nie jest ograniczona tylko do języka PHP czy MySQL).

W normalnym użyciu wyświetlenie newsa odbywa się poprzez odwołanie do URL-a: http://192.168.0.105/news_detail.php?id=1&action=view

Aplikacja wykonuje wtedy następujące czynności (kliknij dwa razy, aby powiększyć):

Co się jednak stanie w przypadku, gdy zmodyfikujemy wartość zmiennej id?

Na przykład w ten sposób:

http://192.168.0.105/news_detail.php?id=-1 union select version(),2–&action=view.

Zobaczmy:

Okazuje się, że w tym przypadku można było odczytać wynik funkcji bazodanowej version()!

Na podobnej zasadzie można tu również odczytać wybrane pliki z filesystemu:

Analogicznie możliwe jest również pobranie danych z zupełnie innej tabeli niż oryginalna 'news’.

Na przykład można pobrać login oraz hasła z tabeli 'users’:

Jak z kolei będzie wyglądać sytuacja w przypadku, gdy nie mamy do czynienia ze zmienną liczbową tylko ze stringiem?

Zobaczmy na przykładzie formularza logowania:

W tym przypadku udało się zalogować na użytkownika 'admin’ bez znajomości jego hasła.

W jaki sposób można zalogować się na innego użytkownika? Patrząc na diagram powyżej, należałoby wybrać nie pierwszego z brzegu, a kolejnego użytkownika z tabeli 'users’:

Ochrona

Nawet w tak skrótowym tekście warto poświęcić kilka słów ochronie przed SQL injection.

W jaki sposób się ochronić?

Mówiąc w dużym skrócie – w odpowiedni sposób weryfikować zmienne przekazywane do użytkownika do aplikacji.

• W pierwszym omówionym przypadku (zmienna id) wystarczy sprawdzać czy przekazana zmienna jest liczbą.
• W przypadku z mechanizmem logowania sytuacja jest trochę bardziej skomplikowana – tutaj należy uniemożliwić zamknięcie przez atakującego zmiennej tekstowej znakiem ’ (np. używając funkcji mysql_real_escape_string(), choć sugerowaną metodą jest stosowanie zapytań parametryzowanych  (update: np. w najnowszej wersji PHP – 5.5.0 mysql_real_escape_string() deprecated i prawdopodobnie w przyszłych wersjach nie będzie obsługiwana))

— michal.sajdak<at>securitum.pl