Obiekt monitorowany – czujesz się bezpieczniej?
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.
Czytaj dalej...
Małe podsumowanie przykładów z bootcamp
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.
Bootcamp XVIIIa: podatność w innej ścieżce wykonania
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!
Oryginał tego wpisu dostępny jest pod adresem Bootcamp XVIIIa: podatność w innej ścieżce wykonania
Autor: Paweł Goleń
Chrome chwalony za sandbox
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:
Oryginał tego wpisu dostępny jest pod adresem Chrome chwalony za sandbox
Autor: Paweł Goleń
Każda praca z czasem powszednieje
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.
Nie jestem purystą, ale... czyli spot the bug
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:
Bootcamp XVIII: wskazówek część dalsza
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.
Bootcamp XVIII: Jak to może być zrobione?
Nie muszę być ekspertem w konkretnej technologii by móc badać bezpieczeństwo aplikacji z niej korzystającej. Olbrzymia część błędów w aplikacjach nie jest specyficzna dla wykorzystanej technologii (język, framework, ...), choć oczywiście, jakaś grupa problemów specyficznych zawsze się znajdzie. Warto jakieś ogólne pojęcie o programowaniu posiadać, pomoże to w zrozumieniu opisów badanej technologii (czasem trzeba zrobić RTFM). Ważna jest również umiejętność spojrzenia na pewną funkcjonalność i próba określenia jak dana funkcja może być zrealizowana.
W przykładzie http://bootcamp.threats.pl/lesson18/ formatka wyszukiwania pozwala na określenie trzech parametrów, po których wyszukiwanie może się odbyć. Warto zastanowić się, czy:
- wszystkie parametry łącznie mają sens,
- czy wszystkie warianty wyszukiwania (różne kombinacje parametrów) obsługuje jedno zapytanie,
- jakie optymalizacje mogły zostać wprowadzone,
Powodzenia! Na razie jest jedno rozwiązanie tego zadania.
Oryginał tego wpisu dostępny jest pod adresem Bootcamp XVIII: Jak to może być zrobione?
Autor: Paweł Goleń
Nie wszystkie SQLi są oczywiste
Już od dłuższego czasu nosiłem się z zamiarem przygotowania przykładu, w którym SQLi nie byłoby tak bardzo oczywiste, a w każdym razie nie na pierwszy rzut oka. Dodatkową motywacją dla mnie stało się nietypowe rozwiązanie jednego z poprzednich zadań, które opisałem we wpisie There's more than one way to skin a cat. Ostatecznie prosty przykład udało mi się w końcu przygotować: http://bootcamp.threats.pl/lesson18/. Zadanie jest proste, wystarczy znaleźć SQLi.
Oryginał tego wpisu dostępny jest pod adresem Nie wszystkie SQLi są oczywiste
Autor: Paweł Goleń
There's more than one way to skin a cat
Rzecz dotyczy udostępnionego przeze mnie już jakiś czas temu wyzwania. Do tej pory wszystkie rozwiązania były zgodne z moim założeniem. Za pomocą blind SQLi rozpoznawana była struktura bazy danych, z odpowiedniej kolumny pobierany był hash hasła dla konkretnego użytkownika, hash ten był następnie w odpowiedni sposób wykorzystywany. Właśnie to odpowiednie wykorzystanie pobranego z bazy hasha było, w moim zamierzeniu, głównym elementem wyzwania. Wszystko po to, by pokazać, że nie wystarczy hashować hasła, trzeba jeszcze robić to z głową.
Dziś otrzymałem rozwiązanie, które wykracza poza ten schemat. Warto mu się przyjrzeć, bo jest nie tylko ciekawe, ale i w pewnym stopniu... przypadkowe.