Kilka razy wspominałem o narzędziu F-Response. Kilka dni temu pojawiła się trzecia generacja tego narzędzia. Myślę, że w najbliższym czasie uda mi się rzucić okiem na zmiany. Oczywiście podzielę się wrażeniami, choć podejrzewam, że będę musiał napisać dokładnie to, co pisałem do tej pory: małe narzędzie, które po prostu robi to, co ma robić i robi to dobrze.
Dziś dostałem informację/potwierdzenie o nominacji mojego blogu w konkursie CONFidence Security Evangelist w kategorii Blog o bezpieczeństwie IT w języku polskim. Chciałem podziękować osobie, która zgłosiła mój blog do konkursu, jak również tym, którzy oddali już na niego głosy. Cieszę się, że widzicie w nim jakąś wartość.
Podobno złodzieje kradnący pieniądze z kont bankowych zaczęli celować również w te systemy, w których autoryzacja transakcji odbywa się przy pomocy kodów SMS. Rozwinę trochę ten temat.
Na blogu F-Secure pojawił się wpis: €25,000 Bank Robbing Mobile Phones? Podobno telefon Nokia 1100 może zostać wykorzystany do przejmowania SMS przesyłanych przez bank do klientów. Na chwilę obecną brak jest bliższych szczegółów i potwierdzenia tej informacji, ale warto śledzić ten wątek. Jeśli okaże się, że rzeczywiście możliwe jest łatwe przechwytywanie wiadomości SMS, może zrobić się ciekawie. Swoją drogą, czy ktoś zna się na GSM na tyle dobrze, by móc spekulować na jakiej zasadzie mogłoby to działać?
Zgodnie z zapowiedzią kolejny przykład – połączenie podatności Cross Site Request Forgery i Cross Site Scripting.
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.
Oryginał tego wpisu dostępny jest pod adresem CONFidence Security Evangelist
Autor: Paweł Goleń
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.
Oryginał tego wpisu dostępny jest pod adresem Bootcamp IV: CSRF – jak to zrobić
Autor: Paweł Goleń
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:
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?