Aplikacje 'z półki' są zwykle testowane pod kątem bezpieczeństwa, a mimo to, jakość ich zabezpieczeń jest często daleka od oczekiwań. O bezpieczeństwie aplikacji pisanych na indywidualne zamówienie jakoś nie słychać. Czy to znaczy, że są doskonałe? Bynajmniej.

O ile problemy bezpieczeństwa gotowych systemów i aplikacji - tych określanych mianem "z półki" - są dobrze rozpoznane, to o bezpieczeństwie aplikacji tworzonych na zamówienie konkretnego klienta wiadomo, paradoksalnie, niewiele. Tymczasem wielokrotnie okazuje się, że luki tkwiące w takich właśnie aplikacjach prowadzą do nieskuteczności całego systemu bezpieczeństwa. Gartner Group podaje, że 75% współczesnych ataków jest przeprowadzanych na poziomie aplikacji. Szczególną grupę stanowią aplikacje udostępniane publicznie, a więc aplikacje internetowe. Według firmy Sanctum, aż 97% serwisów WWW, objętych jej badaniem, było podatnych na jakąś formę ataku aplikacyjnego.

Istnieje wiele opracowań dotyczących konkretnych problemów w konkretnych produktach i sposobów podnoszenia bezpieczeństwa instalacji. Bezpieczeństwo - zwłaszcza popularnych i szeroko stosowanych systemów - jest stale "badane" przez hakerów z całego świata. Możemy też liczyć na poprawki udostępniane przez producentów, a w przypadku oprogramowania open source - ich twórców.

Z aplikacjami tworzonymi na zamówienie jest inaczej - tu przeważnie zamawiający jest jedynym jej użytkownikiem, nie można więc liczyć na to, że inny użytkownik (lub badacz) odkryje lukę. Z reguły nie można liczyć na to, że producent z własnej woli będzie badał bezpieczeństwo aplikacji własnej produkcji i udostępniał poprawki. Zauważmy, że problem ten dotyczy nie tylko aplikacji zamawianych na zewnątrz. Z identycznym problemem można się spotkać wówczas, gdy aplikacja jest pisana przez wewnętrzny zespół programistyczny.

Najważniejszymi przyczynami istnienia błędów w oprogramowaniu tworzonym na zamówienie są:

• rosnąca złożoność aplikacji;

• brak zrozumienia problemów bezpieczeństwa przez programistów;

• brak uwzględnienia odporności na ataki w całym cyklu rozwojowym oprogramowania.

Skomplikowany świat

Aplikacje obejmują coraz więcej dziedzin i z roku na rok robią to bardziej szczegółowo. W rezultacie same stają się coraz bardziej zawiłe, podobnie zresztą jak środowiska, w których działają. Więcej kodu to zaś więcej błędów mających znaczenie z punktu widzenia bezpieczeństwa. Oczywiście, jak zwykle, powyższą myśl można opatrzyć klauzulą "to zależy".

W przypadku aplikacji działających w modelu terminalowym problem bezpieczeństwa aplikacji sprowadzał się właściwie do kontrolowania danych wprowadzanych przez użytkownika. Implementacja (a więc i bezpieczeństwo) klienta i protokołu komunikacyjnego nie była w nich zależna od programisty. W modelu klient-serwer sprawy znacznie się komplikują - bezpieczeństwo klienta i protokołu komunikacyjnego zależy zasadniczo od twórcy aplikacji i nie jest w sumie ustandaryzowane. Poza tym spora część funkcjonalności aplikacji tego typu jest implementowana po stronie klienta. W konsekwencji bezpieczeństwo aplikacji zależy w dużej mierze od jakości zabezpieczeń stacji roboczej.

Popularne obecnie aplikacje WWW odzwierciedlają powrót do koncepcji terminalowej, w której klient i protokół komunikacyjny są ustandaryzowane. Niestety, ani klient (przeglądarka), ani protokół komunikacyjny (HTTP), ani serwer (serwer WWW) nie były tworzone z myślą o budowie aplikacji , lecz "statycznych" stron WWW . Aplikacje internetowe są wynikiem rozwoju metody CGI, czyli możliwości uruchamiania kodu po stronie serwera, wynikiem działania którego jest HTML interpretowany w przeglądarce. Oddzielny problem polega na tym, że część aplikacji jest implementowana po stronie przeglądarki (JavaScript, VBScript, aplety Java, ActiveX), wprowadzając elementy architektury klient-serwer. Wszystko to nie sprzyja poprawie bezpieczeństwa.

Pozorna wewnętrzność

Wraz z rozwojem aplikacji webowych - od skryptów CGI do modelu trójwarstwowego J2EE - rozwijały się techniki ataku na tego rodzaju aplikacje, wykorzystujące podatności charakterystyczne dla tego modelu. Mamy tutaj m.in.:

• Cross-site scripting - której celem jest wykonanie po stronie przeglądarki wrogiego kodu JavaScript/VBScript.

• Manipulowanie identyfikatorem sesji - cała grupa ataków wykorzystujących fakt, że każde zlecenie HTTP jest traktowane osobno, a połączenie wielu zleceń w sesję aplikacji wymaga stosowania identyfikatora sesji. Poznanie identyfikatora oznacza w praktyce możliwość przejęcia sesji aplikacji.

• SQL injection - manipulacja parametrami wejściowymi aplikacji w ten sposób, aby zmienić treść zapytań SQL aplikacji do bazy danych. Warto przy tym zauważyć, że nie jest to problem charakterystyczny tylko dla aplikacji webowych, nawet jeżeli jest przeważnie omawiany wyłącznie w tym kontekście.

• Na horyzoncie są kolejne technologie, takie jak Web Services. Naturalnie wraz z nimi pojawią się nowe rodzaje podatności oraz nowe techniki ataku.