W dniu 10 czerwca w Krakowie odbędzie się ostatnie przed wakacjami spotkanie OWASP. Tym razem dwie prezentacje o tematyce będącej w pewnym stopniu kontynuacją poprzedniego spotkania, oraz oczywiście tradycyjne wieści z OWASP przekazywane przez Przemka Skowrona.
Do myślenia dał mi ostatnio ten post: Banking Malware uses PAC file. W tym przykładzie malware wprost ustawia adres skryptu PAC, z którego korzysta przeglądarka do określania przez jakie proxy powinna przesłać żądanie. Malware musi jednak jakoś ten klucz ustawić, czyli musi wejść na komputer. A co, jeśli wchodzić by nie musiał?
Najbardziej oryginalną (i niestety – jedyną) odpowiedź odnośnie pytania o ukryty sens dobrych praktyk udzielił Kravietz:
Dobre praktyki mają kapitalne znaczenie dla pentesterów, gdyż pozwalają rozdymać raporty nawet gdy nie udaje się znaleźć nic poważniejszego (...)
Wymienione przeze mnie punkty z ASVS mają jednak również praktyczne znaczenie, niestosowanie ich ma realny wpływ na ryzyko, przynajmniej w niektórych scenariuszach. Jakich?
Z dzisiejszych wykładów na Confidence najbardziej podobał mi się The Presence and Future of Web Attacks Multi-Layer Attacks and XSSQLI. Dlaczego akurat ta prezentacja, o tym później. Na pewno warto zapoznać się z zasobem HTML5 Security Cheatsheet. To przy okazji jest częściowa odpowiedź na pytanie, które padło na ostatnim spotkaniu OWASP, czyli “Co zmieni HTML5?”.
Jak zwykle mój kolejny bootcamp bardzo szybko prawie rozwiązał Krzysztof Kotowicz. Podpowiem, że sedno tego przykładu leży w parametrze token , a problemy, które należy zauważyć, są dwa. Pierwszy problem, ten znaleziony, to replay. Możliwe jest wielokrotne wykorzystanie tej samej wartości tokenu. Pytanie – w jakim przypadku? Czy to mówi coś na temat tego, kiedy generowany jest token? Pytanie zasadnicze: czy można wysłać żądanie bez prawidłowej wartości tokenu? Hint: CWE-665: Improper Initialization.
UWAGA: pamiętajcie, że to jest przykład , nie doszukujcie się więc wielkiego sensu czy rzeczywistego ryzyka związanego z tą konkretną podatnością. Ten sam typ błędu w innym kontekście skutki powodować może już całkiem poważne.
Oryginał tego wpisu dostępny jest pod adresem Bootcamp XXII: hint
Autor: Paweł Goleń
Mamy powódź. Znowu. Pozostaje czekać na ogłoszenie planów wsparcia dla powodzian. O przepraszam, nie trzeba czekać, przecież już wiadomo, że takie wsparcie będzie. Rząd da, państwo da. Tylko, że państwo to między innymi ja i jakoś takie ciągłe dawanie mi się nie uśmiecha.
Bardzo prosty przykład: http://bootcamp.threats.pl/lesson22/. Gdzieś tu popełniony został błąd. Może nawet więcej niż jeden. Potraficie go znaleźć?
Oryginał tego wpisu dostępny jest pod adresem Bootcamp XXII: Coś jest nie tak – co?
Autor: Paweł Goleń
Pisałem już o problemach z JBroFuzz. Tym razem “same mi się odtworzyły” na komputerze z Windows XP. W dodatku zaobserwowałem dodatkową niedogodność – problemy z automatycznym ustawianiem przez JBroFuzz nagłówka Content-Lenght. Kilka dni temu wysłałem maila z opisem problemu na podany na stronie JBroFuzz adres. Na razie cisza, brak odpowiedzi...
Oryginał tego wpisu dostępny jest pod adresem JBroFuzz II: problem jak był, tak jest
Autor: Paweł Goleń
Jak w przekonywujący sposób pokazać, że hibernacja jest niebezpieczna? Wystarczy w prosty sposób eskalować swoje uprawnienia, na przykład do poziomu Local System.
Po kolejnym mocno żenującym rankingu bezpieczeństwa bankowości internetowych Przemek Skowron nie wytrzymał i wyszedł z propozycją przygotowania zestawu kryteriów oceny bezpieczeństwa bankowości internetowej. Macie swoje sugestie? No to zapisywać się na listę owasp-poland i do roboty!
Swoją drogą na jakim poziomie powinny zatrzymać się te kryteria? Wskazania wymaganych mechanizmów bezpieczeństwa (uwierzytelnienie, autoryzacja, ...) i cech, które te mechanizmy powinny spełniać? A może należy zagłębić się w szczegóły dotyczące implementacji? W każdym razie – zapraszam do dyskusji na liście OWASP.
Oryginał tego wpisu dostępny jest pod adresem Kryteria oceny bezpieczeństwa bankowości internetowej
Autor: Paweł Goleń