Wampiryczny blog

Prawie rok temu opisywałem działanie nagłówka X-FRAME-OPTIONS. Przygotowałem też prosty przykład, na którym każdy mógł sprawdzić jak jego przeglądarka obsługuje ten nagłówek. Dziś na krótko wrócę do tego tematu, a to z uwagi na wpis X-Frame-Options: zacznij stosować oraz komentarz(e) Bartka. Mam wrażenie, że clickjacking oraz CSRF trochę się ze sobą mieszają. Postaram się wytłumaczyć różnicę.

Jak już zauważył Gynvael wystąpię w tym roku na SecDay, będę mówił na temat bezpieczeństwa bankowości internetowej. Zamierzam skupić się na podstawowych mechanizmach bezpieczeństwa i przy okazji obalić(?) kilka mitów. Bo odbiór poziomu bezpieczeństwa stosowanych mechanizmów przez użytkowników często nie ma nic wspólnego z ich rzeczywistą skutecznością.

Jeśli ktoś miałby jakieś pytania lub sugestie odnośnie tego, o czym chciałby usłyszeć (w tym temacie), jestem otwarty na propozycje.

Niektóre polityki haseł są dziwne. Największe problemy sprawia mi maksymalna długość hasła. Kiedyś, gdy jeszcze pamiętałem swoje hasła, ciężko było mi się zmieścić z frazą w limicie. Teraz, gdy korzystam z KeePass moje domyślne ustawienia przy generowaniu haseł często przekraczają limit długości hasła. Efekty bywają różne.

Dziś w komentarzu ukash napisał:

(...) Poza tym ten przykład już nie działa - napis javascript i tak jest wychwytywany przez parser.

Rzeczywiście, parser zaczął działać lepiej, niż działał wcześniej. Dlaczego? Dlatego, że home.pl zmieniło wykorzystywaną wersję Pythona z 2.5 na 2.6. A w dokumentacji do HTMLParser z wersji 2.7 można znaleźć następujący fragment:

Changed in version 2.6: All entity references from htmlentitydefs are now replaced in the attribute values.

Oznacza to mniej więcej tyle, że mój przykład będzie zawierał o jedną podatność (no dobrze, to jest więcej niż jedna podatność, bardziej jakaś klasa podatności) mniej jeśli będzie uruchomiony z wykorzystaniem Python 2.6 lub Python 2.7. Myślę, że jest to doskonały przykład jak pozornie niewielka zmiana w środowisku może otworzyć/zamknąć wielką dziurę w aplikacji.

Obecnie skrypt powinien działać tak samo, jak wcześniej. Zmiany między HTMLParser w wersji 2.5 i 2.6 sprowadzają się do zmiany metody unescape, przynajmniej z tego, co na szybko sprawdziłem. Po prostu przeciążyłem nową wersję unescape przy pomocy "wersji oryginalnej", czyli tej pochodzącej z 2.5.

Kilka ciekawych komentarzy pojawiło się pod wpisem Ataki czasowe na OpenID i OAuth. Szczególną uwagę chciałbym zwrócić na kilka z nich.

Po pierwsze dwa komentarze Gynvaela. Pierwszy komentarz dotyczy (nie)skuteczności losowych opóźnień w trakcie uwierzytelnienia w kontekście ataków timing attacks. Drugi z nich z kolei dotyczy tego, jak działa operator równości dla stringów. Temat ten został poniekąd wywołany przeze mnie w dwóch komentarzach (pierwszy komentarz, drugi komentarz). Być może wrócę do tematu jak zmienia się czas porównania stringów w zależności od tego, gdzie się różnią. O ile będę miał trochę czasu na eksperymenty.

Drugi ciekawy temat podniósł Radekk. Twierdzi on, że wstawianie sztucznych opóźnień (sleep) do aplikacji jest złym pomysłem, gdyż może ułatwić atak DoS. Konkretnie wariant ataku polegający na wyczerpaniu dostępnych wątków/procesów. Jego uwaga jest słuszna, aczkolwiek warto zwrócić też uwagę na "otoczenie" takich opóźnień w aplikacji, o czym z kolei wspominałem ja. Po prostu w niektórych przypadkach wstawienie umiarkowanego sztucznego opóźnienia do aplikacji nie będzie miało istotnego wpływu na łatwość wykonania ataku typu DoS według opisywanego scenariusza.