10:47
4/12/2009

10 najpopularniejszych błędów w webaplikacjach

Parę tygodni temu, OWASP wypuścił wstępną wersję dokumentu zawierającego 10 najpopularniejszych błędów bezpieczeństwa spotykanych w webaplikacjach. Michał Wiczyński przygotował dla czytelników Niebezpiecznika polskie tłumaczenie raportu. Wierzymy, że OWASP TOP10 w języku polskim pomoże stawiającym pierwsze kroki w branży webdeveloperom i pentesterom lepiej zrozumieć zagrożenia obecne w webaplikacjach i sposoby ochrony przed nimi.

1. Injection: “błędy wstrzyknięcia”

Zaliaczamy do nich błędy: SQL, OS shell, LDAP, XPath Injection. Błędy te powstają podczas przesłania specjalnie spreparowanych danych do interpretera, jako części zapytania lub polecenia (prościej mówiąc: wartości traktowane są jak polecenia). Jeżeli dane te nie są w odpowiedni sposób filtrowane, osoba atakująca ma możliwość wywołania własnych poleceń/zapytań. Może to spowodować dostęp do poufnych informacji lub nieautoryzowanych działań w systemie.

Przykładowy atak:

Błąd ten jest nadal bardzo popularny, a jego ofiarą padają potężne firmy. Przykładem może być całkiem niedawny atak na Yahoo.

Warte uwagi

http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
http://www.owasp.org/index.php/Command_Injection
http://www.owasp.org/index.php/ASVS
http://www.owasp.org/index.php/Reviewing_Code_for_OS_Injection
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Validator.html
http://cwe.mitre.org/data/definitions/89.html

2. Cross Site Scripting (XSS): “skrypty międzyserwisowe”

Błędy tego typu powstają podczas próby wyświetlenia w przeglądarce internetowej danych pochodzących od użytkownika, bez ich wcześniejszej walidacji. Umożliwia to atakującemu, wykonanie skryptu na prawach ofiary. Efektem może być przechwycenie sesji zalogowanego użytkownika, podmiana zawartości serwisu lub przekierowanie użytkownika na stronę zawierającą inne szkodliwe skrypty lub oprogramowanie.

Przykładowy atak
XSS polega na wykonaniu kodu HTML, który został wprowadzony przez osobę trzecią, a jest wykonywany przez daną aplikację. Typowy przykład JavaScriptu użytego podczas ataku XSS, powodujący wyświetlenie okienka z zawartością pliku cookie:

<script>alert(document.cookie);</script>

Na podstawie informacji z “ciasteczka” można określić m.in. login, hasło ofiary.
Oczywiście bardziej wyrafinowane metody wykorzystania tego typu błędów umożliwiają np. obserwowanie jakie strony przegląda ofiara lub dołączenie użytkownika do botnetu.

Warte uwagi:
http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
http://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
http://www.owasp.org/index.php/ESAPI
http://www.owasp.org/index.php/ASVS
http://www.owasp.org/index.php/Testing_for_Cross_site_scripting
http://cwe.mitre.org/data/definitions/79.html
http://ha.ckers.org/xss.html

3. Broken Authentication and Session Management: “niepoprawna obsługa uwierzytelniania i sesji”

Bardzo często funkcje związane z uwierzytelnianiem oraz zarządzaniem sesjami nie są odpowiednio zaimplementowane. Umożliwia to osobom atakującym ujawnienie haseł (w zależności od struktury serwisu), kluczy, tokenów sesji lub wykonania poleceń na prawach zalogowanego użytkownika.

Dlaczego pojawiają się tego typu błędy? HTTP jest protokołem typu bezstanowym (stateless), co oznacza, że dane odnośnie zalogowanego użytkownika muszą być wysyłane przy każdym odwołaniu się do strony. Wszelkie dane (przy braku aktywnego SSL) przesyłane są w postaci niezaszyfrowanej, umożliwiając podsłuchanie w dowolnym momencie. Najczęstszym problemem są dane zawarte w tzw. sesjach (SessionID). Odwołując się do innego serwisu niż tego, na którym jesteśmy zalogowani, jest możliwość przesłania tego typu zmiennych (np. poprzez nałówek referrer). W takim przypadku, osoba atakująca odebrawszy dane z nagłówka referrer ustawia w swojej przeglądarce parametry przechwyconej sesji, co w wielu przypadkach umożliwia poprawne zalogowanie się do obcego serwisu.

Przykładowy atak:
Jesteśmy zalogowani w popularnym serwisie randkowym i chcemy pokazać znajomej osobie ciekawe zdjęcie odnalezione w wyszukiwarce tego serwisu. Link wygląda tak:

