Bezpieczeństwo HTML5 – podstawy (część 1.)

Wstęp

Informacja – potrzebujemy jej aby pracować, bawić się, komunikować, rozwijać. Dostęp do niej obecnie jest niewyobrażalnie prosty – komputery, tablety, smarfony i wiele innych urządzeń sprawia, że Internet jest zawsze na wyciągniecie ręki. Internet, czyli webaplikacje, które muszą sprostać wymaganiom milionów gadżetów. Jest to niemała rewolucja i duże wyzwanie.

Właśnie przez chęć zwiększenia dostępności do stron internetowych oraz przez potrzebę łatwej implementacji nowych rozwiązań, powstała nowa odsłona języka HTML.

HTML5 jest lekkim i niezwykle elastycznym językiem, który łączy coraz większą liczbę urządzeń w sposób zunifikowany. Na dobre zagościł już w Internecie i stał się narzędziem do tworzenia skomplikowanych stron, animacji 2D/3D, odtwarzania dźwięku lub nawet przetwarzania reguł biznesowych. To nie jest już stary HTML4 – niespójny potwór warstwy widoku – z którym trzeba było nieustannie walczyć i obudowywać przy wykorzystaniu przyjaźniejszych języków czy frameworków.

Wzrost popularności języka HTML5 jest ogromny. Trzy lata temu – w 2010 roku – nowa specyfikacja była tylko ciekawostką. Rok później byliśmy świadkami wyścigu przeglądarek w drodze do wsparcia HTML5. Kto by pomyślał, że w tym czasie sami „twórcy” języka szacowali, że specyfikacja zostanie ukończona w okolicach 2022 roku. Deklaracja ta została szybko zmieniona i obecnie W3C planuje ukończenie HTML5.0 już w 2014 roku. Potwierdza to wykładniczy wzrost zainteresowania specyfikacją zarówno wśród programistów, jak i zwykłych użytkowników.

Nowa technologia to niestety również wiele zagrożeń, które mniej lub bardziej dotkliwie mogą uderzyć w nieświadomych użytkowników i ich urządzenia. Dlaczego rozwiązania skupione wokół HTML5 są tak niebezpieczne? Skąd może nadejść niebezpieczeństwo i jak się przed nim chronić? Tego zagadnienia dotyczy cykl artykułów o bezpieczeństwie HTML5.

HTML5 – nowa jakość?

1.  Wojna standardów stron internetowych

Aby szerzej zrozumieć bezpieczeństwo HTML5 warto poznać tło tworzenia tej specyfikacji. Różnego rodzaju przepychanki oraz chybione decyzje miały bezpośredni wpływ na niejednoznaczną specyfikację, która obecnie jest wdrażana w przeglądarkach. Niejednoznaczność ta doprowadziła do wielu problemów bezpieczeństwa.

Zacznijmy od swoistej prehistorii webaplikacji – od statycznych stron internetowych.

W 1989 roku Tim Bernerse-Lee, przyszły założyciel konsorcjum W3C, publikuje pierwszą wersję specyfikacji HTML. Opisał w niej sposób formatowania dokumentów z wykorzystaniem dosłownie kilku znaczników. Dokumenty te były później udostępniane w sieciach lokalnych z wykorzystaniem protokołu HTTP, notabene również stworzonego przez tego samego człowieka.

W 1997 roku konsorcjum W3C założone przez Tim Bernerse-Lee (w skład którego wchodzili przedstawiciele lub przyszli pracownicy Apple, Microsoft, Adobe, Google oraz Oracle) wydało specyfikację HTML3.2. Kilka miesięcy później, przedstawiono HTML4.0, który był wzbogacony o technologie takie jak CSS, DOM, czy XML. Po kilku poprawkach z 1999 roku HTML 4.01 do dzisiaj funkcjonuje jako ostatnia, zatwierdzona wersja standardu, która nie jest zmieniana.

Wczesne specyfikacje HTML pojawiały się w czasach, gdy strony internetowe były treściami statycznymi, o funkcji czysto informacyjnej. Dopiero pod koniec lat 90. dzięki technologiom takim jak PHP czy Java, statyczne strony przerodziły się w dynamiczne, zmieniające swoją zawartość w zależności od poczynań użytkowników – zaczęły powstawać webaplikacje. Każda firma chciała mieć własną stronę internetową – czy to statyczną (wizytówka), czy dynamiczną (sklep). Wokół stron internetowych powstał wielki biznes, który zaczął wtłaczać ogromne pieniądze w inwestycje tzw. Dot-comów.

