4. Cross-Site Scripting (XSS)

W pewnych warunkach aplikacja internetowa może zostać wykorzystana jako transport dla ataków na przeglądarkę i środowisko użytkownika. Dzieje się tak wtedy, gdy dane pobierane od użytkownika są potem wyświetlane na stronie WWW będącej wynikiem działania aplikacji. Najprostszym przykładem jest aplikacja typu hello user, która pobiera od użytkownika imię i wyświetla je na wygenerowanej stronie. Jeżeli atakujący umieści w takim parametrze kod typu JavaScript, VBScript, ActiveX, to kod ten wykona się na przeglądarce ofiary. Ataki tego typu najczęściej są używane w celu wykradnięcia identyfikatora sesji, gdyż wrogi kod ma w takiej sytuacji dostęp do cookies związanych z daną aplikacją. Również i ta metoda została opisana w/w artykule (CW 39/2004).

5. Przepełnienie bufora (buffer overflow)

Przepełnienie bufora polega na takiej manipulacji parametrem wejściowym, żeby została przekroczona ilość miejsca zarezerwowana przez aplikację w pamięci na obsługę tego parametru. Rezultatem może być wywołanie awarii procesu, a w sprzyjających warunkach również przejęcie kontroli nad procesem. Metoda ta jest charakterystyczna dla języków programowania, które nie kontrolują pamięci (np. C/C++). Aplikacje internetowe mogą zawierać takie komponenty, np. skrypty CGI, biblioteki zewnętrzne, sterowniki. Podatności tego typu stosunkowo często zdarzają się w serwerach WWW i serwerach aplikacji.

6. Doklejanie kodu (injection)

Aplikacje internetowe budowane są zwykle wielowarstwowo - niektóre parametry pobierane od użytkownika są później używane do budowy komend wykonywanych przy odwołaniach do kolejnej warstwy. Typowym przykładem mogą być tutaj aplikacje wykorzystujące bazy danych, w których dane pobierane od użytkownika są wykorzystywane do konstruowania zapytań SQL. W sprzyjających warunkach atakujący może dokleić do parametru swój kod SQL, który wykona się w bazie danych. Jest to atak typu SQL-injection opisany w artykule "Zastrzyk prosto w serce" (CW 13/2003).

Problemy podobnej natury mogą wystąpić, gdy parametry użytkownika są wykorzystywane do wykonania komendy systemowej albo pobierania danych z pliku. Zabezpieczanie przed tymi groźnymi błędami polega na szczegółowym sprawdzaniu danych wejściowych oraz na wykonywaniu odwołań do niższej warstwy w sposób bezpieczny, uniemożliwiający interpretację doklejonego kodu, np. poprzez procedury składowane lub mechanizmy typu bind variables w bazach danych.

7. Nieprawidłowa obsługa błędów (improper error handling)

Aplikacja powinna świadomie obsługiwać wszelkie błędy, jakie mogą wystąpić podczas jej eksploatacji. Twórcy aplikacji często zakładają (błędnie!), że użytkownik będzie poruszać się po ścieżce wytyczonej przez aplikację. W rezultacie prosta modyfikacja parametru prowadzi do wystąpienia błędu. Jeżeli nie zostanie on obsłużony przez aplikację, obsługa błędu spada zwykle na domyślny mechanizm obsługi błędów środowiska aplikacyjnego bądź systemu operacyjnego.

Może to prowadzić do ujawnienia szczegółów budowy aplikacji. Przykładowo - platforma .Net w konfiguracji developerskiej zwraca w komunikacie błędu fragment kodu aplikacji, który spowodował błąd. Możliwość sztucznego wywołania błędu może (w pewnych warunkach) zostać wykorzystana do spowodowania awarii aplikacji czy serwera, a nawet do obejścia mechanizmów zabezpieczających.

8. Składowanie informacji bez zabezpieczenia (insecure storage)

Większość aplikacji ma potrzebę przechowywania jakiejś informacji szczególnie wrażliwej (np. hasła, numery kart kredytowych itd.). Do ochrony informacji przechowywanych w bazie danych czy w pliku tekstowym wykorzystuje się zwykle mechanizmy szyfrujące. Niestety, bardzo często mechanizmy te są używane "na ślepo" - bez zrozumienia ich zasad działania. Typowe błędy w tej dziedzinie to: niewłaściwy wybór algorytmu do typu danych lub niewłaściwe jego użycie, słabe źródło liczb losowych, a zwłaszcza zastosowanie własnego algorytmu zamiast sprawdzonych standardów.