OWASP. The Open Web Application Security Project. OWASP Top 10 2010 rc1. Dziesięć najbardziej krytycznych zagrożeń w web aplikacjach

Podobne dokumenty
Architektura bezpiecznych aplikacji internetowych na platformie Java Enterprise Edition. Jakub Grabowski Warszawa,

OWASP i Top 10 Sposób tworzenia Top 10 Czym jest a czym NIE jest Top 10? Zmiany w wersji 2013 Omówienie nowych podatności na liście Podsumowanie

The OWASP Foundation Session Management. Sławomir Rozbicki.

OWASP OWASP. The OWASP Foundation Cross-Site Scripting. Ryzyko do zaakceptowania? Warszawa, 27 stycznia 2011 Michał Kurek

Narzędzia OWASP dla developerów OWASP ESAPI & AppSensor OWASP The OWASP Foundation

Zagrożenia związane z udostępnianiem aplikacji w sieci Internet

Aspekty bezpieczeństwa aplikacji internetowych

Aplikacje webowe w obliczu ataków internetowych na przykładzie CodeIgniter Framework

Projektowani Systemów Inf.

Bezpieczeństwo systemów komputerowych

Hosting WWW Bezpieczeństwo hostingu WWW. Dr Michał Tanaś (

Kurs rozszerzony języka Python

Ataki na aplikacje WWW. Łomem, czy wytrychem? Jak dobrać się do aplikacji WWW

Bezpieczeństwo aplikacji internetowych

Analiza skuteczności zabezpieczeń przed atakami na aplikacje Web

KONFIGURACJA PRZEGLĄDAREK. Poniższa konfiguracja dedykowana jest dla Bankowości Internetowej SGB

Wykład 3 Inżynieria oprogramowania. Przykład 1 Bezpieczeństwo(2) wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz

Open(Source) Web Application Security Project

Tomasz Greszata - Koszalin

Certyfikat niekwalifikowany zaufany Certum Silver. Instrukcja dla uŝytkowników Windows Vista. wersja 1.1 UNIZETO TECHNOLOGIES SA

Wprowadzenie do kryptografii i bezpieczeństwa. Po raz czwarty

Certyfikat niekwalifikowany zaufany Certum Silver. Instalacja i użytkowanie pod Windows Vista. wersja 1.0 UNIZETO TECHNOLOGIES SA

Języki programowania wysokiego poziomu. PHP cz.3. Formularze

Tworzenie witryn internetowych PHP/Java. (mgr inż. Marek Downar)

Program szkolenia: Bezpieczny kod - podstawy

Jarosław Kuchta Administrowanie Systemami Komputerowymi. Internetowe Usługi Informacyjne

Application Security Verification Standard. Wojciech Dworakowski, SecuRing

Programowanie w Sieci Internet Python - c. d. Kraków, 28 listopada 2014 r. mgr Piotr Rytko Wydział Matematyki i Informatyki

Bezpieczeństwo aplikacji. internetowych. 2. Szkolenie dla administratorów stron internetowych hufców Śląskiej Chorągwi ZHP

Programowanie komponentowe. Przykład 1 Bezpieczeństwo wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz

Logowanie do aplikacji TETA Web. Instrukcja Użytkownika

Instrukcja składania wniosku o dofinansowanie w systemie informatycznym IP na potrzeby konkursu nr 1/1.1.1/2015

Bezpieczeństwo usług oraz informacje o certyfikatach

Zadanie1: Odszukaj w serwisie internetowym Wikipedii informacje na temat protokołu http.

Systemy pojedynczego logowania (Single Sign-On)

Konfiguracja przeglądarek internetowych

INTERNETOWE BAZY DANYCH materiały pomocnicze - wykład VII

Gerard Frankowski, Zespół Bezpieczeństwa PCSS. Nowoczesne technologie bliżej nas Poznań,

Technologie Internetowe Raport z wykonanego projektu Temat: Internetowy sklep elektroniczny

Obsługa poczty elektronicznej w domenie emeritus.ue.poznan.pl

Praktyczne wykorzystanie mechanizmów zabezpieczeń w aplikacjach chmurowych na przykładzie MS Azure

Sesje, ciasteczka, wyjątki. Ciasteczka w PHP. Zastosowanie cookies. Sprawdzanie obecności ciasteczka

Zdalne logowanie do serwerów

Web Application Firewall - potrzeba, rozwiązania, kryteria ewaluacji.

Opis Przedmiotu Zamówienia na przeprowadzenie testów bezpieczeństwa systemu wspomagania nadzoru archiwalnego e-nadzór

LUKI BEZPIECZEŃSTWA W APLIKACJACH INTERNETOWYCH. Waldemar Korłub. Wytwarzanie Aplikacji Internetowych KASK ETI Politechnika Gdańska

Xopero Backup Build your private cloud backup environment. Rozpoczęcie pracy

Bezpieczeństwo aplikacji webowych - standardy, przewodniki i narzędzia OWASP OWASP The OWASP Foundation

Konfiguracja poczty IMO w programach Microsoft Outlook oraz Mozilla Thunderbird

Kontrola sesji w PHP HTTP jest protokołem bezstanowym (ang. stateless) nie utrzymuje stanu między dwoma transakcjami. Kontrola sesji służy do

Standard aplikacji WWW Urzędu Miasta Olsztyna

Wykorzystywanie plików cookies

Problemy z bezpieczeństwem w sieci lokalnej

Jak się zalogować do Pocztowy24 Biznes

Zagrożenia trywialne. Zagrożenia bezpieczeństwa aplikacji internetowych. Parametry ukryte. Modyfikowanie parametrów wywołania

OCHRONA PRZED RANSOMWARE

Warszawa, 25 lipca 2014 r.

Instrukcja logowania do systemu Rejestru Unii dla nowych użytkowników

ZASADY KORZYSTANIA Z PLIKÓW COOKIES ORAZ POLITYKA PRYWATNOŚCI W SERWISIE INTERNETOWYM PawłowskiSPORT.pl

Bazy danych i usługi sieciowe

Repozytorium Cyfrowe BN

Instrukcja składania wniosku o dofinansowanie w systemie informatycznym IP na potrzeby konkursu nr 1/1.1.1/2015


Aplikacje webowe na celowniku. Leszek Miś IT Security Architect RHCA,RHCSS,Sec+ Linux Polska Sp. z o.o. 1

SPRAWOZDANIE SIECI KOMPUTEROWE I BAZY DANYCH LABORATORIUM NR 4 BADANIE PROTOKOŁÓW HTTP KAMIL BOGDANOWSKI

Zarządzanie przez przeglądarkę

Client-side Hacking - wprowadzenie w tematykę ataków na klienta. Radosław Wal radoslaw.wal@clico.pl

bla bla Guard podręcznik użytkownika

OCHRONA PRZED RANSOMWARE. Konfiguracja ustawień

Win Admin Monitor Instrukcja Obsługi

Podstawy technologii WWW

GS2TelCOMM. Rozszerzenie do TelCOMM 2.0. Opracował: Michał Siatkowski Zatwierdził: IMIĘ I NAZWISKO

Instrukcja składania wniosku o dofinansowanie w systemie informatycznym IP na potrzeby konkursu nr 1/4.1.4/2015

Złóż wniosek o becikowe, zasiłek lub inne świadczenie przez Internet

Polityka Prywatności Vemma Europe

Konfiguracja programu pocztowego Outlook Express i toŝsamości.

Instrukcja składania wniosku o dofinansowanie w systemie informatycznym IP na potrzeby konkursu nr 1/4.1.4/2016

Cookie Policy. 1. Informacje ogólne.

Pomoc dla usługi GMSTHostService. GMSTHostService. Pomoc do programu 1/14

Panel administracyjny serwera: admin.itl.pl

Polityka Prywatności

Drobne błędy w portalach WWW

Konfiguracja klienta Lotus Notes R6 z certyfikatami i kluczami na karcie kryptograficznej lub w pliku.

Sieciowa instalacja Sekafi 3 SQL

Instrukcja użytkownika aplikacji FairPay Connect

Dokumentacja smsapi wersja 1.4

POLITYKA PRYWATNOŚCI ORAZ POLITYKA PLIKÓW COOKIES W Sowa finanse

Instrukcja generowania certyfikatu PFRON i podpisywania dokumentów aplikacji SODiR w technologii JS/PKCS 12

Opis aktualizacji programu Kancelaria Komornika

Backend Administratora

Instrukcja dla użytkowników Windows Vista Certyfikat Certum Basic ID

Aplikacje WWW - laboratorium

Certyfikat Certum Basic ID. Instrukcja dla użytkowników Windows Vista. wersja 1.3 UNIZETO TECHNOLOGIES SA

e-wsparcie Barbara Muszko Aktualizacja Twojej witryny internetowej tak prosta, jak obsługa Worda

Konfiguracja telefonu Yealink T20P

Instrukcja logowania do systemu Rejestru Unii


Zarządzanie sesją w aplikacjach Internetowych. Kraków, Paweł Goleń

Internetowy serwis Era mail Aplikacja sieci Web

Transkrypt:

OWASP The Open Web Application Security Project OWASP Top 10 2010 rc1 Dziesięć najbardziej krytycznych zagrożeń w web aplikacjach Release Candidate 1 (tłum.+ zmiany: Michał Wiczyński, http://thinklikeninja.blogspot.com) 1

1. Zmiany w najnowszym dokumencie: Dodano Usunięto Zmiana A6 Security Misconfiguration A8 Unvalidated Redirects and Forwards A3 Malicious File Execution A6 Information Leakage and Improper Error Handling (2004) A10 Insecure Configuration Management 2. T10. Poszczególne punkty: 2.1 A1- 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ęść 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 wówczas możliwość wywołania własnych poleceń/ zapytań. Może to spowodować dostęp do poufnych informacji, lub nieautoryzowanych działań w systemie. 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 (http://news.softpedia.com/news/yahoo- Local- Hacked- 120044.shtml). 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/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

2.2 A2- 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. XSS polega na wykonaniu kodu HTML, który został wprowadzony przez osobę trzecia a jest wykonywany przez dana aplikacje. Typowy przykład JavaScript użytego podczas ataku typu 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 tworzą z komputera ofiary komputer zombie. 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/testing_for_cross_site_scripting http://cwe.mitre.org/data/definitions/79.html http://ha.ckers.org/xss.html 3

2.3 A3- Broken Authentication and Session Management: niepoprawna obsługa uwierzytelniania i sesji, Bardzo często funkcje związane z autentykacją, 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 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) pojawiają się w postaci niezaszyfrowanej, umożliwiając podsłuchanie tych danych 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. via referrer). W takim przypadku, osoba atakująca ustawia w swojej przeglądarce sesję odwiedzającego, co w wielu przypadkach umożliwia poprawne zalogowanie się do obcego serwisu. 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. Klikając w link, jest możliwość, że zostaniemy automatycznie zalogowani jako osoba która wysłała nam link. 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 4

2.4 A4- 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 typu: hidden - nadmierne ufanie danym wprowadzanym przez użytkownika - brak walidacji tego typu danych po stornie serwera. Omówię 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=../../../../../../../etc/passwd i zamiast danych abonenta widzimy zawartość pliku /etc/passwd. 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 5

http://owasp- esapi- java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/accesscontroller.html http://cwe.mitre.org/data/definitions/639.html http://cwe.mitre.org/data/definitions/22.html 6

2.5 A5- Cross Site Request Forgery: Fałszowanie żądań, nieautoryzowany użytkownik wabiąc ofiarę na swoją stronę, może wykonywać zapytania jako 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). Użytkowniczka Małgosia, na stałe zalogowana do forum internetowego, 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 albo usunie wątek dyskusji. Jako link może również posłużyć obrazek, którego adres został odpowiednio przygotowany, a konsekwencje wykonanej akcji mogą być znacznie poważniejsze. 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 7

