Ratunku!

W przypadku aplikacji webowych do ochrony nie wystarczą zwykłe zapory ogniowe czy IPS-y. Nie chcemy przecież blokować ruchu, a jedynie wychwycić z niego to, co niebezpieczne dla naszych aplikacji. Z tej prostej prawdy wiele organizacji niestety nie zdaje sobie sprawy i twierdzi uparcie, że posiadanie tradycyjnych mechanizmów czyni ich zasoby odpornymi na ataki.

Zabezpieczanie aplikacji webowych można podzielić na trzy główne etapy. Mówiliśmy już trochę o pierwszym, czyli procesie tworzenia kodu aplikacji. Drugi, to prowadzenie testów przed wdrożeniem do produkcji, a trzeci - stosowanie narzędzi zabezpieczających aplikację już pracującą.

Oprócz przemyślanej metodologii tworzenia kodu, aplikacja powinna być również poddawana regularnym kontrolom. Nie należy do rzadkości sytuacja, kiedy w zespołach odpowiedzialnych za jej przygotowanie brakuje specjalistów ds. bezpieczeństwa. To prowadzi do tego, że luki są wykrywane post factum. Niestety, często przez atakujących.

Czy możemy zatem sami sprawdzić poziom zabezpieczeń własnych aplikacji webowych? I tak, i nie. Testy poważnych aplikacji powinny być prowadzone przez wyspecjalizowane firmy audytorskie. Mamy wówczas szansę na bardziej obiektywny obraz bezpieczeństwa. Z drugiej jednak strony niewiele firm przeprowadza okresowe audyty bezpieczeństwa. Potwierdzają ten stan rzeczy wyniki przeprowadzonej przez firmę Deloitte analizy (patrz tabela).

Można więc wykazać inicjatywę i samodzielnie przeprowadzać diagnostykę. Możemy do tego celu wykorzystać wiele narzędzi. Istnieje specjalizowane oprogramowanie do analizy różnych aspektów bezpieczeństwa aplikacji. Je również można podzielić na wiele grup, np. narzędzia testujące konfiguracje poszczególnych komponentów, analizujące kod, skanery VA (Vulnerability Assesment) czy typowe oprogramowanie "pentesterskie".

Zacznijmy od budowy kodu. Na tym etapie nieodzowne mogą okazać się narzędzia skanujące kod: linia po linii podczas kompilacji, czyli wykonujące analizę statyczną. Jedne są mocno wyspecjalizowane, np. PMD (pmd.sourceforge.net) - zaliczany do narzędzi statycznych. Sprawdza, czy w kodzie nie ma nieużywanych, ale zadeklarowanych zmiennych, niepełnych wyrażeń, czy kod nie jest zbyt skomplikowany lub powtarza się w wielu miejscach.

Klocwork Insight firmy Klocwork to inne, bardziej uniwersalne narzędzie. Zaletą narzędzi do statycznej analizy kodu jest szybkość działania i szerokie spektrum problemów, które są w stanie wykryć, a także możliwość pracy nawet w bardzo wczesnym stadium tworzenia aplikacji. Działają na podstawie różnorakich algorytmów, wykorzystują również mechanizmy heurystyczne. Niestety ich wadą może być - w zależności od konkretnego produktu - wysoki poziom false positive'ów.