http://jakisserwisrandkowy/zdjecie-10-10/?sessionid=34923592752

Przekazując w/w link, przekazujemy również dane odnośnie naszej sesji. Istnieje szansa, że klikając w link zostaniemy automatycznie zalogowani jako osoba która wysłała nam link.

Warte uwagi:
http://cwe.mitre.org/data/definitions/287.html
http://www.owasp.org/index.php/Testing_for_authentication
http://www.owasp.org/index.php/Guide_to_Authentication
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/User.html
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Authenticator.html
http://www.owasp.org/index.php/ASVS

4. Insecure Direct Object References: “niezabezpieczone bezpośrednie odwołanie do obiektu”

Pojawia się kiedy zostaje ujawniona referencja do wewnętrznego obiektu. Może być to plik, katalog lub wartość klucza z bazy danych. Bez kontroli dostępu, lub innych kontroli, atakujący może manipulować referencjami w celu uzyskania dostępu do poufnych informacji.
Punkt ten może, a nawet powinien, służyć jako wprowadzenie do punktu 7.

Powody występowania błędu:
– “ukrywanie” wrażliwych informacji w polach formularza typu: hidden
– nadmierne ufanie danym wprowadzanym przez użytkownika
– brak walidacji tego typu danych po stornie serwera.

Przykładowy atak:
Dosyć częsty błąd, umożliwiający przeglądanie danych innych osób, np. faktur lub notatek. Załóżmy, że istnieje aplikacja umożliwiająca dokonywanie płatności za internet przez internet. Po zalogowaniu się można przeglądać listę dokonanych opłat oraz własnych danych osobowych przez link:

http://platnoscizainternet.lan/?abonent=5654

Jeżeli występuje tego typu błąd, to po zamianie wartości 5654 na 1337, najprawdopodobniej będziemy w stanie przejrzeć dane abonenta o id 1337. Możliwości jest wiele, w zależności od struktury serwisu. Co się stanie, jeżeli dane te nie są brane z bazy danych ale z pliku w katalogu /var/www/users/abonenci/5654? Wtedy wystarczy zmienić link na: http://platnoscizainternet.lan/?abonent=../../../../e t c / passwd/ i zamiast danych abonenta zobaczymy zawartość pliku etc / passwd.

Warte uwagi:
http://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/AccessController.html
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessController.html
http://www.owasp.org/index.php/ASVS
http://cwe.mitre.org/data/definitions/639.html
http://cwe.mitre.org/data/definitions/22.html

5. Cross Site Request Forgery: “Fałszowanie żądań”

Atakujący wabiąc ofiarę na swoją stronę, za pomocą umieszczanych na niej instrukcji, może wykonywać zapytania w serwisie do którego jest zalogowana ofiara. Atak ma na celu skłonić użytkownika zalogowanego do serwisu internetowego do uruchomienia odnośnika, który wykona w wybranym serwisie akcję, do której atakujący nie miałby dostępu (np. brak cookie).

Przykładowy atak:
Użytkowniczka Małgosia, na stałe zalogowana do forum internetowego (opcja “zapamiętaj mnie”), może w pewnym momencie otworzyć spreparowany przez Jasia link:

http://forum/changedata.php?login=jasio&new_pass=123&mail=pwn3d@domena

Link ten zmieni jej dane kontaktowe (może również usunąć wątek dyskusji, etc.). Jako link może również posłużyć odwołanie do obrazka lub arkuszu styli, którego adres został odpowiednio przygotowany.

Warte uwagi:
http://www.owasp.org/index.php/CSRF
http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
http://www.owasp.org/index.php/CSRFGuard
http://www.owasp.org/index.php/ESAPI
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/HTTPUtilities.html
http://www.owasp.org/index.php/Testing_for_CSRF_(OWASP-SM-005)
http://www.owasp.org/index.php/CSRFTester
http://cwe.mitre.org/data/definitions/352.html

6. Security Misconfiguration: “zła konfiguracja”

Dana aplikacja, framework, web server, server aplikacji, platforma, powinny posiadać odpowiednie ustawienia mające wpływ na bezpieczeństwo. Wszelkie ustawienia powinny zostać zdefiniowane, zaimplementowane oraz utrzymywane przez cały czas, ponieważ często domyślne ustawienia nie zapewniają żadnego bezpieczeństwa. Do tego typu problemów możemy zaliczyć zostawianie domyślnych haseł oraz konfiguracji, możliwości listowania katalogów, brak podejmowania akcji w przypadku plików typu *.inc, włączone raportowanie informacji odnośnie błędów aplikacji i wiele innych.

