Paweł Goleń, blog

Eben-Emael czy Linia Maginota się nie sprawdziły. Bo druga wojna światowa nie była taka, jak ta pierwsza. Mówi się, że “generałowie przygotowują swoje armie do wojny, która już była”. Mam czasem wrażenie, że podobne zachowania w zakresie bezpieczeństwa, nie tylko bezpieczeństwa IT, również nie są niczym niezwykłym...

Oryginał tego wpisu dostępny jest pod adresem Wojny, które już były

Autor: Paweł Goleń

Takie nawiązanie do wpisu Jak bardzo można ufać swojemu oprogramowaniu?, w szczególności do jednego z komentarzy, jego fragment:

(...) Z punktu widzenia użytkownika lepsza jest sytuacja z wykryciem i naprawieniem błędów “hurtowo” – dłużej używa bezpieczniejszego softu. (...)

Wiele razy powtarzałem, że bezpieczeństwa nie buduje się przez przyklejanie łatek. Zastanawiałem się jaką wykorzystać analogię by obrazowo wytłumaczyć dlaczego. Chyba w końcu mam pomysł – nasze wspaniałe drogi!

Czytaj dalej...

Był sobie przykład, takie wyzwanie. Żył sobie spokojnie, aż przyszedł ^koto, miał trochę zabawy i go zmiażdżył :) Gratulacje! Przy okazji warto polecić blog Krzyśka, przypomnieć o projekcie XSS-Track (brał udział w Top Ten Web Hacking Techniques of 2010 ) i o szkoleniu Hacking HTML5 jego autorstwa.

Dla porządku trzeba odnotować również dwa wcześniejsze raporty, których autorem jest Ice. Zainteresowani walką z tym przykładem (można kopać leżącego) mogą również skorzystać z pierwszego pakietu wskazówek, które udostępniłem w ramach wyjaśnień. Myślę, że takich pakietów pojawi się jeszcze kilka.

Czy będzie kolejna wersja tego zadania? Przypuszczam, że tak. To, że błędy zostały zaraportowane wcale nie znaczy, że w kolejnej wersji wszystkie muszą być poprawione skutecznie :)

EDIT: How to get SQL query contents from SQL injection flaw

Oryginał tego wpisu dostępny jest pod adresem Bootcamp XXV: był sobie przykład

Autor: Paweł Goleń

Liga broni, liga radzi, liga nigdy cię nie zdradzi!

Tak się zastanawiam ile osób zostało obrobionych w trakcie czytania tego komunikatu...

Oryginał tego wpisu dostępny jest pod adresem Rozpraszacze (uwagi)

Autor: Paweł Goleń

Jedną z usług Google są Google Groups. Pozwala ona między innymi na tworzenie grup dyskusyjnych. Mam jedną taką małą grupę pod opieką, grupa ta w zasadzie pełni rolę listy dystrybucyjnej. Jest to grupa zamknięta, zapisać się na nią mogą wyłącznie osoby zaproszone, adres do listy może dodać również moderator.

Pora na zagadkę – w pewnej chwili jedna z osób zapisanych na grupę zgłosiła mi, że otrzymała wiadomość wysłaną na grupę na adres inny niż ten, który został do grupy dodany. Po sprawdzeniu listy adresów okazało się, że adres taki rzeczywiście znajduje się na liście od, uwaga, ponad dwóch miesięcy(!) Sprawdziłem eksport listy adresów z tego okresu i... tego “nowego” adresu na niej nie było. To jeszcze nie wszystko. Okazało się, że z listy zniknął właściwy adres osoby zgłaszającej problem. W zasadzie wyglądało to tak, jakby adres prawidłowy został zastąpiony innym adresem. Co więcej nowy adres nie należał do tej osoby, ale osoba ta była z nim, nie wdając się w szczegóły, powiązana. Cuda? A może błędy W GMatrix?

Oryginał tego wpisu dostępny jest pod adresem Googlozagadka

Autor: Paweł Goleń

Moje ostatnie wyzwanie utknęło na dwóch rozwiązaniach. Do jego trzeciej wersji (http://bootcamp.threats.pl/lesson25b/) nie otrzymałem do tej pory żadnego zgłoszenia. Zarówno zgłoszenia błędu, jak i “dowodu”, że błędu/błędów w tej wersji już nie ma.

W ramach podpowiedzi pytanie naprowadzające – czy jest możliwość rozróżnienia sytuacji, w której żadne dane nie są wyświetlane, bo zapytanie SQL ich nie zwróciło i sytuacji, w której dane nie są wyświetlane, bo wystąpił błąd w trakcie wykonania zapytania SQL?

I jeszcze jak wyglądają w tym przykładzie następujące kwestie (ASVS):

  • V5.2 Verify that a positive validation pattern is defined and applied to all input.
  • V5.3 Verify that all input validation failures result in input rejection or input sanitization.

Oba pytania z sekcji V5 – Input Validation Verification Requirements.

Oryginał tego wpisu dostępny jest pod adresem Bootcamp XXV – hint

Autor: Paweł Goleń

No straszni ci hakerzy... Hakerzy sparaliżowali handel CO2. Miliony euro strat., cytat z artykułu:

Hakerom udało się złamać zabezpieczenia rejestrów i wykraść uprawnienia do emisji, które natychmiast zostały sprzedane – poinformowała KE (...)

Mam niejasne wrażenie, że ten cały system obrotu pozwoleniami na emisję CO2 był gorzej zabezpieczony, niż typowa (w sensie – niezbyt wybitna) bankowość internetowa. Przecież te “certyfikaty” mają wymierną wartość. Nikt nie wpadł na pomysł, że ktoś będzie chciał je mieć?

Luźne przypomnienie starego wpisu: Gdy są fanty do wyjęcia, ktoś będzie chciał je mieć. Zgadnijcie co tym razem wystąpiło w roli fantów :)

UPDATE: CO2 phishing

Oryginał tego wpisu dostępny jest pod adresem HaCO2erzy

Autor: Paweł Goleń

Wczoraj odbyło się spotkanie OWASP. W trakcie spotkania dostępna była jego transmisja, będzie wideo ze spotkania. Jak zwykle po takim spotkaniu pojawia mi się kilka pomysłów/uwag do prezentacji. Być może jakoś znajdą one odbicie w kolejnych wpisach, może poczekają sobie na lepsze czasy. Teraz tylko krótki komentarz.

Czytaj dalej...

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ę?

Oryginał tego wpisu dostępny jest pod adresem ASVS: (...) sessions timeout after a specified period of inactivity

Autor: Paweł Goleń

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

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.

Oryginał tego wpisu dostępny jest pod adresem Styczniowe spotkania OWASP

Autor: Paweł Goleń