Paweł Goleń, blog

Truizmem jest stwierdzenie, że człowiek jest najsłabszym ogniwem (bezpieczeństwa). Wydaje mi się, że za mało czasu poświęca się temu, by odpowiedzieć na pytanie dlaczego tak właśnie jest. Człowiek jest (tylko) człowiekiem, jest przez to "ograniczony". Ograniczony przez tysiące lat ewolucji, które w pewien sposób nas ukształtowały. Uważam, że z czasów, gdy nasi przodkowie musieli walczyć o przetrwanie, pożywienie i sukces reprodukcyjny, zostało w naszym zachowaniu dużo więcej, niż chcemy się do tego przyznać. Są też inne, prostsze(?), zagadnienia z psychologii, które mogą przydać się przy projektowaniu mechanizmów bezpieczeństwa. Używalnych mechanizmów bezpieczeństwa, cokolwiek to znaczy.

Ciekawa lektura: Anonymous speaks: the inside story of the HBGary hack. Warto przeczytać i zobaczyć jak wiele "małych" błędów prowadzi do całkiem sporej wtopy. A błędy były proste i typowe:

• wykorzystanie "autorskiego", podatnego na SQL injection CMS (a sql injection to nie jest wiedza tajemna),
• przechowywanie haseł w postaci łatwej do złamania (patrz też: O przechowywaniu haseł, Coś mocniejszego niż MD5, Are you sure SHA-1+salt is enough for passwords?),
• wykorzystywanie jednego hasła w wielu miejscach (patrz też: I dlatego warto mieć jedno hasło..., Jak korzystam z KeePass),
• podatność na social engineering (oczywista oczywistość: The Art of Deception: Controlling the Human Element of Security),
• używanie oprogramowania, które zawiera znane podatności,

W tej chwili zamiast się dowartościowywać wymyślając przemyślne epitety mające oddać brak profesjonalizmu ofiar ataku, lepiej zastanowić się, czy my sami się przed takim scenariuszem dobrze bronimy. To jak z tym jest?

Dla przypomnienia inna historia: Uczmy się na błędach: apache.org incident report. Znajdź części wspólne na tych obrazkach :)

UPDATE: W tym samym temacie HBGary hack: lessons learned.

Jeśli ktoś z czytelników ma trochę czasu do zmarnowania(?), to może niech go marnuje produktywnie. No, produktywnie przynajmniej dla mnie :) Chcę przeprowadzić pewien eksperyment, Wasz udział bardzo mi w tym pomoże.

O co chodzi? Przygotowałem prostą aplikację, która wyświetla przez kilka sekund kilka cyfr. Następnie te cyfry znikają, natomiast pojawia się pole do ich wpisania. Zadanie jest proste - spróbować przepisać wyświetlone wcześniej cyfry, lub przynajmniej tyle, ile udało się zapamiętać. Ilość wyświetlanych cyfr waha się od 3 do 10, czas ich wyświetlania zależy natomiast od ich ilości (sekunda na każdą cyfrę).

Przykład ten znajduje się pod adresem http://bootcamp.threats.pl/e/test01.php (wymaga włączonej obsługi JavaScript) i nie jest elementem mojego przewodnika po bezpieczeństwie aplikacji internetowych, więc proszę go nie hakować. Przykłady z przewodnika hakować oczywiście można :)

W trakcie porannej prasówki we wpisie Tomka (Autorization Manager - bestia i jak ją obejść) trafiłem na link do tego wpisu: Szkolenia programistyczne, czyli maszyna ssąco-uciszająca . Miażdżąca ocena szkoleń. Najgorsze jest to, że prawdziwa.

Znam Tomka i mogę praktycznie w ciemno założyć, że jego szkolenie było konkretne (treść) i ciekawe (forma przedstawienia, sposób mówienia, osobowość mówcy). Podobne odczucia mam w odniesieniu do kilku innych osób, co do których wiem, że łączą sporą wiedzę z umiejętnością ciekawego opowiadania. Znam też osoby, których wiedzę naprawdę podziwiam, ale na prezentacji/szkoleniu w ich wykonaniu wytrzymam góra 5 minut, potem zasnę, albo mnie trafi... I niestety też miałem wątpliwą przyjemność uczestniczenia w szkoleniach/prezentacjach, których treść i forma nie nadaje się nawet do /dev/null.

Otrzymałem ostatnio zapytanie odnośnie przechowywania danych sesji po stronie klienta. Było ono związane z drugim z przygotowanych przeze mnie wyzwań. Jednym z istotnych elementów tego zadania była analiza danych przechowywanych po stronie klienta, co wyjaśniam w opisie implementacji sesyjności w przykładowej aplikacji. Pytanie - czy dane sesji można bezpiecznie przechowywać po stronie klienta?