Każda organizacja w swojej codziennej działalności intensywnie korzysta z wielu różnorodnych aplikacji. Coraz więcej z nich jest opartych na mechanizmach webowych, co stopniowo uznaje się za standard. Podłączenie do sieci oznacza łatwy i szybki dostęp do usługi w zasadzie z dowolnego miejsca czy komputera. O ile dla klientów usługi online stanowią znakomite udogodnienie, o tyle dla dostawcy są koszmarem związanym z utrzymaniem i walką z zagrożeniami pochodzącymi z sieci.

Patrząc na rynek e-commerce w 2008 r., można powiedzieć, że w kwestii bezpieczeństwa aplikacji webowych był to dość ważny rok. W szczególności istotny dla organizacji z sektora finansowego, prowadzących transakcje elektroniczne lub przetwarzające informacje związane z kartami kredytowymi. W czerwcu ub.r. upłynął bowiem termin spełnienia wymagań stawianych przez standard PCI-DSS. Spóźnialscy muszą liczyć się z przykrymi konsekwencjami - np. karami finansowymi w przypadku wycieku danych. Stąd też rosnące zainteresowanie bezpieczeństwem tychże aplikacji.

Pamiętajmy jednak, że aplikacje webowe to nie tylko "poważne" serwisy internetowe. To także oprogramowanie do zarządzania routerami czy innymi urządzeniami ... Według Gartnera, aż 2/3 przeprowadzanych obecnie ataków kierowanych jest przeciwko aplikacjom webowym. Dzieje się tak nie bez powodu. Czytając raporty na temat bezpieczeństwa np. Symanteca czy Gartnera, wyraźnie widać, że w dalszym ciągu lwia część aplikacji jest źle zaprojektowana lub źle zabezpieczona. Co więcej, w ponad połowie przypadków wykorzystanie luki nie wymaga specjalistycznej wiedzy, a jedynie kilku powszechnie dostępnych narzędzi (o czym dalej). Ten smutny obraz potwierdza w swoim ostatnim raporcie Websense (Websense Security Labs State of Internet Security Q1-Q2 2008). Wynika z niego, że ok. 75% witryn infekujących kodem złośliwym to skutecznie zaatakowane legalne witryny.

Wszędzie czyhają zagrożenia

Mówiąc o bezpieczeństwie aplikacji webowych, trzeba sobie zdawać sprawę z kilku spraw. Po pierwsze, fakt, że pracują one w warstwie siódmej nie oznacza, że nie staną się przedmiotem wielu innych ataków. Zależy, jaki jest cel. Czasem łatwiej przeprowadzić atak w warstwie niższej i "położyć" serwis skutecznym DDoS-em. Sprawcy mają zatem bardzo dużo możliwości, zanim dotrą do warstwy siódmej.

Po drugie, warto uświadomić sobie, czym jest taka aplikacja. Faktycznie, to nie jeden, ale wiele powiązanych systemów, których niewielką część stanowi prezentowany użytkownikowi usługi portal. Sercem całości jest baza danych przechowująca kluczowe informacje, do której portal odwołuje się za pośrednictwem silnika pośredniczącego. Ten z kolei może składać się z następnych elementów. Każdy z tych klocków to przedmiot potencjalnych ataków.

W przypadku aplikacji webowych na problem bezpieczeństwa trzeba spojrzeć bardzo szeroko. Jest to ten szczególny rodzaj usługi, z którą wiąże się dość duża liczba prac deweloperskich, a same projekty nie należą do prostych. Stąd szczególne miejsce w bezpieczeństwie aplikacji webowych zajmuje właściwe opracowanie ich "cyklu życia" i rozwoju. Począwszy od koncepcji, poprzez czystą deweloperkę, testy akceptacyjne, wdrożenie na produkcję, po zarządzanie zmianami. Trudno winić deweloperów za to, że skupiają się głównie na stronie funkcjonalnej, zapominając przy tym o bezpieczeństwie. Można im jednak przypominać, wprowadzając do cyklu SDLC (Software Development Life Cycle) odpowiednie założenia.

Innym bardzo poważnym zagrożeniem, które należy brać pod uwagę na etapie projektowym, są błędy w logice systemu, np. możliwość uzyskania tych samych informacji różnymi kanałami, bądź wykorzystanie prawidłowych mechanizmów niezgodnie z koncepcją autora. Błędów tych nie wykryją standardowe narzędzia testujące podatności, ale... i tutaj jest promyk nadziei (o czym za chwilę).

Kolejnym zagrożeniem jest fakt, że rzadko kiedy cała aplikacja jest tworzona przez nas. Z reguły wykorzystuje się wiele gotowych elementów, takich jak serwer webowy, silnik bazodanowy itp. Musimy tutaj zaufać temu, że dostawca zadba o odpowiedni poziom bezpieczeństwa tego elementu, ponieważ oprócz konfiguracji zgodnej z jego zaleceniami i przeprowadzania regularnych aktualizacji oprogramowania - nie możemy wiele więcej zrobić. Wybierając komponenty, powinniśmy sprawdzać, jak szybko producent jest w stanie zareagować na odkrytą podatność i wypuścić odpowiednią łatę. Docelowa aplikacja webowa musi z reguły współgrać z wieloma innymi systemami (np. ERP, CRM). Dlatego też warto zwrócić uwagę na ewentualne błędy przy wdrażaniu mechanizmów komunikacyjnych pomiędzy kawałkami webowej układanki.