Jeśli chodzi o same technologie, to w okolicach 2000 roku aplikacje webowe były już wszechobecne. W3C zauważyło problemy w języku HTML4, który z jednej strony wybaczał wiele błędów składniowych, ale z drugiej strony nie mógł narzucić poprawnej składni (przeglądarki do tej pory mogą w dowolny sposób interpretować błędy składni HTML). Rozwiązaniem problemu miał być XHTML pokazany światu w roku 2000.

XHTML to odmiana HTML ściśle weryfikująca składnię, na zasadach obowiązujących w XML. XHTML był dobrym pomysłem, jednak miał równie duże grono zwolenników, jak i przeciwników. Z jednej strony stali ambitni webdeveloperzy, którym marzył się poprawny kod każdej strony internetowej, z drugiej strony – klient. A klient nie mógł pozwolić na to, aby drobny błąd powodował niezaładowanie się strony jego firmy.

Ostatecznie świat stał gdzieś pośrodku, a ponieważ XHTML nie był skłonny do kompromisów, to w praktyce wszyscy korzystali nadal ze standardu HTML4.01 – o tak, dla świętego spokoju. Do dzisiaj jest to najczęstszy  wybór webdeveloperów.

Rok 2001 – Internet już dawno nie jest kojarzony z prostymi, statycznymi stronami internetowymi. Mimo dużej dostępności do Internetu dla przeciętnych ludzi i jego rosnącej popularności, biznes Dot-comów dostał zimny prysznic. Na giełdach pęka tzw. „Bańka Dot-comów”, wiele firm bankrutuje i Internet przestaje być przyjazny (a może raczej prosty) dla biznesu. Przełożyło się to na złe emocje w branży i chociaż aplikacje webowe dalej były chętnie tworzone, to rozwój nowych standardów niejako stanął w miejscu.

Programiści mocno sfrustrowani niewygodnymi technologiami i ciągle rozrastającym się kodem, zaczęli tworzyć coraz lepsze frameworki. Po kilku latach przy użyciu paru sztuczek, niewygodne technologie połączono ze sobą tworząc AJAX, który nakreślił wizję tzw. „stron Web 2.0”. Granica między webaplikacjami i aplikacjami desktopowymi zaczęła się rozmywać.

W3C oczywiście zauważyło szanse rewolucji w branży i od 2004 roku zaczęło pracę nad XHTML 2.0. Miał to być język zmieniający bieg historii Internetu. Niestety nie zapewniał kompatybilności wstecz z XHTML 1.0 czy HTML4, co ostatecznie przesądziło o jego porażce, ale o tym za chwilę.

Niezależnie, również w 2004 roku, IAN Hickson związany z Netscape oraz Operą (a obecnie pracownik Google) założył grupę WHATWG – The Web Hypertext Application Technology Working Group. Do zespołu zaprosił wielu wybitnych badaczy z Apple czy Mozilla Foundation (co ciekawie Microsoft również otrzymał propozycję współpracy, którą jednak odrzucił).

WHATWG w bardzo dynamiczny sposób prowadziło prace nad technologiami, które dzisiaj utożsamiane są jako z HTML5. Były to m.in. technologie Web Forms 2.0 oraz Web Application 1.0. Szybko pojawił się szkic specyfikacji nowego języka Internetu, opartego na HTML.

Wszystkie propozycje WHATWG były bardzo dobre, przyszłościowe i dopracowane, jednak pozostawały w sferze ciekawostek. Twórcy przeglądarek nie chcieli wprowadzać żadnych z tych propozycji do swojego oprogramowania, więc pożytek z dokumentu WHATWG dla przeciętnego internauty był zerowy.

W międzyczasie postęp prac nad XHTML2.0 posuwał się w ślimaczym tempie. Konsorcjum W3C utknęło w machinie swoich założeń, przez co nie mogło określić jednoznacznej wizji standardu. Nieciekawa atmosfera projektu spowodowała, że 2007 roku W3C zdecydowało się na pewne nieczyste posunięcie, które paradoksalnie wszystkim wyszło na dobre. Konsorcjum pobrało prace standardu WHATWG, zmodyfikowało stworzony dokument opisanego języka, adaptując go nieznacznie do swoich założeń, i w styczniu 2008 roku udostępniło światu swoją wersję standardu. Dokument oficjalnie określono jako pierwszy szkic technologii HTML5.

