Z punktu widzenia zarządzania bezpieczeństwem problem z HTML5 polega głównie na tym, że przejście na nowy standard zarówno po stronie użytkowników jak i autorów aplikacji ma charakter "pełzający". Specyfikacja HTML5 - formalnie nadal w trakcie opracowywania - jest traktowana obie strony jako otwarty katalog rozmaitych technologii, a te atrakcyjniejsze są implementowane po prostu wtedy, kiedy ich specyfikacja w miarę okrzepnie.

Tymczasem każdy nowy atrybut, tag czy styl wprowadzany przez HTML5 oznacza zmianę subtelną zachowania przeglądarki. Oznacza to niestety w praktyce, że techniki obrony, które były skuteczne dotychczas mogą stać się bezużyteczne. W szczególności dotyczy to autorów aplikacji, którzy stosują filtrowanie kodu HTML oparte o listy "niebezpiecznych" tagów. Jeśli dotychczas wystarczało blokowanie określonej grupy tagów (np. <script>) i atrybutów (np. onload=) to dzisiaj to już nie wystarczy. Czas filtrowania opartego o "czarne listy" się skończył i każda aplikacja webowa, która tę technikę stosuje albo już jest dziurawa albo z dużym prawdopodobieństwem będzie taką w przyszłości.

Zobacz również:

• Ta ustawa przybliża moment, w którym TikTok zostanie zablokowany w USA
• Chrome lepiej zadba o prywatność użytkowników. Czy na pewno?

Co więcej, istnienie podatności jest w dużym stopniu niezależne od samej aplikacji - to nowe funkcje pojawiające się w kolejnych wersjach przeglądarek powodują, że aplikacja, z której choć trochę wyciekają niefiltrowane dane użytkownika staje się podatna np. na Cross-Site Scripting za pomocą wektorów, nieznanych jeszcze 2-3 lata temu. I nie dotyczy to wyłącznie wąskiej grupki fanów nowych technologii - według statystykhttp://caniuse.com różne funkcje HTML5 obsługują już przeglądarki 70-97% użytkowników Internetu.

Na co więc należy uważać w pierwszej kolejności?

1. Wspomniane powyżej nowe tagi, atrybuty i style wprowadzone przez HTML5. Wśród ciekawostek można wymienić np. tagi <video>, <comment> czy nowe atrybuty tagu <iframe> - wszystkie pozwalają na osadzenie kodu JavaScript i w konsekwencji przeprowadzenie ataku. Obszerną listę elementów, które mogą stanowić potencjalną lukę do przeprowadzenia ataku Cross-Site Scripting można znaleźć na stroniehttp://heideri.ch/jso (patrz też Jak uniknąć Cross-Site Scripting w aplikacji?

2. Nowa logika formularzy HTML oraz funkcja autofocus. W HTML5 formularze nie muszą już przestrzegać ścisłej hierarchii XML (form -> input). Tagi <input> i <button> mogą być porozrzucane w dowolnych miejscach kodu strony, zaś przeglądarka rozpozna do którego formularza należą za pomocą atrybutu form=. Co ciekawsze, z poziomu pojedynczego pola można zmienić też adres docelowy oraz metodę. To kolejna zmiana, która doskonale ułatwi ataki XSS. Tutaj znowu można się bronić tylko przez bezwzględnie skuteczne filtrowanie danych od użytkownika, a wymówka "to nie zadziała bo wyświetla się poza formularzem" może się okazać fatalna w skutkach.

3. Ataki na kodowanie znaków - ze względu na nowe metody kodowania dopuszczane przez HTML5 kluczowe jest jawne deklarowanie kodowania każdej strony zwracanej przez serwer, najlepiej w nagłówkach HTTP (np. Content-Type: text/html; charset=UTF-8), nawet jeśli jest to domyślne (w przeszłości) US-ASCII lub ISO-8859-1. Jeśli kodowanie deklarujemy w nagłówkach META, to deklaracja ta powinna być zwracana jako pierwsza w bloku HEAD.

4. Cross Document Messaging (postmsg). To mechanizm pozwalający na ustandardyzowaną komunikację między "domenami" (w rozumieniu SOP) z poziomu JavaScript. Postmsg ma wbudowane kilka mechanizmów bezpieczeństwa, które mogą zapobiec "wstrzyknięciu" złośliwego kodu ale tylko wtedy, gdy programista faktycznie ich użyje i zrobi to poprawnie. Stosując Postmsg należy więc zapomnieć o gwiazdce (*) i zawsze weryfikować nagłówek Origin, nie zakładając, że będzie poprawny. Co więcej, dane przychodzące przez Postmsg należy traktować jak wszystkie inne dane przychodzące z zewnątrz - i filtrować.

5. Cross Origin Resource Sharing (cors) to nowa metoda implementacji żądań AJAX pomiędzy "domenami" (znowu w rozumieniu SOP). CORS również posiada wbudowane funkcje bezpieczeństwa, z których należy korzystać - np. tryb preflight. Danych przychodzacych z CORS nigdy nie należy również traktować jako zaufanych, a jako że są bloki JSON, które mogą być złośliwie zmanipulowane, nigdy nie należy ich "parsować" przez wpuszczenie na wejście funkcji eval().

