Zagrożenia w sieci

Pomijanie ograniczeń długości pola

Problem

W testowanej aplikacji znaleźliśmy pole wejściowe, które mogłoby być wrażliwe na składo­wany atak XSS, ale serwer obcina je do takiej liczby znaków, która wydaje się być niewystar­czająca do przeprowadzenia znaczącego ataku XSS. Takie ograniczenie można pominąć, od­powiednio wykorzystując separatory komentarzy języka JavaScript.

Rozwiązanie

Ciągi zamieszczone w poniższym listingu po połączeniu tworzą ciąg ataku XSS. Chociaż żaden z nich z osobna nie może posłużyć do przeprowadzenia ataku, każdy stanowi oddzielny fragment standardowego, prostego ciągu ataku XSS.

Wykorzystanie komentarzy JavaScript do pomijania ograniczeń długości pola

<script>/*

*/alert(/*

*/"XSS")/*

*/</script>

Należy również podjąć próbę przesłania sekwencji tych ciągów w odwróconej kolejności.

W niektórych konfiguracjach taki atak może zakończyć się sukcesem. Atak powiedzie się, gdy aplikacja zawiera wiele pól z ograniczeniami długości, które są ze sobą łączone, ale po­między nimi występują znaki interpunkcyjne bądź znaczniki HTML. Powiedzie się również wtedy, kiedy na tej samej stronie wyświetla się wiele egzemplarzy tego samego pola. Spo­tkaliśmy się z kilkoma przypadkami aplikacji, w których na stronie wyświetlała się na przy­kład lista kodów statusu. Były one wprowadzane przez użytkowników i nie poddawano ich żadnym testom sprawdzającym. Wyświetlały się w tabeli zdefiniowanej w kodzie HTML po­dobnej do tej, którą zamieszczono w zamieszczonym niżej listingu

Wyjście aplikacji w przypadku, gdy serwer wprowadza ograniczenie długości kodu statusu

<tr><td>kodStatusu1

</td></tr>

<tr><td>

kodStatusu2

</td></tr>

 

 Wynik HTML po odpowiednim wykorzystaniu komentarzy JavaScript

<tr><td><script>

/*</td></tr><tr><td>*/

alert(

/*</td></tr><tr><td>*/

"XSS")

/*</td></tr><tr><td>*/

</script></td></tr>

W większości przeglądarek, włącznie z przeglądarkami Internet Explorer 7 i Mozilla Firefox 3.0, powyższy skrypt jest równoważny z instrukcją <script>alert( "XSS")<script>.

Podobnie jak w przypadku innych podobnych testów podatności na ataki XSS oznaką wrażliwo­ści aplikacji jest wyświetlenie okna komunikatu w odpowiedzi na wstrzyknięcie ciągu ataku.

DYSKUSJA

W sytuacjach, kiedy serwer wprowadza ograniczenia długości pól wejściowych, ale nie prze­prowadza odpowiedniej weryfikacji danych wejściowych ani kodowania wyniku, do wstrzy­kiwania kodu JavaScript do aplikacji można wykorzystać sekwencję podobną do tej, którą pokazano w zamieszczonym wyżej listingu. Pokazany atak zadziała w przypadku, gdy na jednej stronie wy­świetlają się wszystkie dane wejściowe wprowadzane przez napastnika. Wszystko, co znaj­duje się pomiędzy symbolami /* i */, jest traktowane jako komentarz, dlatego kod HTML, który serwis wstawia pomiędzy dane wejściowe napastnika, jest ujęty w komentarz.

Nie będziemy tu omawiać szczegółowo lokalizacji, w których język JavaScript zezwala na umieszczanie komentarzy, ponieważ jest to zależne od konkretnej implementacji. Na przy­kład w przeglądarce Internet Explorer 7 komentarze są dozwolone w znacznie większej licz­bie miejsc niż w przeglądarce Mozilla Firefox 3.0.

Do pominięcia zabezpieczeń polegających na użyciu atrybutu HttpOnly przez potencjalnych atakujących może być użyta technika XST (ang. Cross Site Tracing). Metodę HTTP TRACE wykorzystuje się do debugowania, choć w wielu serwerach WWW jest ona domyślnie włączona. Żądanie TRACE do serwera powo­duje odbicie żądania do wywołującego. Kiedy klient wywołujący (przeglądarka) ma plik co­okie docelowej witryny, to wysyła go razem z żądaniem. Ten plik cookie jest następnie od­syłany z powrotem na serwer WWW.

W ramach przeprowadzonego testu zakładamy, że napastnik nie może przeprowadzić ataku prze­ciwko serwisowi na XSS, ponieważ w pliku cookie ustawiono atrybut HttpOnly. Napastnik mógłby zamiast tego wygenerować skrypt podobny do tego, który opisano w re­cepturze 12.3, gdzie zastąpiłby metodę GET w wywołaniu funkcji XmlHttpRequest.open() metodą TRACE. Po takim zabiegu mógłby wyizolować plik cookie z odpowiedzi serwera. Oczywiście, aby to było możliwe, serwis musiałby być wrażliwy zarówno na ataki XSS, jak i na ataki XST. Pozostawienie włączonej obsługi metody TRACE samo w sobie nie musi być słabym punktem. Aby napastnik mógł przesyłać żądania do docelowego serwera z przeglą­darki ofiary i czytać odpowiedzi, musi mieć możliwość wstawiania kodu JavaScript do wrażliwej strony.

Należy zwrócić uwagę na to, że nawet jeśli aplikacja nie jest wrażliwa na atak XST i napast­nik nie jest w stanie wykraść pliku cookie, niemożliwy staje się tylko atak XSS w najprostszej postaci. Aplikacja może być wrażliwa na ataki XSS, ponieważ w dalszym ciągu możliwe jest przeprowadzanie ataków omówionych w recepturach 12.2 i 12.3.

Test zaprezentowany w tej recepturze należałoby przeprowadzić w środowisku produkcyjnym lub na serwerach publikujących zbliżonych konfiguracją do serwe­rów produkcyjnych. Jest to problem konfiguracji, którym należy się zająć w fazie wdrażania, dlatego serwery testowe w środowiskach projektowych lub kontroli ja­kości nie dostarczają dokładnych wyników odpowiadających środowisku produk­cyjnemu.