Jak do tej pory nikt nie wykazał się wystarczającą spostrzegawczością. A przynajmniej nikt się nią nie pochwalił. Dla przypomnienia, chodzi o to zadanie: Ćwiczenie na spostrzegawczość.
W ramach podpowiedzi dwa obrazki, które różnią się drobnym(?) szczegółem. Co ta różnica oznacza, z czego ona wynika i jak ją wykorzystać?
Oryginał tego wpisu dostępny jest pod adresem Ćwiczenie na spostrzegawczość II: hint
Autor: Paweł Goleń
Prawie, bo jakoś nie tęsknię za czasami słusznie minionymi na tyle, by nawet w górach uczestniczyć w nudnym dość obrzędzie popularnie zwanym “stanie w kolejce”. Jak widać na załączonym obrazku chętni się znajdują. W liczbie sporej.
Dawno, dawno temu w ramach przewodnika po bezpieczeństwie aplikacji internetowych udostępniłem przykład związany z uploadem plików: Lekcja 16: XSS i SQLi w nazwie pliku.
Tym razem w oparciu o ten sam przykład ćwiczenie na spostrzegawczość: http://bootcamp.threats.pl/lesson16a/. Cel: SQLi. Powodzenia!
Oryginał tego wpisu dostępny jest pod adresem Ćwiczenie na spostrzegawczość
Autor: Paweł Goleń
Tak na wszelki wypadek, jeśli komuś przydarzyłoby się coś niepożądanego (np. tak jak tutaj: Historia pewnej infekcji), warto mieć na podorędziu kilka narzędzi. Jednym z możliwych sposobów postępowania w takim przypadku jest analiza pamięci fizycznej komputera. W takim przypadku pomocne mogą być:
Gdy w końcu uda mi się znaleźć trochę czasu, pokażę trochę więcej odnośnie wykorzystania tych narzędzi.
Oryginał tego wpisu dostępny jest pod adresem Kilka narzędzi na wszelki wypadek
Autor: Paweł Goleń
Bardzo wiele zapytań ofertowych dotyczących “audytu bezpieczeństwa” (w rzeczywistości przedmiot zamówienia z audytem ma niewiele wspólnego) zawiera założenie/wymaganie odnośnie zastosowania “metodologii black box “. Moim zdaniem w zdecydowanej większości wypadków takie podejście jest błędne, charakteryzuje się wyjątkowo niekorzystnym stosunkiem price/performance , lub mówiąc jeszcze bardziej “profesjonalnie”, niskim ROI. Proste pytanie – jakie zalety daje podejście black box? Ja nie jestem w stanie wskazać praktycznie żadnej wartości dodanej takiego podejścia, potrafię natomiast wskazać kilka istotnych jego wad.
No i co się tak gapi? Kozicy nie widział?
A poważnie – nie, nie miałem do tej pory okazji natknąć się na kozicę w Tatrach. Tym razem taka okazja natrafiła się aż dwa razy. W tym raz kozica popisała się biegiem na krechę z Kołowej Czuby w stronę Zadniego Stawu Polskiego.
Oryginał tego wpisu dostępny jest pod adresem Sierpniowy długi weekend 2011
Autor: Paweł Goleń
Najpierw (pewnie już znany) obrazek:
A później tekstowo:
Oryginał tego wpisu dostępny jest pod adresem Obrazkowo o hasłach
Autor: Paweł Goleń
Ponieważ zainteresowanie drugą częścią zadania (Bootcamp IIa: ciąg dalszy zadania) spadło, a ja mam kilka minut czasu, opiszę o co w nim chodziło. Jest to prawie rozwiązanie zadania. Prawie, bo rozwiązanie zadania dostępne jest w formie wizualnej: Bootcamp: lesson02a – hint/spoiler.
Warto zapoznać się z udostępnionym ostatnio przez OWASP dokumentem Session Management Cheat Sheet. Zawarte w nim wskazówki warto porównać z wymaganiami zdefiniowanymi w OWASP Application Security Verification Standard, zwłaszcza z rozdziałem V3 – Session Management Verification Requirements.
Z moich doświadczeń wynika, że obecnie większość aplikacji korzysta z wbudowanego we framework mechanizmu sesji. Jest to zresztą pierwsze z wymagań ASVS. Takie podejście jest o tyle dobre, że w większości przypadków standardowa obsługa sesji jest po prostu wystarczająco dobra. Mimo wszystko pewne problemy wciąż się powtarzają, w szczególności:
Mechanizmy związane z uwierzytelnieniem i kontrolą dostępu są po prostu nieskuteczne, jeśli atakujący jest w stanie ustalić lub wykraść prawidłowy identyfikator sesji ofiary.
Dodatkowo warto pamiętać również, że:
I w ramach bonusu: How and why session IDs are reused in ASP.NET.
Oryginał tego wpisu dostępny jest pod adresem OWASP: Session Management Cheat Sheet
Autor: Paweł Goleń
Ostatnio zdarzyło się coś. Tym czymś był komunikat antywirusa o wykryciu malware na jednym z zaprzyjaźnionych komputerów. Teoretycznie wszystko jest w porządku, malware jakoś wlazł, antywirus go znalazł i usunął. Po sprawie. No dobrze, tylko jak wlazł i czy aby na pewno nic po sobie nie zostawił?