Twórcom i użytkownikom widgetów ku przestrodze

Prawie każdy blog, który w sieci można teraz znaleźć jest wzbogacony przez widgety. Takie małe wkładki, które dostarczają jakiejś dodatkowej informacji, albo są po prostu zabawne. Jednak jest kilka “ale”.

Najczęstszym sposobem osadzania takich widgetów to jest kawałek kodu JS, który wkleja się we własną stronę. Jest to łatwe i proste dla twórcy strony, ale nie zawsze myśli się o bezpieczeństwie takiego rozwiązania. Gdy umieszczasz na swojej stronie tag script, który ściąga kod w JavaScript, pozwalasz aby ten kod miał dostęp do wszystkiego co Twoi użytkownicy robią na Twojej stronie. W większości wypadków wydaje się, że ryzyko jest niewielkie i godzimy się na nie, gdyż w zamian zostaje dostarczony jakiś użyteczny ficzer.

W wypadku blogów ryzyko rzeczywiście wydaje się niewielkie, ale w dla stron firmowych może być już inaczej. Po pierwsze, jeśli Twoja strona w jakiś sposób służy do prowadzenia interesów, taki potencjalnie niebezpieczny kod może oznaczać wymierne straty finansowe dla Twojej firmy i klientów (przechwycenie sesji a co za tym idzie poufnych informacji).

A na dodatek ryzyko jest też innego rodzaju – wpadki ‘wizerunkowej’. Przekonało się o tym wydawnictwo O’Reilly. Ich strona Perl.com przez chwilę zawierała baner pornograficzny. Włamanie? Nie, przyczyna była wręcz prozaiczna. Domena partnera, który wyświetlał na głównej stronie Perl.com reklamy po prostu wyekspirowała. Została wykupiona (domena) przez firmę pornograficzną, która zorientowawszy się, że są wywołania do takiego pliku, wystawiła własny kod JavaScript, który zaserwował ich własny banner. Więcej można przeczytać na O’Reilly Radar.

Jest jeszcze jeden argument przeciw widgetom osadzanym przez tag script. Gdy strona zawierająca taki tag jest wyświetlana, w momencie gdy przeglądarka dojdzie do tego tagu zatrzymuje się dopóki skrypt nie zostanie ściągnięty i wykonany. Co oznacza, że strona może zamrozić się w wypadku problemów technicznych (przeciążenie, brak połączenia sieciowego z serwerem partnera) na kilka(naście) sekund. Jakże często widuje się to na naszych wspaniałych portalach.

Użycie iframe nie zabezpieczy przed wpadką jaką zaliczył O’Reilly ale przynajmniej poprawi wrażenia użytkownika (póki się nie załaduje skrypt, będzie się wyświetlała pusta ramka, a reszta strony wyrenderuje się bez zbędnych opóźnień) oraz zapewni separację (sandbox) cudzego kodu.

Popularity: 21% [?]