Tym bardziej że elementy HTML5 pojawiają się wraz z każdą nową wersją popularnych przeglądarek, a tym samym aplikacje webowe mogą stawać się coraz bardziej dziurawe. 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 przez obie strony jako otwarty katalog rozmaitych technologii, a te atrakcyjniejsze są implementowane, kiedy ich specyfikacja w miarę okrzepnie.

Tymczasem każdy nowy atrybut, tag czy styl wprowadzany przez HTML5 to subtelna zmiana zachowania przeglądarki. Niestety, w praktyce oznacza to, że skuteczne dotychczas techniki obrony mogą stać się bezużyteczne. W szczególności dotyczy to autorów aplikacji, którzy stosują filtrowanie kodu HTML oparte na listach "niebezpiecznych" tagów. Dotychczas wystarczało blokowanie określonej grupy tagów (np. <script>) i atrybutów (np. onload=), dzisiaj to już za mało. Czas filtrowania opartego na "czarnych listach" już 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 dziurawa w przyszłości.

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 statystyk 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? Przede wszystkim na wspomniane 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. Obszerna lista elementów, które mogą stanowić potencjalną lukę do przeprowadzenia ataku Cross-Site Scripting, znajduje się na stronie: heideri.ch/jso.

Niebezpieczna może być też 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, a 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.

Więcej o zagrożeniach, na które trzeba zwrócić uwagę w HTML5, na stronie: go.computerworld.pl/5ac5a