Sesja w obcych rękach

Podatność na ataki przeciw aplikacjom webowym jest przeważnie wynikiem braku doświadczenia, wyobraźni lub wiedzy programisty czy dewelopera.

Interfejs webowy jest standardem wielu aplikacji biznesowych. Przemawia za nim prostota obsługi, wygoda oraz uniwersalność. Aplikacje webowe mogą być jednak bardzo podatne na różne ataki. Większość z zagrożeń dla aplikacji webowych wynika wprost z luk w bezpieczeństwie spowodowanych złą implementacją standardów, , niedopatrzeniem przy kontroli kodu i innymi podobnymi przyczynami. W teorii, większość błędów powinna być wychwycona przy kontroli kodu, gdyż niektóre z nich można łatwo wykryć. Do usuwania podatności w wielu językach (także w PHP) przewidziano gotowe zestawy instrukcji. Niestety, teoria dość często rozmija się z praktyką.

Atak na aplikacje

Dzisiejsze ataki są w większości kierowane przeciw aplikacjom, rzadziej przeciw samym serwerom lub ich systemom operacyjnym. Najważniejsze z naruszeń bezpieczeństwa, to Injection oraz OS Injection (te dwa ataki stanowią około 80% wszystkich naruszeń bezpieczeństwa aplikacji webowych), LDAP Injection, CLI Injection oraz Cross Site Scripting. Na liście ataków znajduje się także bezpośrednie odwoływanie się do systemu z pominięciem uwierzytelnienia oraz ataki kierowane przeciw serwerom usług i systemom operacyjnym, takie jak przepełnienie bufora. Obecnie jest to raczej niewielki odsetek naruszeń bezpieczeństwa w porównaniu do wszystkich naruszeń aplikacji webowych. Prawdopodobnie dlatego, że SQL Injection przeciw aplikacji można zrealizować stosunkowo prosto, a dzisiejsze serwery i systemy operacyjne są znacznie odporniejsze na ataki niż jeszcze kilka lat temu.

Skutki ataku

Naruszenie bezpieczeństwa aplikacji webowej może skutkować nieautoryzowanym dostępem do informacji. W niektórych przypadkach jest to informacja niejawna, która powinna być dobrze chroniona. Brak zabezpieczeń grozi wyciekiem danych, sankcjami karnymi, problemami przy wymaganych audytach oraz utratą klientów. W polskich realiach to zjawisko także występuje. Wiele instytucji z sektora finansowego doświadcza nieautoryzowanego dostępu do informacji, w tym również tej chronionej tajemnicą bankową, lekarską lub służbową.

Gdzie tkwi błąd?

Najpopularniejsze ataki, czyli SQL Injection, polegają na umieszczeniu komend języka SQL w treści pól przekazywanych jako parametr i umieszczeniu znaków ucieczki w tych polach. Błąd polega najczęściej na nieodpowiednim filtrowaniu danych przesyłanych w postaci zapytań SQL do bazy. Jest to przeważnie błąd wynikający z braku doświadczenia, wyobraźni lub wiedzy programisty czy dewelopera. Na taki atak może być podatna aplikacja napisana w dowolnej technologii (PHP, ASP, JSP, PERL), dynamicznie generująca zapytania do bazy danych. W skrajnym przypadku, w ten sposób można usunąć wszystkie dane z bazy, zmienić je lub pobrać, dokonać zmian w uprawnieniach do aplikacji, a nawet przejąć kontrolę nad podatnym na inne luki systemem operacyjnym.

Kanał błędnej komunikacji

Wykorzystanie błędu SQL Injection w aplikacji webowej może posłużyć do późniejszego przejęcia kontroli nad niedostatecznie zabezpieczonym serwerem bazodanowym. Aby chronić się przed włamaniem tą drogą, należy przeprowadzić operacje hardeningu motoru bazodanowego, na przykład przez wyłączenie obsługi poleceń systemu operacyjnego czy uruchamianie z ograniczonymi uprawnieniami. Hardening powinien objąć także system operacyjny obu serwerów - webowego i bazodanowego. Należy wyłączyć i odinstalować zbędne usługi, usunąć narzędzia deweloperskie, wprowadzić ograniczenia na uruchamianie kodu oraz restrykcyjnie blokować połączenia sieciowe z tej maszyny poza dozwoloną podsieć.

W ubiegłym roku opisywaliśmy na łamach Computerworld dość jaskrawy przykład przejęcia kontroli nad systemem Windows Server zrealizowany jedynie przez wykorzystanie błędu SQL Injection oraz kilku luk w konfiguracji SQL Servera i samego systemu Windows. Atak ten był prezentowany na żywo na październikowej konferencji RSA 2009 w Londynie. Przeprowadzono go przeciw w pełni zaktualizowanej i niemal domyślnej instalacji systemu oraz motoru bazodanowego. Według badaczy prezentujących ten atak, omawiana konfiguracja nadal bywa dość często spotykana w wielu firmach z sektora MSP.


TOP 200