Dorobek projektu OWASP - Open Web Application Security Project, tworzy ramy dla standardu de facto w dziedzinie bezpieczeństwa aplikacji internetowych.

Bezpieczeństwo aplikacji, a zwłaszcza aplikacji internetowych, to obecnie jeden z najważniejszych problemów bezpieczeństwa informacji. W przeciwieństwie do bezpieczeństwa sieci czy systemów operacyjnych czy aplikacji w ogóle (np. WebTrust) techniczne aspekty bezpieczeństwa aplikacji WWW nie doczekały się powszechnie akceptowanych zasad dobrej praktyki. Ten zły stan rzeczy stara się zmienić zainicjowany przez ochotników projekt OWASP - Open Web Application Security Project. "Open" w nazwie projektu oznacza, że całość dokumentacji i narzędzi jest tworzona na zasadach open source, czyli każdy może się przyłączyć do projektu, rezultaty prac zespołu są dostępne nieodpłatnie, a stworzone w jego ramach narzędzia są dostępne wraz z kodem źródłowym.

W projekt OWASP (http://www.owasp.org ) zaangażowani są specjaliści czołowych firm zajmujących się bezpieczeństwem aplikacji, a także przedstawiciele użytkowników aplikacji z sektora finansowego, przemysłowego, farmaceutycznego, a także firm świadczących usługi. Rezultaty prac zespołu OWASP są oficjalnie rekomendowane m.in. przez niektóre amerykańskie agencje rządowe oraz firmy finansowe (m.in. Visa). Zbiór zasad OWASP Guide staje się powoli standardem de facto.

Oprócz porad, zaleceń i narzędzi OWASP publikuje OWASP Top 10 - wzorowany na SANS Top 20 spis najważniejszych zagrożeń dla aplikacji internetowych. Listę tę przedstawiamy poniżej wraz z omówieniem poszczególnych pozycji. Nie ulega wątpliwości, że powinien się z nią zapoznać każdy programista i projektant aplikacji WWW .

OWASP Top10

1. Brak kontroli na wejściu (unvalidated input)

Każda porcja danych pobierana z zewnątrz, od użytkownika aplikacji czy z jego środowiska, powinna być zawsze szczegółowo sprawdzana. Brak dokładnego sprawdzania danych wejściowych może prowadzić do groźnych ataków na aplikacje. Szczegółowe sprawdzanie danych wejściowych może zapobiec atakom metodami Cross-Site Scripting, Buffer Overflow i SQL-injection (nr 4, 5, 6 na liście OWASP Top 10), dlatego też jest to bardzo ważna "linia obrony" każdej aplikacji webowej.

Warto zwrócić uwagę, że atakujący może modyfikować dowolny fragment żądania HTTP, a więc sprawdzane powinny być wszystkie dane pochodzące ze środowiska zewnętrznego: zarówno te wprowadzane przez użytkownika w polach formularzy, te wprowadzane pośrednio, jak również dane pochodzące ze środowiska przeglądarki, np. te wysyłane przez przeglądarkę w nagłówku HTTP.

Właściwa strategia sprawdzania danych wejściowych powinna polegać na sprawdzaniu "pozytywnym", tzn. przepuszczaniu tylko takich danych, które są dozwolone, a nie na blokowaniu tych znaków, które są zabronione. Na przykład jeśli wiadomo, że pole ID zawiera liczby od 1 do 99, to funkcja sprawdzająca powinna sprawdzać, czy pole to zawiera jedną lub dwie cyfry.

2. Nieprawidłowa kontrola dostępu (broken access control)

Pod tym punktem kryją się wszystkie podatności związane ze sprawdzaniem praw dostępu do treści oraz do funkcji aplikacji. Prawidłowy mechanizm kontroli dostępu powinien się opierać na zasadzie najmniejszych przywilejów. Najczęściej spotykanym błędem jest możliwość dostania się do określonej informacji (lub możliwość wywołania funkcji aplikacji) przez bezpośrednie wywołanie URL. Prawidłowo zaimplementowana kontrola dostępu powinna być ściśle zdefiniowana w projekcie (np. za pomocą macierzy uprawnień) i powinna być wymuszana przy każdym odwołaniu do zasobów/funkcji.

3. Nieprawidłowe uwierzytelnianie i zarządzanie sesją (broken authentication and session management)

Ta grupa podatności wiąże się z nieprawidłową implementacją mechanizmów uwierzytelniania i mechanizmów towarzyszących, np. procedury zmiany hasła, procedury wysyłania hasła w przypadku jego zapomnienia, zapamiętywanie hasła w cookie itd. Jest też kwestia sposobu implementacji i zarządzania sesją użytkownika. Sesja jest implementowana przez nadanie identyfikatora sesji i przedstawianie go przy każdym odwołaniu się do aplikacji. Nieprawidłowe nadawanie identyfikatora (np. identyfikator łatwy do odgadnięcia) lub złe zarządzanie sesją może prowadzić do przejęcia sesji, a więc do przejęcia uprawnień użytkownika i całkowitego obejścia wszystkich mechanizmów uwierzytelnienia. Więcej o zarządzaniu sesją czytelnik znajdzie w artykule "Problem na zamówienie" (CW 39/2004).