Zagranie W3C może wydawać się nieczyste, ale i dzisiaj każdy ma prawo do pobrania specyfikacji WHATWG/W3C, zmodyfikowania jej, a następnie wypromowania nowego standardu. Oczywiście taka promocja nie jest łatwa, a autorytet W3C pozwolił wpłynąć na twórców przeglądarek, którzy zaczęli eksperymentować z nowymi funkcjami.

W roku 2011 już prawie każda przeglądarka posiadała pewne elementy HTML5. Coraz szybciej zaczęto wdrażać nowości nowego języka i proponować jego nowe rozszerzenia.

Obecnie, mimo tego że dalej mamy dwie równoległe specyfikacje HTML5 (W3C oraz WHATWG), język ten jest kojarzony przez każdego webdevelopera i jest zauważalny coraz częściej. Przeglądarki implementują większość z nowych funkcjonalności. Biznes znowu chętnie inwestuje w webaplikacje, które mogą być odwiedzane nie tylko na komputerach stacjonarnych, ale również na smartfonach, tabletach, telewizorach i wielu innych gadżetach. Z duchem zmian poszedł nawet Microsoft, który bardzo topornie wprowadzał HTML5 do Internet Explorera. W tym momencie Windows 8 oraz IE10 stawiają na rozwiązania odświeżonego języka.

HTML5 więc wygrał. Wypromował się jako wygodny, elastyczny i funkcjonalny język. Powoli zastępuje rozszerzenia flasha oraz javy w przeglądarkach. Internauci kochają gry, które dostarczają im rozrywkę na każdym urządzeniu, biznes ceni wydajność webdeveloperów HTML5, którzy nie muszą uczyć się wielu technologii.

Jesteśmy w dobie kolejnej rewolucji w Internecie. Panie i Panowie, nadszedł czas na boom HTML5. Boom nowych możliwości… i nowych zagrożeń, rzecz jasna.

2. Dobre strony nowych technologii

HTML5 uporządkował wiele elementów starego języka. Nowe znaczniki i atrybuty znacząco zmniejszają liczbę wstawek kodu Javascript, np. podczas zaawansowanej walidacji formularzy. Wymóg używania małych liter dla znaczników i atrybutów oraz wymóg używania cudzysłowów dla wartości atrybutów znacznie zmniejsza fantazje początkujących webdeveloperów. Warto też wspomnieć o tym, że usunięto wiele przestarzałych/nielogicznych znaczników, które nie miały dużych zastosowań (lub które, jak np. marquee, powinny trafić do warstwy widoku).

Sukces HTML5 spowodowany jest między innymi kompatybilnością wstecz do HTML4. Jeśli użyjemy nowych elementów, które nie będę zrozumiałe przez starsze przeglądarki, to oprogramowanie po prostu je zignoruje. Między nowymi znacznikami można wstawiać tekst, który zostanie wyświetlony przez starą przeglądarkę, informując użytkownika o zaistniałej sytuacji.

W skład HTML5 wchodzi wiele innych technologii, które znacznie zmniejszają ilość  kodu tworzonego w innych językach. Obsługa multimediów takich jak video, audio, webGL, webfont czy SVG pozwala na całkowitą rezygnację z pluginów Flash, Java czy Silverlight. Zwiększa to nie tylko bezpieczeństwo, ale również wygodę użytkowania.

 3. Nowe niejasności

Oczywiście nowy język Internetu to nie same superlatywy. HTML zawsze kojarzył się z wieloma niejasnościami i podobnie jest w wersji 5.

Po pierwsze, tak naprawdę istnieją dwie specyfikacje HTML5 – w wersji WHATWG oraz W3C. Długie dokumenty, nad którymi ciągle trwają prace, nie sprzyjają łatwemu przyswajaniu wiedzy. Pływająca specyfikacja to koszmar – co chwilę trzeba obserwować wprowadzane zmiany. W jednym momencie pewna technologia może zostać wycofana, a za kilka miesięcy na jej miejsce może pojawić się coś nowego. Działo się tak np. z webSQL, który teraz może zostać zastąpiony przez IndexedDB.

Niechęć do nauki spowodowana też jest wojnami „politycznymi” między twórcami przeglądarek. Z różnych powodów niektóre właściwości HTML5 nie są wprowadzane przez wszystkich, jak np. wybrane kodeki video. Programiści muszą więc przechodzić przez piekło pisania wielu wersji stron przystosowujących się do różnych przeglądarek używanych przez Internautów.

