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