Aplikacje internetowe

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