Obsługa plików, a SQL Injection
Podczas poszukiwania podatności SQL Injection głównym obszarem analizy jest zawartość strony, generowana dynamicznie na podstawie danych pobranych z bazy. To właśnie dzięki niej jesteśmy w stanie określić czy wstrzyknięte przez nas zapytanie wykonało się poprawnie. Stosując tę metodę można natrafić na kilka sytuacji, w których analiza czy też dostęp do danych jest ograniczony.
Przykładem takiego działania może być podstrona, która wyświetla tylko dane znajdujące się w pierwszym wierszu zwróconym przez bazę. W takim przypadku próba modyfikacji oryginalnego zapytania poprzez warunek 1=1 lub z wykorzystaniem polecenia UNION SELECT na niewiele się zda. Oczywiście większość, jeśli nie wszystkie problemy związane ze specyfiką działania skryptu wykonującego zapytanie można obejść. Jednakże tworzenie obejść w takich przypadkach nie należy do najprzyjemniejszych rzeczy.
Alternatywnym działaniem do wyświetlania danych z bazy może być wykorzystanie wsparcia dla obsługi plików przez SZBD i zapisanie otrzymanego wyniku do pliku.
Załóżmy, że istnieje skrypt o następującej treści:
... $sql = 'SELECT title, body FROM pages WHERE id = ' . $_GET[ 'id' ]; $q = mysql_query( $sql ); $q = mysql_fetch_array( $q ); echo 'Tytuł: ' . $q[ 'title' ] . '
Treść: ' . $q[ 'body' ];
Mimo tego, że jest od podatny na SQL Injection nie jesteśmy w stanie w prosty sposób wyświetlić danych pochodzących z innej tabeli – przekazując jako wartość zmiennej id np. ciąg
1 union select username, password from users
Jeśli natomiast zmodyfikujemy zapytanie tak, aby wynik jego był zapisywany do pliku uzyskamy dostęp do wszystkich danych zwróconych przez bazę. I tak przekazując do powyższego skryptu zmienną o wartości:
1 union select username, password from users into dumpfile '/path/to/public_html/file.txt'
stworzymy plik, który będzie zawierał rezultat wykonania zapytanie, a przy okazji będzie on dostępny za pośrednictwem przeglądarki.
Poza obsługą zapisu plików mamy możliwość również wczytania ich zawartości do bazy. Oczywiście wykorzystanie tego mechanizmu zgodnie z jego zadaniem jest mało przydatne jeśli chodzi o SQL Injection. Może natomiast posłużyć jako proxy w dostępie do plików znajdujących się na tym samym serwerze co baza danych. Wystarczy przekazać do skryptu następujące zapytanie:
1 union select load_file( '/path/to/config.php' ) into dumpfile '/public_hml/config.txt'
W wyniku powyższego zapytania uzyskamy dostęp do pliku konfiguracyjnego, do którego dostępu „strzeże” parser PHP.
W celu zabezpieczenia się poza samym rozważnym przekazywaniem zmiennych do zapytań SQL warto zastosować się do zasady najmniejszych uprawnień. Jeśli w naszej aplikacji nie korzystamy z obsługi plików nie ma sensu, aby użytkownik bazy danych miał takowe uprawnienia. Podobnie powinno być z pozostałymi uprawnieniami. Jeśli celem aplikacji jest jedynie prezentacja danych pochodzących z bazy użytkownik powinien mieć jedynie prawa do wykonania zapytania SELECT. Jedynym skutkiem nadania większych uprawnień jest danie dodatkowych możliwości potencjalnemu napastnikowi.
Tagi: pliki, SQL Injection, sqli
Kategoria: Bezpieczeństwo, Bazy danych
2 komentarze
Trackbacks & Pingbacks
-
Koło fortuny (Blind SQL injection) « guzik
[…] i w komentarzach uzupełniam artykuły dot. baz danych (vide Analiza struktury bazy danych czy Obsługa plików, a SQL Injection). Dziś przyjrzałem się jego podejściu do Blind SQL injection czyli ataku na stronę, która nie […]
Dla uspokojenia czytelników – uprawnienie FILE (http://dev.mysql.com/doc/refman/5.0/en/privileges-provided.html#priv_file) nie jest nadawane domyślnie użytkownikom (np. z ALL PRIVILEGES). To robi się raczej świadomie (jeśli na produkcyjnym systemie sie robi w ogóle).