Już jutro spotkanie krakowskie spotkanie OWASP. Jednym z jego punktów będzie panel dyskusyjny dotyczący ASVS. A ja już dzisiaj chciałbym zachęcić wszystkich do przejrzenia listy ASVS i zastanowienia się, czy aby na pewno wszystkie jej elementy są dobrze i jednoznacznie zrozumiałe. Przykład:
V3.4: Verify that sessions timeout after a specified period of inactivity.
A co w przypadku aplikacji, która intensywnie pobiera informacje w tle (AJAX, JSON) przez co sama, bez “współpracy” użytkownika, podtrzymuje sesję?
Ciekawy jestem jak wypadnie panel dyskusyjny dotyczący ASVS. Na temat ASVS mówiłem i pisałem niejednokrotnie. Bardzo podoba mi się pomysł, by weryfikować stosowanie mechanizmów bezpieczeństwa, a nie skupiać się na szukaniu podatności. Różne poziomy ASVS pozwalają na dostosowanie zakresu wykonywanych sprawdzeń do oczekiwanego użycia aplikacji. Przecież (hipotetyczny) CMS, o którego wyborze pisałemwcześniej, wymaga innego poziomu “pewności”, niż system bankowości internetowej.
W związku z pojawieniem się nowej wersji Chrome i towarzyszącą temu wydarzeniu listą osób nagrodzonych za znalezienie i zgłoszenie błędu, pojawiło mi się w głowie pytanie. Jak bardzo Google musi być pewne jakości swojej przeglądarki, skoro oferuje nagrody za znalezienie błędu? Samo Google można zastąpić dowolną inną nazwą firmy (lub osoby), która płaci za zgłoszone błędy w swoich aplikacjach. I czy na każdym poziomu “dojrzałości” procesu tworzenia oprogramowania taki pomysł jest dobry?
Co prawda już dzieliłem się tym postem, ale warto o nim przypomnieć jeszcze raz: Forensics. Dziś miałem okazję chwilę pobawić się drugim ze scenariuszy, czyli Nitroba University Harassment Scenario. Zadanie nie jest szczególnie trudne, do jego rozgryzienia spokojnie wystarczy Wireshark i Network Miner. Ciekawym ćwiczeniem jest tu przede wszystkim zbudowanie sensownego łańcucha dowodów potwierdzających tezę, że autorem tych strasznych maili jest (...). A to już sobie sprawdźcie sami :)
Na początek krótkie wprowadzenie: “Nie można przełamać czegoś, co nie istnieje” – polski wyrok w sprawie SQL Injection. Sprawa jest stara i szczerze mówiąc to rozstrzygnięcie nie podoba mi się od chwili, gdy o nim usłyszałem. Nie chodzi mi tu o tę konkretną sprawę, ale właśnie o (...) nie można przełamać czegoś, co nie istnieje (...).
Jakiś czas temu opublikowałem kolejny przykład/wyzwanie. Do tej pory dostałem dwa raporty o błędach, które zgodnie z zapowiedzią opublikowałem. Razem z publikacją raportu, udostępniłem nową wersję zadania, która zawiera poprawkę do zgłoszonego błędu. Poprawka może, ale nie musi być skuteczna. Obecna wersja zadania dostępna jest pod adresem http://bootcamp.threats.pl/lesson25b/. Przypominam też, że nie chodzi w nim wyłącznie o szukanie błędu, ale również uzasadnienie dlaczego (prawdopodobnie) jakiegoś błędu nie ma.
Drugie przypomnienie dotyczy przykładu, który omawiałem we wpisie Jak szukać SQLi – przykład. Poza omawianą wersją zadania udostępnionych jest jeszcze kilka innych wersji:
Windows dość intensywnie wykorzystuje coś, co nazywa się Extensible Storage Engine. Z pewnych przyczyn chciałem dobrać się do danych przechowywanych wewnątrz jednej takiej bazy. Było trochę problemów ze znalezieniem odpowiedniego narzędzia, ale udało się. Przy pomocy esedbexport z libesedb zrzuciłem interesujące mnie dane do pliku tekstowego, a dalej to już jakoś poszło :)
Odpowiadając na pytanie z komentarzy - wybrałem FrogCMS, a później przeszedłem na WolfCMS (fork tego pierwszego). Zmiana wynikła z braku aktywności tego pierwszego projektu, a na wszelki wypadek (potencjalne błędy) wolę korzystać z czegoś, co przynajmniej daje nadzieję na wypuszczenie poprawek. Wybór tego konkretnego rozwiązania wynikał z faktu, że ten CMS jest dość minimalistyczny, by nie powiedzieć prymitywny. Jego funkcjonalność była dla mnie w zupełności wystarczająca, choć nie wykluczam, że teraz wybrałbym coś w stylu projektu jekyll.
