Lepiej czy gorzej z bezpieczeństwem Facebooka?

Aby skuteczniej zachęcać, korzystano także z niewidocznej pływającej ramki IFRAME, z facebookowym przyciskiem Lubię To! umieszczanej na różnych stronach. Kliknięcie przycisku odwoływało się do obiektów umieszczonych w przezroczystej ramce. W ten sposób zachęcano nowych użytkowników, prawdopodobnym celem ataków było szybkie rozpropagowanie złośliwego oprogramowania.

Walka z obcymi ramkami

Tego rodzaju ataków można uniknąć, wysyłając do przeglądarki nagłówek X-FRAME-OPTIONS: DENY, dzięki czemu można zapobiec wykorzystaniu ramek, w tym niewidocznych. Parametr ten ma dwie wartości - DENY oraz SAMEORIGIN, ta druga blokuje ramki spoza oryginalnego serwera. Blokowanie obcych ramek za pomocą tego nagłówka obsługuje obecnie Firefox, Internet Explorer 8, Opera oraz Safari, ale nie zawsze można tę ochronę zastosować.

Wiele witryn jest chronionych za pomocą kodu JavaScript, który przeładowuje całą zawartość bieżącego okna lub zakładki. Niestety, taką ochronę za pomocą JavaScriptu można łatwo obejść w Internet Explorerze, wprowadzając do ramki opcję <IFRAME SECURITY=restricted>.

Po stronie przeglądarki bardzo dobrą ochronę przed przechwyceniem kliknięć oferuje dodatek NoScript do przeglądarki Firefox, dostępne są także komercyjne aplikacje, takie jak GuardedID. Blokadę obcego kodu mogą zapewnić także niektóre pakiety ochrony antywirusowej.

Wszędzie SSL

Od niedawna Facebook obsługuje szyfrowanie SSL dla wszystkich stron serwisu (poprzednio zabezpieczenie stosowano tylko przy logowaniu). Dzięki temu przechwycenie sesji za pomocą sniffera i odpowiedniego oprogramowania będzie o wiele trudniejsze. Chociaż szyfrowana transmisja jest już dostępna, nie jest domyślnie włączona, należy zatem samodzielnie włączyć zaawansowane opcje bezpieczeństwa na stronie związanej z ustawieniami konta na Facebooku. Po włączeniu SSL niektóre aplikacje firm trzecich mogą nie działać, ale niedostatki te będą sukcesywnie naprawiane.

Obecnie SSL nie stanowi już dużego obciążenia dla serwerów - Matt Cutts, inżynier Google, twierdzi, że obciążenie produkcyjnych maszyn związane z szyfrowaniem transmisji nie przekracza 1% CPU, mniej niż 10 KB pamięci na jedno połączenie, i powoduje zwiększenie ruchu sieciowego nie więcej niż o 2%. SSL nie jest już zatem tak kosztownym obliczeniowo protokołem jak jeszcze kilka lat temu.


TOP 200