OWASP AppSensor – obroń swoją aplikację

Projekt AppSensor został oficjalnie dołączony do grupy flagowych (flagship) projektów organizacji OWASP. Celem tego projektu jest integracja aplikacji z metodykami wykrywania i powstrzymywania ataków (attack-aware application).

Projekt ten zakłada, że to aplikacja powinna być „świadoma” zagrożeń i to w aplikacji musi nastąpić wykrycie nieuprawnionych działań i ich powstrzymanie. Taka koncepcja przeniesienia ciężaru odpowiedzialności za bezpieczeństwo do wnętrza aplikacji może znacznie przyczynić się do wzrostu odporności przeciwko atakom sieciowym. Zdecydowanie programiści aplikacji powinni być nie tylko świadomi zagrożeń, ale powinni również implementować mechanizmy ich wykrywania i reakcji.

Aktywna obrona

Twórcy projektu Appsensor  porównują swoją koncepcję aplikacji bankowej do ochrony fizycznej banku. Strażnicy bankowi bardzo szybko zauważyliby osobę, która zachowywałaby się nienaturalnie i  inaczej niż pozostali klienci,np. rozglądałaby się próbując dostać się do stref przeznaczonych dla personelu. Taka ma być również bankowość elektroniczna – to aplikacja, lepiej niż system IDS czy WAF, będzie wiedziała, które działania użytkownika są uprawnione, a które są nienaturalne i powinny wzbudzić podejrzenia. Appsensor ma ułatwić twórcom aplikacji implementację mechanizmów wykrywania ataków już na etapie jej projektowania.

OWASP Appsensor, źródło: owasp.org

Zaletą implementacji tego frameworku w budowanych aplikacjach jest to, że może wykryć i reagować na nieznane jeszcze zagrożenia, ponieważ nie bazuje na sygnaturach a na analizie zachowań. Appsensor to też świetne źródło informacji o tym, co się dzieje w aplikacji, w jaki sposób jest wykorzystywana, a reakcje na działania użytkowników przeprowadzane są na bieżąco. Appsensor, który ma pełną świadomość logiki biznesowej danej aplikacji, nie dopuści do nieuprawnionych działań np. wstrzyknięcia zapytania SQL, ponieważ takie działanie nie będzie mieściło się w 'normalnych’ przepływach aplikacji. Appsensor ma łączyć wiedzą o atakach sieciowych z wiedzą o mechanizmach działania danej aplikacji.

Wdrożenie Appsensor do aplikacji

Podręcznik Appsensor wskazuje na różne podejścia wdrożenia mechanizmów aktywnej obrony w aplikacji. Zaleca się przygotowanie konfiguracji opartej na polityce zdefiniowanej wg:

• lokalizacji wykrycia ataku (detection points),
• poziomu/ progu detekcji (thresholds),
• reakcji (responses).

Przykładowe video pokazuje w jaki sposób działa „attack-aware applications” zgodna z zasadami projektu Appsensor.

Detekcja

Dodanie detection point Appsensor’a do kodu walidacji w aplikacji:

if ( Value in Whitelist ) then
 [existing normal process execution];
else
 [send event to AppSensor];
 [existing exception/error handling];
end if;

Istnieje około 50 takich zdefiniowanych przykładów  nieuprawnionych  zachowań – AppSensor DetectionPoints. Podzielone są na 12 kategorii i mogą dotyczyć takich  działań jak :

• manipulacja parametrami zapytania HTTP,
• przesyłany jest GET zamiast oczekiwanego zapytania POST,
• modyfikacja ciastek sesyjnych,
• kodowanie znaków i inne.

Jednym z przykładów jest działanie z kategorii IE2, czyli sytuacja w której użytkownik przekazał do aplikacji dane nie będące na liście dopuszczalnych wartości (whitelist):

Próg detekcji

Oczywiście nie każde przekazanie danych spoza 'whitelist’y’ powinno być traktowane jako atak – to generowałoby zbyt dużo fałszywych alarmów, w tym celu określa się próg detekcji – threshold. Wykrycie ataku z kategorii IE2 mogłoby być zdefiniowane w następujący sposób:

3 zdarzenia typu IE2 w czasie 5 minut dla tego samego użytkownika