Warte uwagi:
http://www.owasp.org/index.php/Configuration
http://www.owasp.org/index.php/Testing_for_configuration_management
http://www.owasp.org/index.php/A10_2004_Insecure_Configuration_Management
http://www.owasp.org/index.php/ASVS
http://www.pcmag.com/article2/0,2817,11525,00.asp
http://cwe.mitre.org/data/definitions/2.html

7. Failure to Restrict URL Access: “Brak zabezpieczeń dostępu przez URL”

Często dostęp do poufnych danych lub narzędzi administracyjnych nie jest limitowany do właściwych użytkowników. Aplikacje powinny wykonywać dodatkowe sprawdzanie czy dana osoba powinna mieć dostęp do żądanych danych, nawet jeżeli zna “ukryty” adres URL.

Przykładowy atak:
Najczęściej popełniany błąd, “ukrywanie” panelu administracyjnego pod URL:

http://serwis/adminsitracja (oczywiście może to być: /admin/, /adm/, /panel/ itp....)

W tym momencie programista stwierdził: “skoro nie ma bezpośredniego odwołania do panelu administracyjnego na stronie głównej serwisu, to nikt nie wpadnie na pomysł żeby wpisać /administracja/… więc po co zabezpieczać taki panel formatką logowania?”. Jak się okazuje, zawód niektórych ludzi polega właśnie na takim “wpadaniu na pomysł” ;)

Warte uwagi:
http://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Access
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessController.html
http://www.owasp.org/index.php/Guide_to_Authorization
http://www.owasp.org/index.php/Testing_for_Path_Traversal
http://www.owasp.org/index.php/Forced_browsing
http://www.owasp.org/index.php/ASVS
http://cwe.mitre.org/data/definitions/285.html

8. Unvalidated Redirects and Forwards: “Brak walidacji przekierowań”

Aplikacje wielokrotnie przekierowują użytkownika na inne strony lub serwisy na podstawie przesłanych danych. Bez odpowiedniej walidacji tych danych, użytkownik może zostać skierowany w zupełnie inne miejsce, np. na stronę phishingową lub ze szkodliwym oprogramowaniem.

Przykładowy atak:
Serwis po poprawnym zalogowaniu użytkownika, wywołuje następujący adres:

http://serwis/redirect.php?strona=main.php

Wartość zmiennej “strona” określa na jaką nazwę strony/ pliku ma zostać przekierowany użytkownik. Wykorzystując błędną obsługę wartości zmiennej, możemy wpisać:

http://serwis/redirect.php?strona=http://evil.com/malware.exe

co w rezultacie przekieruje użytkownika na stronę ze szkodliwym oprogramowaniem.

Warte uwagi:
http://www.owasp.org/index.php/Open_redirect
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/filters/SecurityWrapperResponse.html
http://cwe.mitre.org/data/definitions/601.html
http://cwe.mitre.org/data/definitions/601.html
http://googlewebmastercentral.blogspot.com/2009/01/open-redirect-urls-is-your-site-being.html

9. Insecure Cryptographic Storage: “Błędy szyfrowania danych”

Aplikacje w wielu przypadkach przechowują dane poufne w niezaszyfrowanej postaci. Mogą to być dane typu SSN (Social Security Number), hasła, dane osobowe. Poufne dane należy przechowywać w zaszyfrowanej postaci, jednocześnie zapewniając dostateczny poziom szyfrowania.

Przykładowy atak/błąd:
Załóżmy, że wszystkie dane odnośnie użytkowników danego serwisu trzymane są w bazie w postaci niezaszyfrowanej; loginy, hasła, dane osobowe itp. Wykorzystując np. błąd typu Injection, atakujący wchodzi w posiadanie tych danych i może je niezwłocznie wykorzystać do dalszych ataków. Wystarczyłoby zastosować najprostsze hashowanie danych (np. haseł) z odpowiednim “saltem”, co w ogromnym stopniu ograniczyłoby możliwości natychmiastowego poznania i wykorzystania tych danych.

Warte uwagi:
http://www.owasp.org/index.php/ASVS
http://www.owasp.org/index.php/Top_10_2007-Insecure_Cryptographic_Storage
http://www.owasp.org/index.php/Guide_to_Cryptography
http://www.owasp.org/index.php/Codereview-Cryptography
http://cwe.mitre.org/data/definitions/312.html
http://cwe.mitre.org/data/definitions/326.html

10. Insufficient Transport Layer Protection: “Niedostateczne zabezpieczenia wymiany danych”