Skoro są narzędzia statyczne, to muszą też istnieć dynamiczne. Te z kolei badają zachowanie aplikacji w boju. Do produktów spod tego znaku możemy zaliczyć np. Valgrind (http://www.valgrind.org ) czy IBM Rational Purify. Narzędzia dynamiczne również mają zalety i wady. Ich skuteczność w dużej mierze zależy od właściwie skonstruowanych scenariuszy testowych.

Są także kombajny, które potrafią zbadać aplikację w zasadzie w każdym momencie jej cyklu życia, np. Fortify 360 firmy Fortify. Z reguły firmy deweloperskie korzystają z narzędzi pochodzących z obu "rodzin".

Na koniec jeszcze parę słów o narzędziach z serii VA oraz "pentesterskich" (od: penetration tester). W tej grupie mamy z czego wybierać. Dobrym przykładem narzędzia VA jest Acunetix Web Vulnerability Scanner (http://www.acunetix.com ), który mimo że jest darmowy, daje ogromne możliwości. Jest też stary i sprawdzony Nikto 2 (http://www.cirt.net/nikto2 ). Użyteczny będzie również Burp Scanner (portswigger.net) lub pochodzący z tej samej serii pakiet Burp Suite. Do skanowania aplikacji AJAX możemy wykorzystać inny pakiet - Scanweb 2.0 (blueinfy.com).

Warto też wspomnieć o jednym ze skuteczniejszych narzędzi "pentestujących" aplikacje webowe, jakim jest Cenzic Hailstorm (http://www.cenzic.com ), który potrafi poddać nasze oprogramowanie najrozmaitszym torturom i "stresom". Dostępne są też inne produkty, które można wykorzystać, np. AppScan firmy Watchfire (obecnie IBM) czy platforma Metasploit (http://www.metasploit.org ).

Niedawno, swoje do tej pory wewnętrzne narzędzie udostępnił na zasadach open source Google. Pasywny skaner Ratproxy (http://code.google.com/p/ratproxy/ ) analizuje zachowanie aplikacji w poszukiwaniu oznak problemów mogących prowadzić do wykonania skutecznych ataków np. XSS. Szczególne wyrazy uznania należą się tutaj współautorowi narzędzia - Michałowi Zalewskiemu (lcamtuf.coredump.cx). Ratproxy ma wiele zalet. Są to m.in. prostota obsługi, wsparcie dla SSL Man-in-the-middle, dekompilacja "w locie" skryptów Flash ActionScript, a także możliwość podpięcia pod inne proxy. Pozwala też na przeprowadzenie kilkunastu testów bezpieczeństwa, np. składni JSON (JavaScript Object Notation), wykrywanie podejrzanych interakcji między domenami, podatność na ataki CSRF (Cross-Site Request Forgery).

Przykładów narzędzi jest znacznie więcej, wystarczy się tylko rozejrzeć. Zanim jednak zdecydujemy się na ich sprawdzenie na żywym organizmie, warto wyposażyć się w jeden z kilku dostępnych "worków" treningowych, np. narzędzi z serii Hackme udostępnianych nieodpłatnie przez Foundstone'a. Jest to zestaw pełnych dziur aplikacji webowych naśladujących np. portal bankowości internetowej, sklep z książkami czy kasyno. Instalacja jest banalna - wystarczy Windows XP, MSDE, .NET v1.1.4322, Java i portal gotowy. Nie zaszkodzą także odwiedziny serwisu badstore.net, gdzie bezpłatnie udostępniany jest obraz ISO gotowej, lecz słabo zabezpieczonej aplikacji webowej.

Wreszcie przeciwnicy instalowania czegokolwiek mogą wejść nahttp://www.testfire.net i pobawić się w ataki zupełnie online. Oprócz ww. narzędzi do webowej zabawy przydadzą się wszelkiej maści proxy przechwytujące ruch, m.in. wiekowy już ParosProxy (http://www.parosproxy.org ). Za jego pomocą jesteśmy w stanie przechwycić chociażby formularz zamówienia i w locie podmienić np. jego wartość, a następnie przesłać do miejsca docelowego. No i na koniec, warto wyposażyć się w odpowiednią lekturę, jak choćby książkę wydawnictwa O'Reilly "Web Security Testing Cookbook".

Często jednak nie jesteśmy w stanie wychwycić lub wykryć wszystkich błędów. Dlatego też stosowanie wyspecjalizowanych narzędzi ochronnych jest równie istotne. Mowa tutaj przede wszystkim o zaporach aplikacyjnych określanych wspólnym mianem WAF (Web Application Firewall). Działanie takiego produktu polega na poddawaniu inspekcji całego ruchu, który zarówno napływa do aplikacji, jak i ją opuszcza. WAF patrzy na kilka aspektów działania aplikacji. Tak jak klasyczny firewall, prowadzi inspekcję protokołów sieciowych HTTP czy HTTPS. Powinien jednak potrafić znacznie więcej, tj. rozumieć i analizować także zawartość np. DHTML, CSS, czy badać XML-e. Musi również umieć obronić samego siebie.

WAF-y występują zarówno w postaci oprogramowania, jak i gotowych appliance. Te pierwsze są tańsze w zakupie, ale drugie łatwiejsze w późniejszym utrzymaniu i z "marszu" poddane procesowi hardeningu. WAF może pracować, wykorzystując jeden z dwóch modeli bezpieczeństwa - pozytywny (wszystkie transakcje są odrzucane do momentu stworzenia reguł zezwalających) oraz negatywny (wszystkie transakcje są dozwolone, a my definiujemy wyjątki) - podobnie jak w przypadku tradycyjnych zapór ogniowych.

Przy wyborze rozwiązania trzeba kierować się wieloma czynnikami, m.in. rodzajem stosowanych mechanizmów ochronnych (sygnatury, heurystyka, wykorzystanie technik normalizacji), częstotliwością aktualizacji sygnatur, umiejętnością i sposobem obsługi ruchu SSL (terminator SSL - konieczność rekonfiguracji sieci, czy też pasywny "rozszywacz" ruchu), liczbą obsługiwanych protokołów, wydajnością i możliwością konfiguracji wysokiej dostępności. Warto też zwrócić uwagę na poziom szczegółowości budowanych reguł oraz możliwość dopisywania własnych sygnatur lub tworzenia rozbudowanych reguł. Nie bez znaczenia jest także wsparcie dla regulacji PCI DSS. No i wreszcie nie wolno zapominać o sposobie zarządzania rozwiązaniem, raportowaniu i logowaniu - tutaj szczególnie pomocna może okazać się obecność modułu forensic, który pozwoli lepiej zrozumieć incydent. Producentów WAF-ów jest wielu. Wśród największych można wymienić firmy, takie jak: Imperva (http://www.imperva.com ), Breach (http://www.breach.com ), Citrix (http://www.citrix.com ), NetContinuum - obecnie Barracuda (http://www.barracudanetworks.com ), F5 (http://www.f5.com ). Są też mniejsze firmy - DenyAll (http://www.denyall.com ) czy BinarySec (http://www.binarysec.com ).