Reakcja

Wykryty atak wywołuje reakcję, aplikacja świadoma ataków sieciowych ma w modelu Appsensor zdefiniowane grupy reakcji – AppSensor ResponseActions, podzielone na 4 główne kategorie:

• Ciche (Silent) np. logowanie, powiadomienie administratora,
• Pasywne (Passive) np. dodatkowe uwierzytelnienie podejrzanego użytkownika, wydłużenie czasu odpowiedzi,
• Aktywne (Active) np. zamknięcie procesu, wylogowanie użytkownika, wyłączenie podatnej części aplikacji,
• Śledcze (Intrusive) np. zebrania informacji o IP, numerze IMEI, charakterystyce przeglądarki użytkownika itp.

Przykładem reakcji może być zmiana funkcjonalności aplikacji ASR-H: Function Amended:

ID	ASR-H
TITLE	Function Amended
CLASSIFICATIONS	Logging, notifying (sometimes), disrupting and blocking | One, some or all users | For a period or permanent
CATEGORY	Active
DESCRIPTION	The usual functionality is amended but not disabled (see ASR-I).
CONSIDERATION
EXAMPLES	Example 1: Limit on feature usage rate imposed Example 2: Reduce number of times/day the user can submit a review Example 3: Additional registration identity validation steps Example 4: Additional anti-automation measures (e.g. out-of-band verification activated, CAPTCHA introduced) Example 5: Static rather than dynamic content returned Example 6: Additional validation requirements for delivery address Example 7: Watermarks added to pages, images and other content Example 8: Additional human interactive proof challenges added due to the number of incorrect guesses of CAPTCHAs outnumbering the correct guesses by more than a certain factor (e.g. Token bucket idea) Example 9: Fuzz responses to mask real functionality or increase attacker efforts to enumerate the application (e.g. random URL generation using ADHD Spider Trap or Weblabyrinth, realistic but invalid cipher text data using techniques such as honey encryption)

Poniższe video prezentuje przykład zaawansowanej konfiguracji AppSensor w aplikacji biznesowej (sklep internetowy).

Przykładowe implementacje

W ramach projektu AppSensor powstały demonstracyjne produkty pokazujące, w jaki sposób można zaimplementować omawiane rozwiązania:

1. AppSensor WS (Web Services) wersja 2

2. AppSensor Core (Java) wersja 1

3. Light Touch Retrofit (PHP)

4. Ensnare (Ruby) – luźno związny z AppSensor ale o zbliżonej filozofii

4. Team Mentor (.NET) – integracja biblioteki AppSensor (Java) z .NET + video Denisa Cruz 

Przykłady projektów demonstracyjnych pokazują również, w jaki sposób połączyć taką aplikację z produktami takimi jak SIEM czy Event Logging.

Przykład szczegółowych danych z AppSensor w Splunk

AppSensor detection points w regułach ModSecurity

Twórcy webowego firewalla aplikacyjnego ModSecurity dodali do repozytorium reguły eksperymentalne, które implementują niektóre detection points określone przez twórców AppSensor. W artykule Trustwave Labs można znaleźć przykłady zastosowań tych reguł, a video pokazuje sposób integracji zasad AppSensor w ModSecurity. Niemniej prawdziwym duchem AppSensor jest jednak przeniesienie zewnętrznych mechanizmów obronnych do środka aplikacji.

Na koniec zachęcamy do obejrzenia prezentacji m.in. o AppSensor, którą przygotował Leszek Miś na konferencję Confitura 14.

Podsumowanie

Projekt AppSensor wychodzi naprzeciw potrzebom deweloperów w zakresie implementacji mechanizmów ochronnych przed atakami sieciowymi. OWASP AppSensor Guide daje programistom wskazówki, w jaki sposób aplikacja ma stać się świadoma ataków oraz jak powinna reagować na niepożądane działania.  Zaletą AppSensor jest skalowalność – wdrażanie tych zasad można rozpocząć na ograniczoną skalę poprzez implementację kilku detection points, a wraz z rozbudową aplikacji poszerzyć mechanizmy obronne o bardziej zaawansowane odpowiedzi na ataki i współpracę z systemami zewnętrznymi takimi np. klasy SIEM.

 

–j23