Aplikacje często nie posiadają odpowiednio zabezpieczonych kanałów przesyłu danych. Może to być brak stosowania SSL podczas logowania, wygasłe certyfikaty lub zbyt słabe szyfrowanie połączenia.

Przykładowy atak:
Jak już było wspomniane wyżej, brak użycia SSL podczas logowania się na serwis pocztowy lub do banku, umożliwia podsłuchanie przesyłanych danych bez informowania o tym użytkownika (tak, jesteśmy świadomi ostatnich błędów związanych z “*” w certyfikatach).

Warte uwagi:
http://www.owasp.org/index.php/ASVS
http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
http://www.owasp.org/index.php/Top_10_2007-Insecure_Communications
http://www.owasp.org/index.php/Guide_to_Cryptography
http://www.owasp.org/index.php/Testing_for_SSL-TLS
http://cwe.mitre.org/data/definitions/319.html
https://www.ssllabs.com/ssldb/index.html
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

Na sam koniec chciałbym dodać od siebie jeszcze jedno zdanie, niezwykle ważne przy wykrywaniu, oraz zapobieganiu błędom w aplikacjach:

nigdy nie ufaj danym od użytkownika!

Powyższy tekst można pobrać jako plik PDF.
Autorem tłumaczenia jest Michał Wiczyński.


Przeczytaj także:



20 komentarzy