2.6 A6- Security Misconfiguration: niepoprawne ustawienia, 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 w/ w części 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 informacje odnośnie błędów aplikacji i wiele innych. 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.pcmag.com/article2/0,2817,11525,00.asp http://cwe.mitre.org/data/definitions/2.html 8

2.7 A7- Failure to Restrict URL Access: Brak zabezpieczeń dostępu przez URL, wielokrotnie dostęp do poufnych danych, lub narzędzi administracyjnych. Aplikacje powinny wykonywać dodatkowe sprawdzanie czy dana osoba ma dostęp do tego typu danych, nawet jeżeli zna ukryte URL. 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 zakładać logowanie na taki panel. Jak się okazuje, zawód niektórych ludzi polega właśnie na takim wpadaniu na pomysł ;) 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://cwe.mitre.org/data/definitions/285.html 9

2.8 A8- 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. 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. http://www.owasp.org/index.php/open_redirect http://owasp- esapi- java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/filters/securitywrapperrespon se.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 10

2.9 A9- 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), dane do autentykacji, 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, osoba atakująca jest w posiadaniu tych wszystkich danych w niezakodowanej postaci, dzięki czemu może je niezwłocznie wykorzystać do dalszych ataków. Wystarczyłoby zastosować najprostsze szyfrowanie/ hashowanie danych (np. haseł) z odpowiednim salt em, co ograniczyłoby w pewnym stopniu możliwości wykorzystania tych danych. 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 11

2.10 A10- 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. 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, jestem świadom ostatnich błędów związanych z * w certyfikatach;) ). 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 12

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 13