Paweł Goleń, blog

Zarówno ja, jak i środowisko, w którym się obracam, jesteśmy obarczeni pewnym zboczeniem zawodowym. Prowadzi to czasem do abstrakcyjnych dość rozważań.

Jest sobie konkurs: CONFidence Security Evangelist. Jestem strasznie ciekawy kandydatur w kategorii Polish Politician Promoting IT Security.

Udostępniam kolejną lekcję, czyli tekst do zadania z Cross Site Request Forgery. Proponuję przyglądnąć się przy pomocy Fiddlera, lub innego proxy (WebScarab, Burp), jakie żądania generuje przeglądarka. Atak CSRF został wykorzystany choćby tu: Twitter XSS/CSRF worm series, a wcześniej (to już prawie cztery lata temu): Myspace CSRF and XSS Worm (Samy). Mój przykład specjalnie składa się z dwóch (lub więcej) żądań HTTP, by pokazać, że CSRF to nie tylko one-click-attack.

Nie widzę jakiegoś powalającego zainteresowania przykładami, które udostępniam na bootcamp. Są za proste? W każdym razie czekam, aż ktoś poda rozwiązanie jak w przykładzie z CSRF wykorzystać XSS do automatycznego usunięcia wiadomości. Chodzi o to, by po wysłaniu wiadomości (która jest wypisywana następnie na stronie) przeglądarka klienta sama (oczywiście w wyniku przekazanego kodu) wygenerowała dwa żądania HTTP:

• jedno żądanie, które "otwiera" wiadomość, która ma zostać usunięta i ładuje jej identyfikator do sesji,
• drugie żądanie, które wysyła polecenie usunięcia wiadomości,

Tak jak pisałem nie jest to do końca "typowe" CSRF, ponieważ "coś" co ma zmusić przeglądarkę do wygenerowania żądań jest osadzone na atakowanej stronie. Kolejny odcinek będzie również o CSRF, ale tym razem na stronie będzie istniał token zabezpieczający. Zadanie będzie również proste, osadzony wrogi kod będzie musiał odczytać token zabezpieczający i przygotować odpowiednie żądanie. Ale to już w kolejnym odcinku, na razie czekam na rozwiązanie dla http://bootcamp.threats.pl/lesson04/.

Od października 2008 roku Microsoft poza Severity Rating System udostępnia również drugi "parametr" opisujący podatność: Exploitability Index. Po co?