Mimo znacznego przyśpieszenia prac nad standardem, finalizacja specyfikacji nadal posuwa się w tempie specyficznym dla W3C. Nieprędko więc doczekamy się ostatecznej wersji dokumentu HTML 5.x, a do tego czasu nowe funkcje języka mogą różnie działać w poszczególnych przeglądarkach.

Jak sobie poradzić w takim gąszczu informacji na temat zmian specyfikacji? Z pomocą przychodzą serwisy takie jak http://caniuse.com, które na bieżąco monitorują nie tylko prace nad standardem, ale również nad jego implementacją w popularnych przeglądarkach. Stan wsparcia HTML5 w lutym 2013 roku przedstawia poniższy wykres:

 4. Nowe zagrożenia

HTML5 jest jakby rozszerzeniem starszego języka o nowe, dodatkowe technologie, komunikujące się ze sobą przez jednoznacznie określone API. Technologie te korzystają ze zdecydowanie większej liczby zasobów niż dotychczas miało to miejsce, np. z kontekstu karty graficznej, lokalnych zasobów plików, baz danych i wielu innych.

Tak duży wachlarz możliwości bezpośrednio przekłada się na zwiększenie prawdopodobieństwa wystąpienia błędu – nie tylko w aplikacji webowej, ale również w samej przeglądarce internetowej.

Błędy i przeoczenia czyhają dosłownie na każdym kroku, nawet jeśli nie używa się aplikacji HTML5 (a HTML4). Zanim jednak przejdziemy do ich opisu, krótko zobaczmy jak działa (web)aplikacja HTML5.

5.  Przykładowa aplikacja HTML5

Poniższy rysunek przedstawia prostą aplikację HTML5. Jest to elementarny szkielet strony, która zawiera tytuł, nagłówek strony, treść artykułu, pole oceny 1-5 oraz stopkę.

Łatwo można tu zauważyć bardzo duże podobieństwo do HTML4. Jest to główna zaleta HTML5. Aby zacząć pisać strony w nowej technologii wystarczy poznać kilka nowych znaczników, atrybutów oraz interfejsów API Javascript.

Widać również, że język HTML5 jest prostszy w stosowaniu od swojego poprzednika. Można to zauważyć chociażby po uproszczonym nagłówku <!DOCTYPE html> czy łatwiejszej do zapamiętania sekcji meta.

Oprócz całkowicie nowych kontrolek, takich jak pole wyboru zakresu input range, HTML5 wprowadza również znaczniki mające znaczenie czysto syntaktyczne. W powyższym przykładzie zastosowano znaczniki header, article oraz footer, które de facto mogłyby być zastąpione blokami div z odpowiednimi identyfikatorami i klasami.

Po co więc używać np. takie znaczniki jak footer zamiast konstrukcji <div id=”footer”>?  Stosujemy je w celu zwiększenia czytelności i logiki kodu samego w sobie. Łatwiej wtedy zarządzać skryptami oraz stylami CSS, gdy np. formatujemy element footer, a nie jedną z tysiąca klas lub identyfikatorów. Niby nic wielkiego, ale znacznie upraszcza to zarządzanie kodem HTML w większych serwisach.

Znamy już założenia języka HTML5, jego mocne i słabe strony. Poznaliśmy pokrótce proces jego standaryzacji oraz nauczyliśmy się wykorzystywać go w podstawowych zastosowaniach. Jest to wystarczający wstęp do samej technologii, a więc w zasadzie moglibyśmy już poznawać zagrożenia HTML5. Jednak, aby móc zrozumieć ich problematykę należy przybliżyć fundamentalną zasadę bezpieczeństwa nie tyle stron internetowych, co przeglądarek je wyświetlających. Mowa tutaj o Same Origin Policy (SOP), która w dobie HTML5 ma znaczenie jak nigdy dotąd.

Źródła

• Projekt inżynierski: „Haiq – narzędzie do automatycznego testowania aplikacji internetowych pod względem podatności na podstawowe wektory ataku”; Adrian Michalczyk i Katarzyna Konieczniak; Gliwice, styczeń 2012,
• CanIUse, Dr Mario Heiderich materials, Html5rocks,
• http://muppet.wikia.com/wiki/File:CookieMonster-Sitting.jpg#filelinks, http://www.sxc.hu,
• Przedruk i aktualizacja artykułu HTML5 Application Cache Poisoning – zatruwanie Facebooka krok po kroku  (za zgodą autora),
• http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html, http://www.w3.org/TR/offline-webapps/, http://www.html5rocks.com/en/tutorials/appcache/beginner/ .