;)

Tak. Łatwe to nie jest.
W wolnej chwili polecam przejrzeć kod framebustingowy Twittera. Oni tam mocno kombinują, robią magię i im to zazwyczaj wychodzi ;)

Racja, ale to trochę kłopotliwe.

Dawid napisał niżej dobrą odpowiedź.
Referer się pojawi w normalnej wyszukiwarce - ale referera zawsze można oszukać.
Ogółem ramka to zwyczajny request wysłany przez przeglądarkę użytkownika (ofiary) - tak jakby strona była otwarta w nowym oknie.
Zawsze można wykrywać własnym algorytmem taką sytuację - ale trudno mi sobie wyobrazić coś lepszego od Framebustingu oraz X-Frame-Options.

Tak, dokładnie. Framebusting trzeba implementować, bo dalej jest dużo ludzi z IE6-7. Framebusting jednak trzeba robić prawidłowo.
Po co tracić kilka promili użytkowników (stara przeglądarka + wyłączony JS) nie zapewniając dodatkowo zabezpieczeń?

@snup, @piotr
Na prawdę mam świadomość, że dużo z tym zrobić nie można. Z drugiej strony - no bez przesady! Takie błędy powinny być wykrywane na jakiś podstawowych unit testach (i to niekoniecznie związanych stricte z testami bezpieczeństwa).
Dzisiaj XSS, wcześniej trochę podobny SQLi. Wordpress ma dziwny proces developerki. Nie wyobrażam sobie, aby tak skomplikowany CMS robić bez testów automatycznych. Jak widać - chyba można.

Dzięki za te dodatkowe informacje, nie miałem po prostu czasu aby je sprawdzić.

;)

Chciałbym, aby ten artykuł był odbierany jako badania na temat bezpieczeństwa przeciwko atakom Clickjacking polskich aplikacjach na przykładzie bankowości. Clickjacking to Clickjacking, koniec kropka. Kilka osób wypominało, że przecież to ani SQLi, ani XSS, więc o czym tu w ogóle mówić... W takim wypadku polecam dwa razy przeczytać tytuł artykułu oraz uświadomić sobie, że istnieje jeszcze kilka innych wektorów ataku niż SQLi oraz XSS ;)

Dziękuję za obszerny komentarz, w szczególności, że do napisania tego artykułu natchnął mnie właśnie sam OWASP (a dokładnie podobne badania w 2010 w tematyce framebusting stron rankingu Alexa TOP500).

Kilka razy spotykałem się z opiniami, że przeprowadzenie ataku Clickjacking w ebankowości jest trudne, męczące, a niebezpieczeństwo jest znikome. Całkowicie się z tym zgadzam, jednak podkreślam, że niebezpieczeństwo istnieje i jest szansa go wykorzystać aby osiągnąć konkretny cel (przykładowo jeden z badanych przeze mnie banków umożliwiał zapamiętywanie formularza hasła w przeglądarce).

Wiem również, że wyciągnięcie pieniędzy ofiary jest piekielnie trudne (przez clickjacking). Z drugiej strony witryny ebankowości udostępniają coraz więcej funkcji. Czasem przeciągnięcie samych danych o użytkowniku z jakiegoś formularza zmiany danych może wystarczyć cyberprzestępcom.

Sam pracowałem kiedyś w jednym z banków i wiem jak trudny jest proces wprowadzania najdrobniejszych zmian. Nie tyczy to się tylko banków - pomagam robić pentesty w kilku dużych projektach IT i sam proces akceptacji SUGESTII zmian czasem może przeciągać się parę tygodni, nie mówić o implementacji, testowaniu, wdrożeniu itd... Doskonale zdajemy sobie z tego sprawę. W zasadzie to najbardziej doczepiłem się do śpiewki bredni pokazywanej w mass mediach, gdzie banki zawsze oferują nam pomocną dłoń, zawsze chcą nas wysłuchać, zawsze doradzić itd. Jak widać - nie zawsze ;)

Bardzo dziękuje za propozycję prezentacji - jednak w tej chwili (z wielkim żalem) muszę odmówić. Mam zbyt mało czasu, aby przyjechać do nieodległego Krakowa na same spotkania OWASP (byłem tylko raz). Za pewien czas się to zmieni (gdy ostatecznie skończę studia) i mam nadzieję, że nie raz będziemy mieli okazję wymienić się wiedzą :)