10:50
26/7/2011

Na naszych szkoleniach poruszamy kilka technik omijania filtrów WAF. Jedną z nich jest HPP, czyli Http Parameter Pollution. Niedawno zaś pojawił się ciekawy dokument opisujący kolejną, zbliżoną do HPP metodę obchodzenia filtrów — Http Parameter Contamination.

Http Parameter Pollution (HPP)

Dla przypomnienia HPP, czyli Http Parameter Pollution to metoda modyfikacji tzw. query string (znaki od ? do końca URI), polegająca m.in. na przesyłaniu kilku takich samych nazw parametrów, ale z różnymi wartościami. W zależności od webserwera i języka programowania, reakcje webaplikacji mogą być różne (przyjęcie pierwszej lub ostatniej wartości, albo stworzenie tablicy z wszystkimi wartościami).

Http Parameter Pollution

Http Parameter Pollution, fot. Owasp AppSec'09

Dzięki HPP możemy tak zmodyfikować parametry w GET/POST/Cookie, aby możliwe było:
– nadpisanie wartości zahardcodowanych zmiennych
– wpłynięcie na działanie logiki webaplikacji
– ominięcie walidacji parametru (ew. regułki WAF)

Atak HPP Http Parameter Pollution

Przykład ataku HPP (Http Parameter Pollution), zmiana akcji

Http Parameter Contamination (HPC)

HPC, czyli Http Parameter Contamination to celowe zanieczyszczanie nazw parametrów znakami, które wg RFC3986 i RFC2396 mają w przypadku URL różne przeznaczenie:

HPC Http Parameter Contamination

HPC Http Parameter Contamination - reakcje różnych frameworków

Bazując na powyższej tabeli, można zauważyć, że aby obejść regułkę Mod_Security blokującą http://localhost/?xp_cmdshell można przesłać do aplikacji następujące dane: http://localhost/?xp[cmdshell (bo [ jest zamieniane na _). Podobnie, aby wykonać blokowany atak path traversal http://IP/test.asp?file=../bla.txt można użyć http://IP/test.asp?file=.%./bla.txt  (bo % jest pomijane).

Warto tu przywołać ciekawe zachowanie PHP w dostępie do plików — metoda ataku bardzo zbliżona do HPC.

Więcej o HPC możesz przeczytać tutaj. Jeśli jesteś zainteresowany bezpieczeństwem webaplikacji, zapraszamy na nasze szkolenie — właśnie otworzyliśmy rejestrację na kolejny termin (1-2 września), pozostało jeszcze 7 wolnych miejsc, a rejestrując się przed 10 sierpnia zapłacisz mniej.

Przeczytaj także:

11 komentarzy

Dodaj komentarz
  1. Ciekawe, aczkolwiek jak sądzę, każdy szanujący się deweloper robi 2 rzeczy:
    1. Waliduje dane,
    2. Używa modułów wspomagających takich jak Suhosin dla PHP.

    To pierwsze załatwia sprawę na poziomie kodu, a to drugie utwardza środowisko, w którym się działa (na wszelki wypadek).

    • To znaczy na Suhosin nie bedzie to dzialac? Tylko wadliwe jest mod_security?

  2. Ciekawe, nie słyszałem wcześniej o tych metodach ataków, ale popieram przedmówcę – żadne dane nie trafiają do przetwarzania bez uprzedniego sprawdzenia ich zawartości. Szczególnie tak istotne dane jak ścieżki są escape’owane i przechowywane w taki sposób, żeby nie mogło dojść do LFI / RFI.

    • Tomasz Kowalczyk: Oczywiście, to co obaj mówicie, jest prawdą. Tylko, że
      a) niestety nie wszyscy o tym wiedzą
      b) niestety nie wszyscy, którzy o tym wiedzą, zawsze o tym pamiętają
      c) niestety, nie wszyscy którzy o tym wiedzą i zawsze o tym pamiętają, zdają sobie sprawę z tego, że w funkcjach escape’ujących również zdarzają się błędy (por. ataki na addslashes) ;-)

      Zechciej również zauważyć Tomaszu, że w np. w HPP nie zawsze i nie do końca chodzi o to, że dane przekazywane do webaplikacji są niepoprawne bądź nie są “walidowane”, tu atakujący może czasem wpłynąć na logikę webaplikacji, bo webserwer albo framework coś zrozumie tak, a nie inaczej.

    • dokładnie jak pisze Piotrek, czasem konkretne zachowanie zależy od webserwera na którym aplikacja jest uruchamiana, a nie zawsze używa się świadomie bądź nie środowiska zalecanego przez producenta. Co nie zmienia postaci rzeczy, że a) b) i c) należą do najczęstszych problemów :), problem niestety najczęściej pojawia się pomiędzy klawiaturą a krzesłem.

  3. Czyli żeby wykryć atak HPP, już nie wystarcza walidacja każdego parametru z osobna zapisanego w $_GET[] i $_POST[] ale też trzeba sprawdzać cały łańcuch czyli $_SERVER[‘QUERY_STRING’]. Po prostu makabra! Tym sposobem rozmiar aplikacji i stopień komplikacji kodu rozrasta się do niebotycznych rozmiarów!

    • Ale kto ci każe parsować QUERY_STRING ?
      lecisz po _POST/_GET i tyle – miej jedynie świadomość tego, że dziwne parametry mogą zostać przekazane i każdy należy dokładnie sprawdzić na okoliczność typu (np. można dostać array zamiast stringa).
      Zwróć uwagę, że tabelki przedstawiają wejście w postaci query stringa a na wyjściu to, co widzi PHP. Ergo – ty i tak widzisz to, co PHP, tyle że w qs może pojawić się coś innego niż się spodziewasz :)

  4. @Piotr Konieczny: Ależ ja wcale nie próbuję stawiać siebie na pozycji “tego nieomylnego”. ;] Zgadzam się z Tobą, że jeśli programista nie jest świadomy istnienia tego typu problemów, to włamywacze mają wolną drogę do danych / serwera. Celem mojego komentarza było jedynie wskazanie, że przed zdecydowaną większością podatności można się obronić. Jeśli błąd będzie w serwerze / interpreterze / czymkolwiek poza władzą teoretycznego programisty, to niestety “mówi się trudno” i stara wykombinować inne rozwiązanie. Chyba, że tak, jak wspomniał @Kenjiro, można się poratować np. Suhosinem.

  5. @Marcin Maziarz

    Zapomniałeś o walidacji nagłówków zapytania i cookies ;)

  6. @Marcin Maziarz
    Nie jest tak źle wystarczy wyseparować filtry wejścia i po problemie.

    Generalnie kolejne przypomnienie że nie należy ufać magii serwera ;)

  7. Jedynie mod_perl i python dają radę:)

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: