Ataki na firmowe aplikacje webowe stanowią obecnie większość naruszeń bezpieczeństwa w przedsiębiorstwach, przy czym nawet najlepsze zapory i urządzenia IPS nie ochronią błędnie napisanego oprogramowania. Niektóre z podatności, takie jak SQL Injection, udaje się odfiltrować za pomocą nowoczesnych zapór sieciowych, w których można wprowadzić ograniczenia na zawartość poszczególnych pól formularzy, zanim dotrą one do serwera. Urządzenia, które to potrafią zrealizować (na przykład niektóre z zapór F5), nie ochronią aplikacji przed wszystkimi atakami, zatem to aplikacja powinna radzić sobie z niepożądanymi działaniami użytkownika. W odróżnieniu od stosunkowo prostych do zablokowania ataków SQL Injection, niektóre ataki są bardziej skomplikowane.

Pułapka opóźnia włamywacza, alarm przyspiesza interwencję

Aplikacje mają dostęp do wielu informacji nieudostępnianych użytkownikom, dlatego włamywacze próbują wykorzystać którąś z luk, by te dane pozyskać. Ponadto ograniczenia wbudowane w oprogramowanie uniemożliwiają wykonanie niektórych działań (na przykład nieautoryzowanego transferu pieniędzy), zatem po rozpoznaniu podatności cyberprzestępcy spróbują wykorzystać luki do wykonania działań, których nie udaje się przeprowadzić w normalnym trybie pracy aplikacji. Zadaniem kodu obronnego wbudowanego w aplikację jest wykrycie prób i podjęcie działań, przy czym należy myśleć raczej w kategoriach pułapek na włamywacza niż zapór chroniących dostępu. Zadaniem pułapek jest wykrycie i odrzucenie połączeń na tyle wcześnie, aby włamywacz nie zdążył wykryć podatności, lub opóźnienie ataku, by administrator zdążył zareagować na wysłane alerty i podjął inne decyzje.

Złodziej na polu minowym

Ponieważ zabezpieczenia mogą być skuteczne tylko wtedy, gdy są wbudowane w aplikację, założenia punktów poszukujących nieprawidłowości muszą być dołączone praktycznie do każdego wprowadzanego pola i kontrolować każdą akcję użytkownika. Powinny mieć jednak różną wagę - od drobnych ostrzeżeń, aż po raporty krytyczne, które oznaczają nieautoryzowane działania w aplikacji. Wykrywanie ataków powinno być jednak o wiele bardziej zaawansowane, gdyż wprowadzając dodatkowe dane, można wykryć o wiele więcej niż tylko podmianę jednego pola. Praktyka pokazuje, że dołączenie trendów systemowych, historii działania użytkownika, możliwości odpytania zewnętrznych systemów (ERP, firewall aplikacyjny) oraz połączenie z wiedzą na temat ról i uprawnień umożliwi wykrycie wielu ataków, w tym niektórych nieznanych w momencie opracowywania zabezpieczeń.

Arsenał akcji

W tradycyjnym rozumieniu aplikacji biznesowej korzystało się zazwyczaj z dwóch standardowych opcji odpowiedzi na atak - pracy bez zmian, ale z kompletnym logowaniem aktywności oraz przerwanie procesu (na przykład zresetowanie połączenia). Tymczasem twórcy aplikacji webowych mają cały arsenał możliwych akcji, do których należą:

działanie bez zmian;

- wzmożenie logowania, w tym ze szczegółami wewnętrznej pracy aplikacji;

- powiadomienie administratora;

- inne powiadomienie, na przykład przekazanie zgłoszenia do innego systemu;

- użycie proxy, na przykład przez przekierowanie do innego serwisu;

- zmiana statusu użytkownika, m.in. radykalne obniżenie uprawnień po wykryciu niepożądanego działania;

- powiadomienie użytkownika;

- zmiana szybkości pracy aplikacji (wprowadzenie opóźnień)

- przerwanie procesu;

- tymczasowe lub całkowite zablokowanie pewnych funkcji aplikacji

- wylogowanie użytkownika;

- wylogowanie i zablokowanie konta użytkownika;

- wyłączenie aplikacji;

- zażądanie dodatkowych informacji od użytkownika.

Wiele z tych opcji być może jest już zaimplementowane, wystarczy uzupełnić niektóre z nich i wprowadzić system detekcji, który następnie wyzwoli żądane akcje. Najbardziej prawdopodobne akcje to: zmiana poziomu logowania pracy, system powiadomień adminów, wiadomości dla użytkowników, wylogowanie, blokowanie konta i przekierowania. O wiele mniej prawdopodobne jest istnienie opcji związanych z użyciem proxy czy dodawaniem opóźnień, a także wyłączaniem poszczególnych funkcji lub nawet całej aplikacji.

Aby przyspieszyć działanie aplikacji, warto zaimplementować motor sprawdzający, który byłby wyposażony w odpowiednie narzędzia, ale pracujący poza samą aplikacją. Niekiedy można wszystkie zadania sprawdzenia przenieść na osobną maszynę, wprowadzając przy okazji sondy sprawdzające w innych elementach infrastruktury, takich jak bazy danych czy systemy serwerów front end oraz aplikacyjnych. To ważne, gdyż umożliwia wykrycie zjawisk i trendów systemowych, takich jak nagłe wylogowanie wielu użytkowników lub poważny wzrost obciążenia serwisów przy niewielkiej liczbie użytkowników zalogowanych.

Zadaniem procedur chroniących aplikację jest wykonywanie właściwych działań, przy czym jest to związane także z kontekstem pracy. Nie należy wylogowywać użytkownika w przypadku stwierdzenia prostego błędu, ale na niektóre działania system musi reagować natychmiast, aż do wyłączenia aplikacji włącznie. Typowe działanie związane z wykryciem ataku powinno się jednak wiązać z zablokowaniem dostępu, by uniemożliwić dalsze działania włamywaczowi.

Należy przy tym pamiętać, że kont uprzywilejowanych nie powinno się automatycznie blokować, ale raczej wysyłać alerty do administratorów i logować wszystkie akcje podejmowane przez takie konto, najlepiej do trwałego medium, którego nie można zdalnie zmienić.