Problem
W testowanej aplikacji znaleźliśmy pole wejściowe, które mogłoby być wrażliwe na składowany atak XSS, ale serwer obcina je do takiej liczby znaków, która wydaje się być niewystarczająca do przeprowadzenia znaczącego ataku XSS. Takie ograniczenie można pominąć, odpowiednio 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 pomię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. Spotkaliśmy się z kilkoma przypadkami aplikacji, w których na stronie wyświetlała się na przykł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 podobnej 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 przeprowadza odpowiedniej weryfikacji danych wejściowych ani kodowania wyniku, do wstrzykiwania 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 znajduje 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 przykład w przeglądarce Internet Explorer 7 komentarze są dozwolone w znacznie większej liczbie 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 powoduje odbicie żądania do wywołującego. Kiedy klient wywołujący (przeglądarka) ma plik cookie docelowej witryny, to wysyła go razem z żądaniem. Ten plik cookie jest następnie odsyłany z powrotem na serwer WWW.
W ramach przeprowadzonego testu zakładamy, że napastnik nie może przeprowadzić ataku przeciwko 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 recepturze 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 napastnik 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 serwerów produkcyjnych. Jest to problem konfiguracji, którym należy się zająć w fazie wdrażania, dlatego serwery testowe w środowiskach projektowych lub kontroli jakości nie dostarczają dokładnych wyników odpowiadających środowisku produkcyjnemu.