W 1953 roku na uniwersytecie w Yale przeprowadzony został ciekawy eksperyment. Poproszono studentów ostatniego roku o zapisanie celów, jakie chcą oni osiągnąć w życiu. Po 20 latach wrócono do uczestników eksperymentu. Okazało się, że sprecyzowane cele miało jedynie 3%25 badanych. Jednocześnie okazało się, że te 3%25 uczestników zgromadziło majątek większy, niż pozostałe 97%25. Wyniki tego eksperymentu pokazują, jak w samodoskonaleniu ważne jest zdefiniowanie swojego celu.
Eksperyment ten ma tylko jedną wadę. Najprawdopodobniej nigdy się nie odbył...
Oryginał tego wpisu dostępny jest pod adresem Do celu
W trakcie testów często problemem jest to, że do końca nie wiadomo jakie parametry przyjmuje dany punkt wejścia. Czasami może się okazać, że dopisanie jakiegoś parametru spowoduje nieco inne zachowanie aplikacji. Jak powinien nazywać się parametr? Cóż, można próbować zgadnąć. Można też sprawdzić nazwy parametrów, które występują na danej formatce, na przykład jako pola hidden. Warto pamiętać, że parametr może być przekazany metodą POST lub GET, aplikacja nie zawsze te metody traktuje równorzędnie.
Dawno, dawno temu przygotowałem ten przykład Lekcja 21: Przykład – phishing na formatce logowania z wykorzystaniem XSS, ale nie wzbudził on specjalnego zainteresowania. Dziś postanowiłem go trochę zmodyfikować i teraz oprócz phishingu (jeśli ktoś chce, nadal może go sobie poćwiczyć), można na nim również przećwiczyć session fixation. Zadanie nie jest zbyt wymagające, choć przyda się trochę pomysłowości. Chodzi o to, jedyne cookie PHPSESSID wysłane przez przeglądarkę klienta przy próbie logowania było tym, które ustawi atakujący.
Zamiast wystawiania slajdów (są dostępne tutaj), postanowiłem zrobić mały przegląd swoich starszych wpisów i zebrać je w jednym poście. Dzięki temu jeśli ktoś jest zainteresowany tematem, będzie mógł poczytać trochę więcej, niż z suchych slajdów.
Jakie są skutki tego stanu rzeczy? Potencjalny replay attack. Oczywiście parametr Q może być losowy, w związku z czym replay attack staje się mało prawdopodobny. Pytanie – kiedy challenge (Q) jest nie do końca losowy?
Muszę powiedzieć, że moje wrażenia po SecDay są bardzo pozytywne. Prezentacje ciekawe, choć w większości dość niskopoziomowe. Z tej tematyki wyłamały się chyba tylko trzy tematy: ulot elektromagnetyczny, bankowość internetowa (mój, przy okazji: ZeuS Mitmo: Man-in-the-mobile (I) via ^rezos) oraz informatyka śledcza. Szczególne wyrazy uznania dla tej ostatniej prezentacji i dyskusji po niej. Doskonały przykład jak o informatyce śledczej można rozmawiać bez niepotrzebnego nadęcia.
Przez pewien czas używałem dodatkowo wiki, bo na blogu pewnych rzeczy robić nie mogłem. Gdy blog przeszedł całkiem pod moją kontrolę, wiki stało się zbędne. Powoli miałem wygaszać ten adres, ale wygląda na to, że home.pl mi w tym pomógł. Mam wrażenie, że zmienił wersję Pythona i coś przestało działać (patrz też: Dlaczego przykład przestał działać).
Jeśli jesteś bardzo zainteresowany jakąś treścią z wiki, daj znać, spróbuję ją ponownie gdzieś opublikować.
Już jutro odbędzie się konferencja SecDay 2010. Będę miał okazję poopowiadać trochę na temat bezpieczeństwa bankowości internetowej, w szczególności o podstawowych mechanizmach bezpieczeństwa oraz ich podatności na ataki phishingowe, oraz ataki z wykorzystaniem malware. Jeśli ktoś nie może być we Wrocławiu – nic straconego. Wojtek Dworakowski (Securing) będzie mówił na ten temat w Warszawie na konferencji Secure. Wojtek będzie mówił na ten sam temat, ale nie dokładnie to samo, więc jeśli ktoś się wybiera na obie konferencje, nie powinien się nudzić. W Krakowie jakaś wersja tej prezentacji pojawi się prawdopodobnie w grudniu. Zainteresowani powinni śledzić stronę OWASP Poland.
Do zobaczenia we Wrocławiu!
PS: To jeszcze chciałem dodać, że 28 października pojawię się na spotkaniu SPIN w Krakowie.
Miałem dziś okazję spotkać się ze znajomymi (pozdrowienia!), którzy zajmują się na co dzień nieco innymi tematami, niż ja. Rozmowa krążyła wokół różnych tematów (Grześ: Pan Samochodzik i..., Łukasz: local proxy). W pewnej chwili doszliśmy do tematów bezpieczeństwa bankowości internetowej i... No właśnie. Po raz kolejny przekonałem się, że coś, co jest oczywistą oczywistością dla mnie i ludzi zajmujących się tym tematem, wcale nie jest tak oczywiste dla “zwykłych ludzi”. A to właśnie “zwykli ludzie” stanowią większość użytkowników bankowości internetowej. Cóż, chyba będzie trzeba napisać trochę na temat tych oczywistości.
W mechanizmach kryptograficznych wykorzystywanych w ASP.NET wykryty został błąd. Microsoft opublikował stosowny dokument: Vulnerability in ASP.NET Could Allow Information Disclosure. Informacje na temat tej podatności są nieco chaotyczne, ale z kontekstu można przypuszczać, że pozwala ona nie tylko na rozszyfrowanie danych i ustalenie klucza, którym zostały zaszyfrowane.