Paweł Goleń, blog

Pod koniec stycznia odbędą się dwa spotkania OWASP:

• OWASP Kraków - 20 stycznia,
• OWASP Warszawa - 27 stycznia,

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łem wcześniej, wymaga innego poziomu "pewności", niż system bankowości internetowej.

Moja odpowiedź na pytanie ze strony podesłanej przez ^koto:

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 (...).