6. Web Storage czyli znacznie udoskonalona wersja cookies, umożliwiająca przechowywanie nawet znacznych ilości danych po stronie klienta i odczytywanie ich z poziomu JavaScript. Zapewne ułatwi realizację zadań, do których trzeba było do tej pory wykorzystywać Flash lub Silverlight. Klientowi zapewnia również większą kontrolę nad tym co aplikacje przechowują w jego przeglądarce. Ponieważ WebStorage nie posiada żadnych mechanizmów bezpieczeństwa (poza SOP), a dane są przechowywane w postaci niezaszyfrowanej - nigdy nie należy umieszczać tam danych wrażliwych lub podatnych na manipulację.

7. Aplikacje off-line (offline-webapps) umożliwiają autorowi aplikacji przygotowanie "paczki", którą przeglądarka pobiera i przechowuje w długoterminowej pamięci cache, co umożliwia tworzenie aplikacji webowych działających także bez dostępu do sieci. Treść, którą normalnie ładowalibyśmy na żądanie w offline-webapps jest już po prostu dostępna na dysku. Z punktu widzenia bezpieczeństwa stwarza to możliwość trwałego zainfekowania nawet zwykłej strony przez wstrzyknięcie złośliwego kodu za pomocą mechanizmów offline-webapps. Aby zabezpieczyć użytkownika przed tym perfidnym atakiem należy po prostu stosować SSL w każdej aplikacji, w której autentyczność pochodzenia kodu strony jest istotna.

8. Web SQL (webdatabase) to jeszcze jeden mechanizm przechowywania danych po stronie użytkownika, który oferuje aplikacji JavaScript interfejs SQL - w odróżnieniu od Web Storage, które posługuje się interfejsem klucz/wartość. Implementacja webdatabase oferuje API podobne do SQLlite. Niezależnie od pozornej prostoty tego rozwiązania bazwzględnie należy przestrzegać wszystkich zasad bezpiecznego budowania zapytań SQL (Jak bezpiecznie pisać aplikacje webowe). Atak SQL injection przeprowadzony na webdatabase może na przykład umożliwić trwałe osadzenie złośliwego kodu JavaScript w przeglądarce użytkownika.

9. WebSockets to mechanizm stanowiący podstawę do implementacji własnych protokołów komunikacyjnych w aplikacjach pisanych w JavaScript. Umożliwia wykonywanie połączeń TCP z wielokrotnie mniejszym narzutem niż wcześniej stosowane rozwiązania tego typu oparte o tunelowanie w HTTP (np. Comet). Źle zaimplementowana aplikacja korzystająca z WebSockets umożliwi np. skanowanie lokalnej sieci. Sporo problemów można oczekiwać również tam, gdzie wymyślony przez autora aplikacji protokół oparty o WebSockets bedzie wymagał funkcji bezpieczeństwa bo historia pokazuje, że ta dziedzina jest jedną z najgorzej rozumianych przez programistów (patrz Meandry kryptografii).

10. Scalable Vector Graphics (SVG) to doskonała wiadomość dla autorów aplikacji, które dla wyświetlenia najprostszego wykresu musiały angażować Flash lub dynamicznie generowane bitmapy. SVG umożliwia wyświetlanie grafik wektorowych z poziomu kodu JavaScript (np. tag <circle> narysuje okrąg). Jednak specyfikacja SVG jest usiana potencjalnymi miejscami wstrzyknięcia kodu i przeprowadzenia ataku Cross-Site Scripting (na stroniehttp://heideri.ch/jso jest cała odrębna sekcja poświęcona SVG), dlatego implementując cokolwiek korzystającego z funkcji SVG należy podwoić czujność i mieć pewność, że filtrowanie danych w aplikacji działa perfekcyjnie.

Podsumowując, specjaliści od bezpieczeństwa nie powinni bać się HTML5. Powinni mieć jednak świadomość, że standard ten jest płynny i ma charakter katalogu produktów, z którego programiści będą z pewnością wybierać co atrakcyjniejsze techniki, należy zatem przeprowadzić wyprzedzające działania edukujące. Z przedstawionej listy wyraźnie widać, że absolutnie należy zadbać o skuteczność filtrowania danych przychodzących z zewnątrz do aplikacji webowej i Cross-Site Scripting jest atakiem, który HTML5 ułatwia chyba najbardziej. Z tego powodu należy we własnych aplikacjach bezwzględnie stosować filtrowanie oparte o parser HTML (dekompozycja i budowanie drzewa XML od zera), takie jakhttp://htmlpurifier.org lub OWASP ESAPI.

Artykuł został zainspirowany szkoleniem HTML5 Security przeprowadzonym przez Krzysztofa Kotowicza, publikacjami na jego blogu oraz artykułem na blogu Writing Secure Software.