Nie ufaj przeglądarce

Błędy i luki w popularnych językach AJAX i JavaScript ułatwiają ataki na użytkowników. Dużą winę za istniejące zagrożenia ponoszą też programiści nie dbający o bezpieczeństwo kodu.

Błędy i luki w popularnych językach AJAX i JavaScript ułatwiają ataki na użytkowników. Dużą winę za istniejące zagrożenia ponoszą też programiści nie dbający o bezpieczeństwo kodu.

Nie tylko przeciętni użytkownicy Internetu, ale również programiści i administratorzy stron WWW często nie są świadomi, jak łatwo można paść ofiarą ataku, wykorzystującego najbardziej rozpowszechniony i popularny język JavaScript.

Aplikacje AJAX

Nie ufaj przeglądarce

Dzisiejsze aplikacje internetowe w niczym nie przypominają tych sprzed 5-6 lat. Oprócz tradycyjnej warstwy odpowiedzialnej za dynamiczne generowanie kodu HTML, stosowane są powszechnie usługi internetowe. Usługi te to API pozwalające na bezpośrednie odwoływanie się do logiki po stronie serwera, m.in. za pomocą języka JavaScript.

Zgodnie z zasadą tożsamego pochodzenia (same origin policy), zdefiniowaną ponad 10 lat temu, przeglądarki blokują bezpośrednią komunikację między stronami/skryptami działającymi w kontekście różnych witryn. Dlatego też, aby i wyświetlić np. listę towarów dostępnych w sklepie, użytkownik potrzebuje pośrednika - proxy, który pozwala na obejście tej zasady po stronie serwera.

Na pierwszy rzut oka wszystko wydaje się w porządku - twórcy witryn sami wybierają, z którymi aplikacjami można się komunikować i skąd wykonywane mają być skrypty. Ale w praktyce to przekonanie jest mylne.

Tradycyjne sposoby ataku

To zadziwiające, jak wielu programistów webowych jest nieświadomych potencjalnych zagrożeń. W przypadku większości ataków furtką dla intruzów są niezabezpieczone formularze, które pozwalają na wprowadzenie do bazy danych złośliwego kodu. Zostaje on następnie wykonany po wyświetleniu strony przez użytkownika (ataki te znane są jako XSS, cross-site scripting). Raz uruchomiony kod pozwala na kradzież ciasteczek, haseł i innych informacji. Nie jest to nowość, atak XSS jest znany od momentu wprowadzenia aplikacji webowych, opartych o bazy danych.

Nawet jeśli ktoś rygorystycznie filtruje treści pochodzące od użytkowników, zawsze może paść ofiarą "wyrozumiałości" przeglądarek, które w nieprawidłowy sposób próbują interpretować źle skonstruowany kod. Samy Kamkar - twórca kodu, który w krótkim czasie unieruchomił serwis MySpace, przyznał w jednym z wywiadów: "Nie było luki po stronie MySpace. Twórcy tej strony wykonali świetną robotę, aby ją ochronić, blokując dostęp złośliwych kodów, skryptów JavaScript itp. To, że byłem w stanie wprowadzić JavaScript przez ich filtry wynikło z pobłażliwości przeglądarek. Za pomocą sztuczki technicznej byłem w stanie wykonać kod JavaScript w niektórych przeglądarkach, nawet jeśli nie był on poprawny".

CSRF i JSON

Zasada tożsamego pochodzenia nie obejmuje obrazów lub znaczników <script/> w następującej postaci: <img src=http://www.good.com/basket.php? buy=12345"/>

<script type=" text/javascript" src=" http://www.good.com/getcontacts.asmx"></script>.Wprawdzie obraz nie pozwoli na pobranie istotnych danych, ale może na przykład doprowadzić do wykonania transakcji kupna w słabo zabezpieczonym sklepie internetowym. Przeglądarka wraz z żądaniem pobrania zasobu basket.php? buy=12345 wyśle bowiem ciasteczka jednoznacznie identyfikujące klienta sklepu (wystarczy wcześniej zalogować się z opcją "zapamiętaj mnie").

Znacznik <script/> pozwala natomiast intruzowi wykraść dane zapisane w bardzo popularnym obecnie formacie JSON. Warto dodać, że niewielu programistów kontroluje zawartość obiektów w notacji JSON przesyłanych na serwer. Prawie zawsze są one w locie przekształcane do postaci instancji klas Javy czy C#. CSRF (Cross Site Request Forgery) jest trudniejszy do naprawienia niż XSS czy SQL injection. Jego usunięcie wymaga przepisania całej aplikacji webowej, włącznie z formularzem i funkcjonalnością na stronie. A w połączeniu z XSS jest to atak szczególnie niebezpieczny.

Czy da się okiełznać JavaScript i AJAX?

JavaScript i przeglądarki są wciąż modyfikowane. Kolejne wersje przeglądarek udostępniają nowe funkcjonalności, np. Firefox 3 ma pozwalać na ominięcie zasady tożsamego pochodzenia. "Myślę, że ta funkcjonalność będzie niesamowicie użyteczna - w miarę jak zacznie się jej proces adaptacji, zobaczymy wiele nowych rozwiązań, szczególnie w obszarze aplikacji działających po stronie klienta i mashup'ów" - mówi John Resig z Mozilla Corporation. Na razie jednak odpowiednia specyfikacja nie została opublikowana przez organizację W3C.

Niestety tradycyjne metody analizowania zabezpieczeń aplikacji internetowych nie sprawdzają się. Takie są m.in. wyniki testu pięciu popularnych i dość kosztownych analizatorów zabezpieczeń, przeprowadzone przez Information Week. "Testowane aplikacje AJAX były relatywnie proste. Żadna z luk, których wykrycia można było się spodziewać, nie była zaawansowana i nie wymagała złożonej analizy kodu. Były to raczej tradycyjne luki aplikacji webowych dostępne tylko przez interfejs AJAX. Mimo to, w większości przypadków skanery nie potrafiły automatycznie sprawdzić błędów i wymagały współpracy człowieka".

Douglas Crockford z Yahoo sądzi, że przynajmniej krótkoterminowym rozwiązaniem może być podzbiór JavaScript określany jako Adsafe, który początkowo został wykorzystany przez Yahoo do tworzenia bezpiecznych reklam, ale może być także użyty w widgetach i innych składnikach mashup'ów. Natomiast Google opracował Caja - system umożliwiający zarówno statyczną, jak i dynamiczną weryfikację skryptów pod względem ich zgodności z przyjętym za bezpieczny podzbiorem języka.

Dopóki jednak inicjatywy te nie staną się popularne i nie pojawią się efektywne narzędzia do automatycznego testowania aplikacji AJAX, to podczas projektowania aplikacji internetowych warto trzymać się zasady: nigdy nie ufaj informacjom wysłanym przez użytkowników i nie powierzaj przeglądarce poufnych danych.


TOP 200