Wiele cennych porad zarówno na temat projektowania aplikacji webowych, jak i możliwych problemów znajdziemy na stronach inicjatywy OWASP (Open Web Application Security Project) -http://www.owasp.org . Projekt ten dostarcza również informacji o lukach i związanych z nimi atakach na aplikacje webowe, które były najczęściej wykorzystywane - raport TOP 10 (ostatnia wersja jest z 2007 r.). Do tego raportu odwołuje się również PCI DSS. Trzy pierwsze pozycje na liście zajmują: ataki XSS (Cross-Site Scripting), grupa ataków typu "injection" oraz wykonanie kodu złośliwego.

Warto również zajrzeć na strony Web Application Security Consortium (WASC) -http://www.webappsec.org - organizacji, która podobnie jak OWASP promuje ideę bezpiecznych aplikacji webowych i publikuje własną listę. Tutaj dwa najpoważniejsze zagrożenia to XSS oraz SQL Injection. Statystyki te wydają się potwierdzać także doniesienia z ostatnich miesięcy. Na popularności zaczyna zyskiwać dość prosty, ale rzadko przeprowadzany do tej pory atak - CSRF (Cross-Site Request Forgery). Trend ten potwierdza analityk bezpieczeństwa z WhiteHat Security Jeremiah Grossman. Według niego CSRF są wykorzystywane znacznie częściej, ponieważ obrona przed nimi to coś więcej, niż tylko aplikowanie poprawek. Zatem w dużym skrócie sprawdźmy, na czym polegają ataki SQL Injection, XSS oraz CSRF.

SQL Injection należy do dość dużej grupy ataków "wstrzykujących informacje". Równie dobrze w miejsce SQL moglibyśmy podstawić HTML, LDAP czy XSLT. W przypadku SQL Injection chodzi o uzyskanie dostępu do informacji w bazie danych, do których w normalnych warunkach nie udałoby się dotrzeć. Celem może być nie tylko kradzież danych (choć ten motyw ataku jest najczęstszy), lecz także ich modyfikacja lub zafałszowanie. Atak ten, w pełni zautomatyzowany, na bardzo szeroką skalę zaczął być przeprowadzany w 2007 r. Na przełomie 2007 i 2008 ponad 70 tys. serwisów padło jego ofiarą. Podobnie jak w przypadku opisanego poniżej XSS, SQL Injection jest związany z niewystarczającą kontrolą danych wejściowych i brakiem mechanizmów "czyszczących" nieuprawnione elementy zapytania. Ataki SQL Injection często wykorzystują procedury "xp_cmdshell","OPENROWSET" oraz "OPENDATASOURCE" - domyślnie obsługiwane zarówno przez MS SQL 2000, jak i wersję 2005. Wyłączenie tych procedur już na wstępie zwiększa poziom bezpieczeństwa serwera, choć jest zaledwie promilem możliwych do podjęcia działań obronnych.

XSS (Cross-Site Scripting) to statystycznie jeden z popularniejszych ataków. Jest związany z brakiem kontroli nad danymi wejściowymi. Dzięki temu atakujący może wywołać kod wykonywalny z poziomu przeglądarki użytkownika w kontekście odwiedzanej witryny. Jego skutki mogą być poważne, np. dane dotyczące sesji z portalem bankowości internetowej są przesyłane do atakującego, co pozwala na podszycie się.

Wreszcie najmniej popularny z całej trójki ataków - CSRF (Cross-Site Request Forgery). Jest prosty w działaniu, ale niezwykle skuteczny. Jednym z najgłośniejszych przykładów ataków tego typu było wykradnięcie danych z popularnego portalu aukcyjnego w Korei, dotyczących 18 mln klientów. Innym kuriozalnym i barwnie opisywanym przykładem było wykorzystanie luki w usługach GMail. Ofiarą padł grafik David Airey. W GMailu Airey'a atak spowodował dopisanie filtru, który kierował określoną korespondencję do atakującego, co ostatecznie umożliwiło mu przejęcie należącej do niego domeny. Dzięki CSRF atakujący może wysłać do aplikacji webowej dowolne zapytanie w kontekście zalogowanego do niej użytkownika. Atak ten jest szczególnie niebezpieczny, jeżeli uprawnienia, które ma zalogowany do aplikacji użytkownik, dają duże możliwości manipulacji, np. działania na koncie "admin". Najprostszą metodą przeprowadzenia tego ataku jest ukrycie na odwiedzanej przez użytkownika stronie prostego kodu, np.<KOD> <img src="http://adres/?skrypt"> </KOD>. Wystarczy odwiedzić taką stronę lub odczytać HTML-owego e-maila i skrypt zostanie wykonany.

Skoro mowa o zagrożeniach. Warto przy okazji obalić pewien mit, który często jest powtarzany przez specjalistów ds. bezpieczeństwa - o bezpieczeństwie bardzo popularnego ostatnio AJAX-a, zbioru technologii pozwalających budować bardziej przyjazne użytkownikowi i jednocześnie dynamiczne aplikacje webowe. Tak naprawdę można by powiedzieć, że AJAX rodzi znacznie więcej problemów, niż standardowe aplikacje, a to za sprawą znacznej liczby wykorzystywanych skryptów, których obecność jest skrzętnie ukrywana w zapytaniach. A jak wiadomo, maskowanie obecności czegokolwiek to niezbyt skuteczna metoda ochrony. Zainteresowanym polecamy zgłębienie tematu.