mi az OWASP Top 10 sebezhetőségi listája?
Az Open Web Application Security Project által először 2004-ben kiadott OWASP Top 10 sebezhetőségi lista (amely a cikk alján található) valószínűleg a legközelebb áll ahhoz, hogy a fejlesztői közösség valaha is parancsolatokat kapjon arról, hogyan kell termékeiket biztonságban tartani.,
Ez a lista az OWASP szerint ma a szoftverbiztonság szempontjából a legfontosabb fenyegetéseket jelenti, sokan homlokára csapva, akik azon gondolkodnak, hogy az SQL injekciók még mindig ilyen aggodalomra adnak okot ennyi év után. A sebezhetőségi típusokat négy kritériumpont alapján ítélik meg:
- könnyű kihasználhatóság
- prevalences
- detectability
- üzleti hatás
érdekes módon az OWASP kijelenti, hogy valójában nem vonják be egyenletükbe annak valószínűségét, hogy a támadók megpróbálnak kihasználni egy bizonyos sebezhetőséget.,
Mikor kezdődött, az írók úgy döntöttek, hogy a legjobb módja annak, hogy fedezze a földön volt, hogy hasonló réseket, hogy ők úgy gondolják, hogy a legtöbb kapcsolatban a csoportok. Felismerték, hogy a megfelelő statisztikák hiányában mindig lehet kérdés, hogy mely sebezhetőségek voltak feltétlenül a legfontosabb aggodalmak, különösen mivel ez szubjektív kérdés lehet az egyes szervezetek fenyegetési modellje szerint.
azonban sok vita után felajánlották a listát arról, hogy mit gondoltak a legszélesebb körű szervezetekről, bár nem különösebben sorrendben.,
idővel az OWASP Top 10 sebezhetőségi listáját számos szervezet elfogadta a legjobb gyakorlatok és követelmények szabványaként, szabványt állítva a fejlesztés szempontjából. A lista egyik jól ismert alkalmazója a PCI-DSS fizetési feldolgozási szabványai.
sajnos, mivel az OWASP Top 10 sebezhetőségek listája szélesebb közönséget ért el, valódi útmutatóként való szándékait félreértelmezték,a fejlesztők megsegítése helyett. Tehát hogyan kell érteni a célja ennek a listának, és valóban ösztönözni a fejlesztőket, hogy kódolni biztonságosabb?,
Megértése Frissítéseket, Hogy A 2017-es Lista
az évek óta, az általuk egyáltalán nem reordered a bejegyzéseket, hozzátéve, egy új típusú biztonsági rés, mint válnak releváns, éppen úgy, mint mások ejtették a listából. Az új verziók 2010-ben, 2013-ban és 2017-ben jelentek meg. Az új listát egy hosszú és fáradságos tanulmány után állították össze, amely több mint 50 000 alkalmazást vizsgált, és mintegy 2, 3 millió sebezhetőséget elemzett.,
a lista rendszeres követői észrevették, hogy a sorrend néhány változásával együtt-annak ellenére, hogy az injekciós támadások továbbra is a tetején maradnak — vannak újoncok az OWASP Top 10 sebezhetőségek családjának 2017-es frissített verziójához.
a verseny kiírása, hogy a mezőnyre való feljutás érdekében a fel nem használt átirányítások és előremozdítások elindításával a nem védett API-k kérdése., Az A10-es listán való szerepeltetése valószínűleg annak a ténynek az eredménye, hogy a fejlesztők egyszerűen sokkal jobban függenek az API-któl, mint régen, sokkal több összetevővel és külső termékkel kölcsönhatásba lépve, mint korábban. Jön a A7 hely nem elegendő támadás, védelem, ami kiüti a fejlesztők, hogy nem elég átfogó hozzá védelem kimutatására, fakitermelés, illetve természetesen reagál a kísérlet, hogy a kárt a termékek.,
A másik jelentős változás, hogy itt a 2017-es verzió a ötvözi A4 bizonytalan közvetlen objektum referenciák, A7 hiányzó funkció szintű hozzáférés-vezérlés, ami egy egységes törött hozzáférés-vezérlés biztonsági rés, kiemelve a szükségességét megfelelően létrehozó ellenőrzések, akik nem tudnak hozzáférni, a számlák adatait.,
félreértelmezve az OWASP Top 10 sebezhetőségi listáját
a force for good, ez a lista sajnos olyan eszközré vált a fejlesztők megszégyenítésére, akik nem követik tanításait, klubként használják őket, hogy ne legyenek tökéletesek a biztonság szempontjából. Ez a megközelítés kontraproduktív, és hiányolja az OWASP azon küldetését, hogy ösztönözze és felkészítse a fejlesztőket a biztonságosabb kódolásra. Sőt, nem ismeri fel a fejlesztők pontszámainak eredményeit, akik soha nem látott sebességgel hatalmas mennyiségű új szoftvert tolnak ki.,
egy közelmúltbeli interjúban az OWASP elnöke, Martin Knobloch csalódottságának adott hangot a listán, amelyet egyfajta ellenőrzőlistaként használnak a kiadás előtti végső átfutáshoz, amely inkább érvényesítési mechanizmusként szolgál, mint útmutatóként.
mint valaki, aki erősen hisz a biztonság balra tolódó megközelítésében, nem meglepő módon egyetértek Knobloch csalódottságával abban, hogy hányan vették az OWASP Top 10 listát a FUD eszközeként, nem pedig az irányadó elvek sorozatát, amelyeknek szánták.,
Kihívást jelentő Ipari Módszerek Biztonsági
a Szervezeti biztonsági stratégiák függ várt hiba az emberi elemeket, hogy azok biztonságos szoftver támogatja a fényes eszközök kudarcra vannak ítélve.
az elmúlt években a túl sok gyártó, különösen a hálózati oldalon történő üzenetküldés az volt, hogy “a kerület halott”, és hogy a vállalatoknak mélységben kell keresniük a biztonságot, hogy megtalálják azokat a rossz fiúkat, akik már a hálózatukon belül vannak., Túl sok a főcím konferenciákon próbáltam meggyőzni CISOs, hogy a csapatok elit hackerek vadászik rájuk elvont 0-nap hasznosítja, hogy hagyja őket védtelenül, hacsak nem veszik a terméket, amely valahogy teszi őket bevehetetlen, hogy ezek az egyébként megállíthatatlan támadások.
Ez a szemlélet az állam a biztonság feleslegesen fatalista, csöpög a marketing hype, vagy hiányzik, az alapvető fogalmakat, hogy a biztonsági szakemberek kéne kockázat.,
a biztonság átfogó megközelítése nem hirdetheti az emberi Fejlesztők eltávolítását a folyamatból, csak azért, hogy az eladó biztonsági eszközeit megjavítsák, miután befejezték munkájukat. Ez azt feltételezi, hogy a fejlesztőkben nem lehet megbízni, sértő, és nem tesz semmit, hogy a csapat erősebb legyen, amikor a biztonságról és a kockázatkezelésről van szó.
mi az OWASP Top 10 sebezhetőségi listája, és nem
évente néhányszor ott van a kötelező blogbejegyzés, amely azt kérdezi, hogy lehetséges, hogy 2017-ben még mindig a script kiddie szintű támadásokról beszélünk., Valószínűleg magam is írtam néhányat, amiért elnézést kérek.
az OWASP Top 10 nem azért van beállítva, hogy megoldja a könyv minden támadását, hanem azért, hogy segítsen a csapatoknak elkerülni azokat a gyakori hibákat, amelyek sokkal valószínűbb, hogy alkalmazásaikat megsértik. Egy eltökélt támadó számos lehetőséget talál arra, hogy megsértse a célpontját. Az intelligens kockázatkezelési tanácsok azonban nem az esetek kisebbségére összpontosítanak, hanem a legszélesebb közönség előtt álló kérdések kezelésére törekszenek.,
felhívni a fogalmak fizikai biztonság területén az átlagos kockázati menedzsernek kell lennie, sokkal jobban aggaszt, hogy az ügyfelét, hogy a baleset az utakon, mint a nindzsák képzett SEAL Team 6 érkezik a windows által irányított AI (illetve a blokklánc).
a valódi biztonság arról szól, hogy megtanítsuk az embereket a biztonságos munkavégzésre, és megadjuk nekik azokat a technológiákat, ismereteket és folyamatokat, amelyek megkönnyítik számukra a biztonságos munkavégzést., Bár mindig fontos a QA és a végleges biztonsági ellenőrzések futtatása a kiadás előtt, a biztonságnak a csapat működésének legkorábbi szakaszaiban kell elindulnia, a termék fejlesztése során. Hibák fognak történni, de sokkal költséghatékonyabb és egyenesen okosabb, ha megpróbáljuk elkerülni a lehető legtöbb kérdést.
sok fejlesztő számára a vezetési cél arra összpontosít, hogy a termék működjön, kevésbé összpontosítva arra, hogy biztonságos-e vagy sem. Ez nem az ő hibájuk.,
az oktatás során megtudták, hogy ha minimális mennyiségű hibát tartalmazó terméket állítanak elő,akkor A.-t kapnak. Ehelyett a vezetőknek meg kell ragadniuk a lehetőséget, hogy megmutassák nekik egy jobb módot a munkára, amely magában foglalja annak megfontolását, hogy miként kódolják őket, valamint azokat az összetevőket, amelyekkel dolgoznak, befolyásolják termékük biztonságát.,
GET 451 RESEARCH ‘ S REPORTTON biztosítása nyílt forráskódú szoftver letöltés ingyenes
gyakorlati lépéseket, hogy jobb biztonsági gyakorlat
egy közös bukás, hogy jött ki a nap vízesés fejlesztés volt várni, amíg a farok végén a fejlesztési ciklus elvégzésére biztonsági ellenőrzések, ahol a fejlesztők kapna egy mosodai listát a biztonsági rések kijavítani, késlelteti a kibocsátás és a növekvő súrlódás közöttük és a biztonsági csapat.,
abban a reményben, hogy a fogaskerekek zsírosodnak, és lépést tartanak a DevOps sebességével, a szervezetek új módszereket keresnek kódjuk kezdettől fogva történő biztosítására, valamint a szervezeti egységek közötti harmónia fenntartására.
Egy egyre népszerűbb módszer hozza be a biztonsági korábbi szakaszában, a termékfejlesztés, a határokon beporzó csapatok keverék a fejlesztők, majd a biztonsági emberek, ezáltal mindkét oldalon adni bemeneti tanulni egymástól., Ez kiváló lehetőség lehet A biztonsági szakértők számára, hogy felvethessék azokat a kérdéseket, amelyeket az OWASP Top 10 megpróbál kezelni egy kevésbé konfrontatív környezetben, olyan szakaszban, amely valóban hatással lehet.
Amikor eszközök, melyek segítségével elősegítik a jobb biztonsági végrehajtása, meg kell gondolni, nem csak arról, hogy milyen technológiával lehet fogni a hibákat, vagy sérti az eset után, de segíteni munka okosabb, több biztonságosan a legkorábbi szakaszai., Ez a perspektíva része a váltás-bal mentalitásnak, keresi a lehetőségeket a kérdések kezelésére, mielőtt drága problémákká válnának.
Integráló Technológiák, Hogy Fokozza Fejlesztő Képességek
Egy világos példa arra, hogy technológiák változó bal segíthet a fejlesztők hasznosítani az OWASP Top 10 a 9-es számú bejegyzést, amely arra figyelmeztet, használata ellen összetevők ismert sebezhetőségek. Az egyik leggyakoribb probléma, amely ebben a térben felmerül, a láthatóság megszerzése a nyílt forráskódú összetevőkben, amelyeket hozzáadtak a termékükhöz.,
a fejlesztők szinte mindig a nyílt forráskódú komponensekhez fordulnak, hogy segítsenek nekik a termék gyorsabb és hatékonyabb felépítésében, erőteljes funkciók hozzáadásával anélkül, hogy maguknak kellene írniuk az új kódot.
a legtöbb esetben nem valószínű, hogy ellenőrizze, hogy az összetevőnek van-e ismert sebezhetősége, mielőtt hozzáadná termékéhez. Még akkor is, ha elvégzik a felületes ellenőrzést, hogy megnézzék, van-e valamilyen konkrét problémája, nem valószínű, hogy tisztában vannak az összetevő függőségeinek bármely problémájával.,
ahhoz Azonban, hogy ezek a Szoftverek Összetétel Elemzés eszköz, valójában kapnak hasznos információkat arról, hogy egy nyílt forráskódú alkatrész bármilyen ismert sebezhetőségek társul hozzá a szoftver teljes egészében fejlesztési életciklus (SDLC), megmentve őket az idő, hogy egyébként töltött könnyezés, az alkatrész cseréje után ellenőrizze a biztonsági csapat később le a pályáról, mielőtt kiadás után követték el, hogy a kód.,
legyen biztonsági engedélyező a szervezeten belül
az OWASP Top 10 és Knobloch észrevételeinek olvasása alapján a listát eszközként kell használni ahhoz, hogy a csapatok biztonsággal rendelkezzenek a termékeik kódolásának, konfigurálásának és szállításának gondolkodási folyamatában.
azok a biztonsági csapatok, amelyek nem vesznek részt a fejlesztőikkel, arra törekedve, hogy megértsék, hogyan tudják felhatalmazni őket arra, hogy a biztonság a munkafolyamat szerves eleme legyen, gyorsan kiszorulnak.,
ha relevánsnak szeretne maradni, legyen engedélyező, és használja az OWASP Top 10 listát a beszélgetések elindításának módjaként, ne fenyegetésként. Végül előfordulhat, hogy több (O)darazsat fog el mézzel, mint ecettel.
A hivatalos OWASP Top 10 sebezhetőségi lista
A1. Injection-Injection hibák, mint például az SQL, NoSQL, OS, LDAP injection, fordulnak elő, ha nem megbízható adatokat küld egy tolmács részeként egy parancs vagy lekérdezés. A támadó ellenséges adatai becsaphatják a tolmácsot, hogy nem kívánt parancsokat hajtson végre, vagy megfelelő engedély nélkül hozzáférjen az adatokhoz.
A2., Törött Hitelesítés – Alkalmazás funkciók kapcsolódó hitelesítés, valamint munkamenet-kezelés gyakran helytelenül végrehajtott, lehetővé téve, hogy a támadók kompromisszum jelszó, kulcs, vagy munkamenet tokenek, vagy kihasználni más végrehajtási hibák feltételezni, hogy más felhasználók személyazonosságát ideiglenesen vagy véglegesen.
A3. Érzékeny adatok kitettsége-számos webes alkalmazás és API nem védi megfelelően az érzékeny adatokat, például a pénzügyi, egészségügyi és PII-t. A támadók ellophatják vagy módosíthatják az ilyen gyengén védett adatokat hitelkártya-csalás, személyazonosság-lopás vagy más bűncselekmények elkövetésére., Az érzékeny adatok további védelem nélkül sérülhetnek, például nyugalmi állapotban vagy tranzitban történő titkosítással, és különleges óvintézkedéseket igényelnek, ha a böngészővel cserélik őket.
A4. XML külső entitások ( XXE) – sok régebbi vagy rosszul konfigurált XML processzor értékeli az XML dokumentumokon belüli külső entitáshivatkozásokat. A külső entitások felhasználhatók belső fájlok közzétételére az URI handler, a belső fájlmegosztások, a belső port szkennelés, a távoli kód végrehajtása, valamint a szolgáltatásmegtagadási támadások segítségével.
A5.,Törött hozzáférés-vezérlők – a hitelesített felhasználók által megengedett korlátozások gyakran nem kerülnek megfelelően végrehajtásra. A támadók kihasználhatják ezeket a hibákat a jogosulatlan funkciók és/vagy adatok elérése, más felhasználók fiókjainak elérése, érzékeny fájlok megtekintése, más felhasználók adatainak módosítása, hozzáférési jogok megváltoztatása stb.
A6. Security Misfiguration-Security misfiguration a leggyakrabban látott probléma., Ez általában nem biztonságos alapértelmezett konfigurációk, hiányos vagy ad hoc konfigurációk, nyílt felhőalapú tárolás, tévesen konfigurált HTTP fejlécek, valamint érzékeny információkat tartalmazó verbose hibaüzenetek eredménye. Nemcsak az összes operációs rendszert, keretrendszert, könyvtárat és alkalmazást kell biztonságosan konfigurálni, hanem azokat időben be kell javítani/frissíteni.
A7.,Cross Site Scripting (XXS)-XSS hibák fordulnak elő, ha egy alkalmazás nem megbízható adatokat tartalmaz egy új weboldalon, megfelelő érvényesítés vagy menekülés nélkül, vagy frissíti a meglévő weboldalt a felhasználó által szolgáltatott adatokkal egy böngésző API segítségével, amely HTML vagy Javascriptet hozhat létre. Az XSS lehetővé teszi a támadók számára, hogy szkripteket hajtsanak végre az áldozat böngészőjében, amelyek eltéríthetik a felhasználói munkameneteket, megrongálhatják a webhelyeket, vagy átirányíthatják a felhasználót rosszindulatú webhelyekre.
A8. Bizonytalan Deserialization-bizonytalan deserialization gyakran vezet távoli kód végrehajtását., Még akkor is, ha a dezerializációs hibák nem eredményezik a távoli kód végrehajtását, felhasználhatók támadások végrehajtására, beleértve a visszajátszási támadásokat, az injekciós támadásokat és a kiváltság-eszkalációs támadásokat.
A9. Az ismert biztonsági résekkel rendelkező komponensek – például könyvtárak, keretrendszerek és más szoftvermodulok-használata az alkalmazással azonos jogosultságokkal történik. Ha egy sérülékeny komponenst kihasználnak, az ilyen támadás megkönnyítheti a súlyos adatvesztést vagy a szerver átvételét., Az ismert sebezhetőséggel rendelkező komponenseket használó alkalmazások és API-k alááshatják az alkalmazások védelmét, és lehetővé tehetik a különböző támadásokat és hatásokat.
A10. Elégtelen naplózás & Monitoring – elégtelen naplózás és monitoring, párosulva a hiányzó vagy hatástalan integráció incidens válasz, lehetővé teszi a támadók számára, hogy további támadás rendszerek, fenntartása perzisztencia, pivot több rendszer, és szabotázs, kivonat, vagy elpusztítani az adatokat., A legtöbb megsértési tanulmány azt mutatja, hogy a jogsértés észlelésének ideje meghaladja a 200 napot, amelyet általában külső felek észlelnek, nem pedig belső folyamatok vagy nyomon követés.