Atak wstrzyknięcia na stronach bez pól tekstowych

Artykuł ten jest pierwszym z serii wpisów poświęconych zagadnieniom bezpieczeństwa aplikacji Webowych. W niniejszym artykule zostanie omówiona możliwość wykorzystania podatności typu injection na stronach bez pól tekstowych oraz wykorzystanie narzędzia WebScarab do przeprowadzenia takiego ataku.

Wykorzystanie podatności wstrzyknięcia (ang. Injection Flaw) jest częstą przyczyną włamań do aplikacji internetowych. Problemy związane z bezpieczeństwem aplikacji dotyczące wstrzyknięcia niepoprawnych danych na stronach z polami testowymi są powszechne (w szczególności ataki typu Cross Site Scripting, XSS). Jednak możliwość wykorzystania podatności wstrzyknięcia na stronach bez pól tekstowych nie jest już tak oczywista.

Injection Flaw

Rozpatrzmy prostą funkcjonalność aplikacji obsługującej sklep internetowy, służącą do przedstawienia statusu złożonych zamówień. Przykładowy wygląd takiej aplikacji przedstawiony jest na rysunku 1.

Jak można przypuszczać, informacja uzyskana od użytkownika, związana z wyborem interesującego statusu przesyłki służy do sparametryzowania zapytania SQL do bazy danych. Z dużym prawdopodobieństwem można założyć, że wykorzystane zapytanie SQL będzie zbliżone do zapytania w następującej postaci:

SELECT id, towar, adres FROM zamowienia WHERE klient_id = ... and status = ...

Jeśli założy się, że programista aplikacji kleił ręcznie zapytanie oraz nie zapewnił walidacji dostarczanych danych, łatwo można się domyśleć jaki tekst trzeba umieścić w zapytaniu aby uzyskać informację o wszystkich zamówieniach.

Rozważyć można sytuację, kiedy zamiast spodziewanego identyfikatora statusu podstawiony zostanie fragment zapytania SQL postaci:

4 or 1=1

W takim przypadku warunek w zapytaniu będzie zawsze prawdziwy, co w efekcie spowoduje wyszukanie wszystkich rekordów z tabeli.

Ponieważ aplikacja wysyła dane użytkownika za pomocą metody GET, w wysyłanym URLu możemy zaobserwować wszystkie parametry. Wystarczy, że w odpowiednim miejscu zostanie wklejony spreparowany fragment danych a cały URL ponownie wysłany. Na rysunku 2 można zaobserwować wynik wykonania za pomocą zwykłej przeglądarki takiego złośliwego zapytania.

Jak można było się spodziewać, w wyniku tego zapytania została ujawniona cała zawartość tabeli. W tym przypadku poznano wszystkich adresatów do których sklep wysłał paczki. Jednak jeśli byłby to system bankowy i "dziurawa" funkcjonalność dotyczyłaby kodów jednorazowych - ujawnione zostałyby adresy, pod które zostały one wysłane. Jeśli w tablicy znajdowały by się adresy mailowe, to ich poznanie mogło by posłużyć do wysyłania SPAMu lub wiadomości związanych z phishingiem. Taki atak byłby o tyle groźny, że dotyczył rzeczywistych klientów danej organizacji.

W omawianym powyżej przykładzie aplikacja wykorzystywała do komunikacje metodę GET, więc atak można przeprowadzić nawet za pomocą przeglądarki. Jednak wykorzystanie metody POST, chociaż ukrywa część informacji przed zwykłym użytkownikiem oraz umożliwia szyfrowanie przesyłanych danych w przypadku protokołu HTTPS, nie jest zabezpieczeniem (patrz paradygmat security by obscurity). W takim przypadku pomocne może być narzędzie WebScarab. WebScarab jest specjalnym rodzajem serwera proxy. Każde żądanie przechodzące przez niego jest przechwytywane i może zostać dowolnie zmodyfikowane. Program ten jest często wykorzystywany przy testach bezpieczeństwa aplikacji webowych.

Jak przeprowadzić atak wykorzystując program WebScarab

Pierwszym krokiem jest ustawienie proxy w używanej przeglądarce na adres wykorzystywany przez program WebScarab (standardowo nasłuchuje na porcie 8008). Następnym krokiem jest wejście na stronę, której ewentualne podatności chcemy sprawdzić. Podczas wywołania zapytania zostanie ono przechwycone i zaprezentowane użytkownikowi. W tym miejscu można dokonać dowolnych modyfikacji nagłówków a także danych przesyłanych za pomocą metody POST. Przykład takiej modyfikacji dobrze znanym fragmentem zapytania SQL zaprezentowany jest na rysunku 3. Efekt przeprowadzonych działań widoczny jest na rysunku 4.

Zgodnie z oczekiwaniami po zatwierdzeniu zmiany dokonanej w programie WebScarab uzyskany zostaje dostęp do wszystkich danych znajdujących się w tabeli.

Podsumowanie

Jak można zabezpieczyć się przed tego typu atakiem

• Nie kleić ręcznie zapytań, zamiast tego skorzystać ze specjalnych funkcji lub obiektów służących do tego (ale nie zawsze się da, np. zapytanie XPath). Dla przykładu, w JDBC mamy do dospozycji PreparedStatement:

  . . .
  PreparedStatement ps;
  c = ds.getConnection();
  ps = c.prepareStatement("SELECT id, towar, adres FROM zamowienia
     WHERE klient_id = ? and status = ?");
  ps.setString(1, klient_id);
  ps.setString(2, status);
  ps.execute();
  . . .
  

• Nie ufać w żadne dane wysłane od klienta, zawsze dokonywać walidacji albo choćby procesu escapowania danych

  . . .
  try {
  Integer val = null;
  val = val.parseInt(request.getParameter("status"));
  if (val <= 0 || val > 4)
  throw new NumberValidationException(); //własna klasa wyjątku
  . . .
  } catch(NumberFormatException ex) {
  out.println("Parameter problem, try once again");
  } catch(NumberValidationException ex) {
  out.println("Parameter problem, try once again");
  } catch(...) ...