Dodaj komentarz
  1. Błąd 4. występował w systemie faktur dużego koncernu energetycznego (17% rynku) jeszcze 2 lata temu :) Pozwalał na przeglądanie zużycia energii wszystkich klientów w regionie ;p

  2. Wydaję mi się, że w wypadku braku szyfrowania SSL przy logowaniu, dobrym wyjściem zastępczym jest szyfrowanie chociażby parametru z hasłem za pomocą javascript’a w momencie wysłania formularza. Do tego szyfrowania można wykorzystać “salta” np. klucz sesji. Naturalnie każdy może podejrzeć w jaki sposób odbywa się szyfrowanie w kodzie javascript, ale ktoś musiałby już napisać bezpośrednio sniffer’a wycelowanego w daną stronę, aby te dane na bieżąco odszyfrowywać.

  3. Właściwie to większość błędów można załatać stosując funkcje np do stripowania tagów html, sleshy itp. Wystarczy pamiętać by używać tych funkcji w trakcie PISANIA aplikacji. Bo zostawiając to na koniec z łatwością można coś przeoczyć. A np błąd nr 4… wyświetlać informacje na jakiejś stronie profilowej dla użytkownika.

    Tak naprawdę pożądne zabezpieczenie systemu webowego nie jest trudne. Wystarczy o tym myśleć w trakcie pisania i nie być zbyt ufnym.

  4. Dokładnie. Zgadzam się, że to już trzeba robić podczas pisania aplikacji.
    Co do ataków CSRF warto napisać jeszcze, że nie tylko zapytania GET można w ten sposób wykorzystać, ale również POST poprzez umieszczenie odpowiedniego skryptu w javascripcie na stronie, która sama będzie wykonywać zapytania do obcej stronki. Wydaję mi się, że te są najtrudniejsze do zabezpieczenia, bo należy do każdego formularza zaimplementować system token’ów jako dodatkowy ukryty parametr, który jest generowany przez skrypt na stronce i następnie weryfikowany.
    Można również napisać o tzw. click-jacking’u, który również można niecnie wykorzystać np. do dodawania znajomych na NK.

  5. > tak, jesteśmy świadomi ostatnich błędów związanych z “*” w certyfikatach

    Można prosić o więcej info na ten temat? :]

  6. Do jakiej kategorii można zaliczyć ostatni atak na joemonster? Pasuje mi “Forced browsing” nie wymieniony w top10.

    • Darek: 6. Security Misconfiguration: “zła konfiguracja”

  7. […] Amazon z powodu błędu w jednej z hostowanych na EC2 webaplikacji, zapewne wykorzystując jedną z opisanych tu technik. Naprawdę, nie widzę niczego specjalnego w takim ataku. Równie łatwo i równie sprawnie […]

  8. Hehe, tak przeczytałem co jest na tej liście i muszę powiedzieć że przypomniały mi się stare czasy kiedy człowiek się tego uczył (teraz uczy się więcej ^_^). Większość tych błędów jest popełniana przez amatorów.
    Jeżeli podpada duża firma to też nie ma się co dziwić. W nie jednej “poważnej” firmie widziałem “programistę artystę” który “znał idealnie PHP” i który “pisał poważne aplikacje webwe”. Tylko nie wiedział czym jest SQL Injection czy też co może grozić wyświetlenie numeru strony podawanej w pasku adresowym. I tak z adresu:

    http://www.example.com/artykuly/lista.php?strona=5

    robiło się

    http://www.example.com/artykuly/lista.php?strona=Buuuuuuu

    i człowiek wyświetlał wspaniałe pogrubione Buuuu w miejscu gdzie powinna widnieć informacja na jakiej stronie jesteś. Nie muszę mówić jakie możliwości rodzi taka mała głupota. W sumie nie mam co narzekać :-) Nieźle zarobiłem szkoląc tych pracowników.

    • Wesoły: “Tylko nie wiedział czym jest SQL Injection czy też co może grozić wyświetlenie numeru strony podawanej w pasku adresowym. I tak z adresu”

      wyświetlenie numeru strony podawanej w pasku adresowym nie grozi zupełnie niczym. Brak walidacji parametru przekazującego ten numeru grozi m.in. LFI i RFI :>

  9. Lol, źle dobrałem Tag :-) W tych komentarzach jest używany ^_^ miało być

  10. Eh, miało być html’owe pogrubienie :D Znaczy się B w nawiasach trójkątnych :-) Spróbuj tak napisać – <b> :-) Zresztą wiadomo o co chodzi.

  11. Wesoły: “Tylko nie wiedział czym jest SQL Injection czy też co może grozić wyświetlenie numeru strony podawanej w pasku adresowym. I tak z adresu”

    A czym różni się ten parametr, który defacto przekazywany jest GET-em od każdej innej zmiennej? Filtrowanie danych i sprawdzenie typu danej. Numerem strony zawsze będzie cyfra dlatego wystarczy sprawdzenie czy wartość dla strona= jest cyfrą czy też nie. Jeśli nie jest – możesz śmiało wywalić komunikat “Ty świntuchy chciałeś nam coś zepsuć. Admin się Tobą już zajmie”.
    Nie ważne czy GET czy POST – dane muszą być odfiltrowane!
    Kłaniają się wyrażenia regularne.

    • To ja tylko dodam do wypowiedzi maciejkosa, że z SSI (Server Side Includes) niektórzy walczą też w ten sposób, zrzucając sobie z barków wyrażenia regularne:

      include(“FIRMA-” . $GET_PARAM . “.php”)

  12. Nie o to chodzi :-) Klient wyświetla na stronie po prostu $_GET[‘nr’] albo coś takiego. Więc można preparować adres i rozsiewać go po sieci jak wam pasuje szukając naiwniaka. W końcu wstawisz tam wszystko.

    Sprawę ułatwiają np fora internetowe które w wypadku wstawienia linki – robią go klikalnym oraz umożliwiają zapis bbcode w stylu:

    [link=www.dowolny.adres.pl]www.jakis.nieszkodliwy.adres.pl[/link]

    Nieświadomy internauta (czyli większość ludzi surfujących po sieci) kliknie w niego sobie niczego się nie spodziewając. Bardziej świadomy rzuci okiem na dół przeglądarki gdzie jest wyświetlany adres do którego zostajemy przeniesieni. Sam właściciel witryny też ma problem bo pomijając utratę zaufania ludzi, może trafić na listę niebezpiecznych witryn u Google, Mozilli itp. Nie wpływa na popularność wielki czerwony ekran z napisem “TA WITRYNA JEST NIEBEZPIECZNA”. Ale wcześniej może oberwać się użytkownikom.

    W życiu poprawiałem w ten sposób nie jedną witrynę (hehe, nieraz za poprawianie dostaje tyle kasy co za zrobienie podobnej od podstaw) i przestałem się dziwić czemukolwiek.

  13. […] niebezpiecznik.pl Follow us on Twitter 1,516 śledzących RSS Feed 163 czytelników 10 najpopularniejszych błędów w webaplikacjach 1 głosuj! Parę tygodni temu, OWASP wypuścił wstępną wersję dokumentu zawierającego […]

  14. […] widać, błędy należą do podstawowych błędów popełnianych w webaplikacjach, a mimo wszystko wymknęły się doświadczonym programistom i testerom, jacy na pewno pracowali […]

  15. […] porównania rzućcie okiem na listę OWASP-u opisującą błędy w […]

  16. […] przez naszego Czytelnika błąd to tzw. “open redirect“. Znajduje się on na liście 10 najpopularniejszych błędów w webaplikacjach wg OWASP-u oraz 25 najgroźniejszych błędów jakie może popełnić […]

  17. […] to według wielu raportów jedne z najpopularniejszych błędów w aplikacjach, zwłaszcza webowych — jeśli chcesz […]

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: