(X)HTML

Bezpieczeństwo w HTML5 - jak ustrzec się typowych błędów

  • 2013-10-16 10:15
  • 1 komentarz
  • 2193 odsłony
  • 4/6
HTML 5, mimo że wciąż znajduje się w fazie eksperymentalnej, jest jedną z najpopularniejszych składni budowania semantycznych, przyjaznych i nowoczesnych serwisów internetowych. Język wprowadza szereg nowych elementów strukturalnych i funkcjonalnych, które poza oczywistymi możliwościami, narażają aplikacje również na pewne niebezpieczeństwa. W krótkim wstępie do tematu bezpieczeństwa w HTML5 wymienić warto kilka przykładów nowych elementów, które nie były znane w poprzednich wersjach standardu, a więc: canvas (<canvas>), media (<audio>, <video>), formularzowe (<datalist>, <keygen>) czy semantyczne / strukturalne (<article>, <summary>, <nav>, <section> i inne). Wśród nowych funkcji dostępnych w ramach składni znajdziemy również między innymi: drag&dropa, geolokalizację, app cache, audio, video i wiele innych.

Interesującą opcją, z której można korzystać w ramach HTML5 jest Local Storage, znany również jako Offline Storage lub częściej Web Storage. Umożliwia on gromadzenie zdecydowanej większej ilości informacji aniżeli http cookie (od 5 MB do 25 MB w zależności od przeglądarki internetowej) i przez niektórych deweloperów jest uznawany jako rozszerzenie tego mechanizmu. Przeglądarki, które wspierają Web Storage, interpretują poniższy kod JavaScript:

// Umieszczenie danych w ramach Local Storage (poza sesją)
localStorage.setItem('key', 'value')
// Odczytywanie wcześniej zapisanych w Local Storage danych (poza sesją)
alert(localStorage.getItem('key'))


W ramach Local Storage nie jest rekomendowane przechowywanie szczególnie sensytywnych danych. Jeżeli chcemy, aby były bardziej bezpieczne, powinniśmy używać sessionStorage, jeżeli tylko dane nie są potrzebne w sposób ciągły (dane zawarte w sessionSotrage będą dostępne do zamknięcia okna/karty). Atakiem, który może zostać użyty do wyciągnięcia danych z Local Storage, podobnie jak do prostego wstrzyknięcia tam danych, jest atak Cross Site Scripting (XSS). Ataki te są dostępne, ponieważ dane są zawsze dostępne z poziomu JavaScriptu, jak w przykładzie kodu odpowiedzialnego za umieszczanie oraz odczytywanie tych danych.

Inną często używaną opcją dostępną z poziomu HTML5 jest sandboxed frame, które powinny być używane jako <iframe> dla niezaufanych treści. Atrybut sandbox w ramach elementu <iframe> włącza predefiniowane ustawienia dla zawartości wewnątrz ramki, zabezpieczające między innymi przed tworzeniem nowych okien (poprzez window.open oraz target=”_blank”), wysyłaniem zawartych wewnątrz ramki formularzy, czy obsługą javascriptu wewnątrz ramki (zmniejszenie ryzyka ataków XSS).

Dzięki poniższym atrybutom restrykcje mogą być ograniczane (przykłady):

allow-popupspozwala na działanie pop-upów w ramach zawartości ramki
allow-formspozwala na wysyłanie formularzy
allow-scriptspozwala na wykonywanie plików javascript


Dzięki powyższym zabezpieczeniom jest możliwość posiadania zdecydowanie większej kontroli nad tym, co jest przywoływane wewnątrz ramki. Są to metody szczególnie istotne wtedy, gdy nie mamy stuprocentowej pewności, że aktualna zawartość iframe’a nie zmieni się (np. przy przywoływaniu zawartości strony, której administratorami nie jesteśmy).  

W przeglądarkach, gdzie ta funkcja nie jest wspierana (np. w Operze), zostanie zignorowana i <iframe sandbox> wywoła się identycznie jak element <iframe>.

Poza atrybutem sandbox istnieją również inne metody zabezpieczenia przed clickjackingiem oraz niebezpiecznymi treściami dostarczanymi poprzez ramki. Zamiast uznawanych za przestarzałe rozwiązań takich jak framebusting if(window!== window.top) { window.top.location = location; },  rekomendowane jest używanie znacznika header X-Frame-Options, przyjmujący dwie wartości:

SAMEORIGINwitryna może być przywoływana w iframie tylko w ramach domeny
DENYwitryna nie może być przywoływana w iframie przez żadną witrynę

Dzięki temu zabezpieczamy się przed umieszczeniem naszej strony w ramkach.

Następnym zagrożeniem istotnym w kontekście HTML 5 jest clickjacking ponownie na przykładzie elementu <iframe>. W przypadku przeglądarki Internet Explorer istnieje możliwość umieszczania elementu <iframe> wewnątrz tagu <a>. Poprzez kliknięcie na element nieklikalny wewnątrz ramki wykona się URL zdefiniowany w atrybucie href elementu <a>. Przykładem zagrożenia jest następujący kod:


<a href="http://attackingurl.com"> <iframe src="http://example.org/"></iframe> </a>


W HTML5 istnieje także możliwość zabezpieczania witryny odpowiednim podejściem do nagłówków. Zabezpieczeniem przed X-XSS może być opcja Enable XSS filter (działa jedynie dla Reflected XSS). Przykładem jej zastosowania jest X-XSS-Protection: 1; mode=block. http Strict Transport Security (HSTS) natomiast może pomagać w atakach polegających na ominięciu SSLa (SSL skip attack).

Końcową uwagą dotyczącą zagrożeń generowanych przez składnię HTML5 jest odniesienie owych zagrożeń i ich rozwiązań do relacji pomiędzy HTML5 a przeglądarkami, którym jest serwowany. Otóż, pytanie o to, czy dana przeglądarka wspiera HTML5 i przez to jej użytkownik zostanie zabezpieczony przed danymi ryzykami, jest pytaniem błędnym ponieważ odpowiedź na nie nie może ograniczać się do prostego „TAK” lub „NIE”. Poprawnie zadane pytanie powinno brzmieć, czy i w jaki sposób konkretna wersja danej przeglądarki wspiera konkretną wersję i element HTMLa5. To podejście oznacza konieczność indywidualnego podejścia do konkretnych funkcji języka i analizowania zagrożeń i remedium na nie per konkretny przypadek.

Autorzy: Mateusz Jabłoński @ http://www.datalab.pl/

1 komentarz

Brak avatara
Autor tekstu 2014-04-11 16:38

Panie Mateuszu, nie jest Pan autorem tego tekstu. Dlaczego się Pan pod nim podpisuje?