Sesja w obcych rękach
- 16.02.2010
Podatność na ataki przeciw aplikacjom webowym jest przeważnie wynikiem braku doświadczenia, wyobraźni lub wiedzy programisty czy dewelopera.
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 SQL 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.