Taka straszna pandemia miała być. Tyle ofiar śmiertelnych. Wielka afera, że rząd nie kupił szczepionek i... Nic. Okazuje się, że teraz większy problem będą miały te kraje, które szczepionki kupiły i teraz im niewykorzystane (ach ci niedobrzy obywatele, szczepić się nie chcieli) zalegają... Zwycięskie będą media, które najpierw nakręcały panikę pod hasłem świńska grypa lub nowa grypa , a teraz będą mogły demaskować spiski złych koncernów farmaceutycznych. Ech...
Nie będę się rozpisywał na temat tego, jak Google zostało skutecznie zaatakowane przy pomocy nowego błędu w Internet Explorer (CVE-2010-0249). Jeśli ktoś ma ochotę poczytać na ten temat, może zrobić to na przykład tu: Techniczne szczegóły ataku na Google. Ja tylko jeszcze raz chciałem podkreślić, że napisanie absolutnie bezpiecznej przeglądarki jest praktycznie niemożliwe. Dlatego należy stosować tak wiele środków zaradczych, jak to jest tylko możliwe. Wówczas jest szansa, że skutki wykorzystania podatności będą ograniczone.
Po wczorajszym spotkaniu OWASP chciałem zwrócić uwagę na fragment wypowiedzi Piotra Łaskawca z prezentacji dotyczącej fuzzingu i fuzzerów. Powiedział on mniej więcej tyle, że w procesie tworzenia oprogramowania (konkretnie podczas jego testowania) firma, w której pracuje wykorzystuje fuzzing. Kluczowy fragment jest jednak inny. Wykorzystywane fuzzery są tworzone specjalnie pod testowane aplikacje , bo tworzone aplikacje są na tyle specyficzne, że “standardowe” fuzzery sobie z nimi nie radzą.
Ostatnio na drzwiach mojej klatki schodowej pojawiła się naklejka “Obiekt monitorowany”. Ktoś się czuje z tego powodu bezpieczniej? To niech pomyśli jeszcze raz.
Obecnie w ramach przewodnika po bezpieczeństwie aplikacji internetowych udostępnione jest 18 przykładów. Przykłady dotyczą różnych aspektów bezpieczeństwa oraz testowania aplikacji internetowych, po części po to, by pokazać, że testy penetracyjne wcale nie są gwarancją bezpieczeństwa. Ten temat poruszałem zresztą wiele razy na blogu i jeszcze kilka razy pewnie poruszę.
Dziś chciałem podsumować to, co pokazałem w przykładach, a przy okazji zapytać się, co pokazać jeszcze. Jeśli ktoś ma sugestie odnośnie tematu, na który chciałby się czegoś więcej dowiedzieć – proszę bardzo.
W ramach ciekawostki przygotowałem drobną modyfikację zadania bootcamp XVIII. Wersja ta dostępna jest pod adresem http://bootcamp.threats.pl/lesson18a/ i różni się od oryginalnej ścieżką kodu, w której występuje podatność. O ile w przykładzie podstawowym podatność znajduje się w kodzie normalnie używanym w trakcie interakcji z użytkownikiem, w wersji zmodyfikowanej podatność ukrywa się w legacy code , który mógł być kiedyś wykorzystywany, ale wprowadzone zostały drobne zmiany i... Wciąż jednak można się do tej ścieżki wykonania dostać. Jak? To jest właśnie Wasze zadanie :) Powodzenia!
Chrome to wzorowo zabezpieczona przeglądarka? Cóż, z tym wzorowym zabezpieczeniem to może pewna przesada, aczkolwiek zwrócenie uwagi na korzyści płynące z sandboxa jest słuszne. Pisałem zresztą o tym już jakiś czas temu:
Czasami jak spotka się kilku ludzi, to temat rozmowy schodzi na pracę. Schemat jest zwykle podobny, (...) moja praca jest nudna, Ty to masz ciekawą (...) z drobnym odstępstwem od tego schematu w przypadku osób dopiero zaczynających pracę na jakimś stanowisku/w jakiejś firmie. I chodzi chyba o to, że z czasem każda praca powszednieje. Nawet ta najlepsza.
Tym razem nie chodzi o żaden przykład z bootcamp. Błąd, który trzeba zauważyć jest co prawda związany z bezpieczeństwem, jest(?) to podatność, ale ryzyko z nią związane jest nikłe. Błąd jest dość oczywisty, fragment kodu:
Pora na rozwinięcie poprzedniej wskazówki podanej we wpisie Bootcamp XVIII: Jak to może być zrobione. Chcę przede wszystkim podkreślić, że tego typu przypadki “występują w naturze”, przy czym wykrycie ich nie jest trywialne.
