Biztonságos kód felülvizsgálata: gyakorlati megközelítés

ez a cikk a különböző kód felülvizsgálati technikákról és azok alkalmazásáról szól a Való Világban

mit fog tanulni:

mi a biztonságos kód felülvizsgálata és hogyan kell kezelni őket a valós forgatókönyvekben

mit kell tudni:

alapvető biztonsági koncepciók

biztonságos kód felülvizsgálata:

a biztonságos kód felülvizsgálata egy olyan folyamat, amely azonosítja a nem biztonságos kódot, amely potenciális sebezhetőséget okozhat a szoftverfejlesztési folyamat későbbi szakaszában, ami végül nem biztonságos alkalmazáshoz vezet. Ha egy biztonsági rést észlelnek az SDLC korábbi szakaszaiban, annak kisebb hatása van, mint az SDLC későbbi szakaszaiban – amikor a nem biztonságos kód átkerül az éles környezetbe. Az SDLC (Software Development Life Cycle) folyamatban a secure code review folyamat a fejlesztési szakasz alá kerül , ami azt jelenti, hogy amikor az alkalmazást a fejlesztők kódolják, akkor elvégezhetik az önkódot, vagy egy biztonsági elemző elvégezheti a kód felülvizsgálatát, vagy mindkettőt. A fejlesztők automatizált eszközöket használhatnak, amelyek integrálhatók az IDE-vel (Eclipse, MS VS stb.), és egyszerre végezhetnek kódolást és kódellenőrzést. Ezt követően egy biztonsági szakértő segítségét vehetik igénybe a kód további hibáinak azonosításához, mivel a biztonsági szakértők belső nézete van a biztonsági kérdésekről, amelyeket a fejlesztők kihagyhatnak.

különböző tanulmányok és felmérések azt mutatják, hogy a támadások körülbelül 75% – a nem biztonságos alkalmazás miatt történik, amely nem biztonságos kódot tartalmaz. Ily módon az SDLC nagyon fontos részévé válik, amelyet szigorúan kell végrehajtani. A fejlesztők általában az alkalmazás funkcionalitására koncentrálnak, és figyelmen kívül hagyják a biztonságos kódolási megközelítést. De manapság egyre tudatosabbak a kód felülvizsgálatával kapcsolatban a hackelés és a szerver támadások növekvő incidensei miatt.

ábra– 1

technikák a kód felülvizsgálatának biztosításához:

általában, a biztonságos kód felülvizsgálati folyamatát két különböző technikára oszthatjuk:

1. automatizált eszköz alapú / fekete doboz: ebben a megközelítésben a biztonságos kód felülvizsgálata különböző nyílt forráskódú/kereskedelmi eszközökkel történik. Leginkább a fejlesztők használják őket kódolás közben, de egy biztonsági elemző is segítséget nyújthat nekik. Az eszközök nagyon hasznosak a kódellenőrzés során, amikor a biztonságos SDLC folyamatot implementáljuk a szervezetben,és biztosítják az eszközt a fejlesztőknek, hogy kódolás közben” önkódot ” végezzenek. Az eszközök hasznosak a nagy kódbázis (több millió sor) elemzésében is. Gyorsan azonosíthatják a kódbázisban lévő potenciális nem biztonságos kódrészleteket, amelyeket a fejlesztő vagy egy biztonsági elemző elemezhet.
2. kézi / fehér doboz: ebben a technikában alapos kód-felülvizsgálatot végeznek az egész kódon, ami nagyon unalmas és fárasztó folyamat lehet. De ebben a folyamatban logikai hibákat lehet azonosítani, amelyek automatizált eszközökkel, például üzleti logikai problémákkal nem lehetségesek. Az automatizált eszközök többnyire képesek megtalálni a technikai hibákat, például az injekciós támadásokat, de hiányozhatnak olyan hibák, mint az engedélyezési problémák. Ebben a folyamatban, ahelyett, hogy sorról sorra haladnánk az egész kódbázison, koncentrálhatunk a kód lehetséges problémáira. Ezek a potenciális sebezhetőségek kiemelt prioritást élvezhetnek. Például a C / C++ – ban, ha megpróbálunk bármilyen másolási funkciót találni a kódban, és ellenőrizzük, hogy olyan funkciókat használ-e, mint például a strcpy() a másolási funkció végrehajtásához. Mint tudjuk, az strcpy () köztudottan érzékeny a puffer túlcsordulási támadásokra. Azt is szeretnénk ellenőrizni, hogy bármilyen testreszabott titkosítást használnak-e az alkalmazásban, amely automatizált eszközök hiányozhatnak, mivel csak a szabványos algoritmusokat tudják azonosítani.

   tehát a legjobb megközelítés a kettő keveréke lesz, az adatok mennyiségétől és kritikusságától függően. A mai világban, ahol sok összetett alkalmazást fejlesztenek ki, nem hagyhatjuk figyelmen kívül a fent említett technikák egyikét sem.

a Secure code review előnyei:

van néhány tényező, hogy figyelembe kell venni, míg a fejlődő robusztus hozzáférés-ellenőrzési mechanizmus a webes alkalmazás:

1. erőfeszítés előnye: az SDLC folyamat korábbi szakaszában a biztonsági rések kijavítására irányuló erőfeszítés sokkal kisebb, mint a folyamat későbbi szakaszában. Miután a kód elkészült, és a hibát nem azonosították, nagyon fárasztó és időigényes folyamat a problémák megtalálása, miután az alkalmazás készen áll a gyártásra. Ezenkívül az utolsó pillanatban történő rögzítés befolyásolhatja a program teljes funkcionalitását, és akadályozhatja a termék kiadásának határidejét. Ki tudja, ez újabb biztonsági hibát okozhat, ami könnyen lehetséges egy nagy és összetett kóddal.
2. költség-haszon: a költség közvetlenül arányos a szükséges erőfeszítéssel. Nem csak a fejlesztési költségek, hanem a termelési környezetben azonosított sebezhetőség is több költséggel járhat. Ismét megéri, mivel a támadással kapcsolatos költségek sokkal meredekebbek lehetnek.
3. megfelelés: bizonyos megfelelés, például a PCI, szükségessé teszi a biztonságos kód felülvizsgálatát a termék elindítása előtt. Tehát egy teljes SDLC-t követő szervezetnek nagyobb esélye van a tanúsításra.
4. hírnév: a Secure code review eltávolítja a korábbi szakasz legtöbb biztonsági hibáját, biztonságosabbá téve azt, mint pusztán a fekete doboz értékelését. Tehát kevesebb esély van arra, hogy a termék kompromisszumos legyen, így kisebb a jó hírnév károsodásának esélye.

megközelítés:

ezek a standard folyamat és a saját megközelítésem keverékén alapulnak. Ez személyenként eltérő lehet.

szabványos eljárás :

ábra-2

határozza meg a hatókört: először meg kell értenie és ki kell dolgoznia egy durva becslést a kód felülvizsgálatának hatóköréről és az azzal kapcsolatos erőfeszítésekről. Költségvetési megszorítások is meghatározhatók. Milyen típusú kód felülvizsgálat végezhető? Fekete doboz vagy fehér doboz? Próbálja megérteni az alkalmazás üzleti logikáját. Ne feledje, hogy mely sebezhetőségeket kell keresnie, mint például az OWASP Top 10, SANS stb. … megpróbálhatja áttekinteni őket, amennyire csak lehetséges, ha nem mindet. Ezután megállapíthatja, hogy hányan észlelhetők az eszközök segítségével, és amelyek a legmegfelelőbbek a kézi felülvizsgálathoz.

kategorizálja a biztonsági réseket: mi a prioritása, vagyis milyen típusú biztonsági réseket fog prioritásként kezelni? Például az üzleti alkalmazásokban leginkább az alkalmazás üzleti logikájára koncentrálhat, és mélyen belemerülhet, mivel a technikai eszközöket az eszközök könnyen felismerik. Rangsorolja őket.

az alábbiakban néhány kategóriát tekinthet meg:

• Engedélyezés
• hitelesítés
• injekciós hibák
• helytelen hibakezelés / kivétel hibák
• titkosítás (kriptográfia)
• auditálás és naplózás
• munkamenethez kapcsolódó hibák (munkamenet-kezelés)
• nem biztonságos konfiguráció

ajánlás: biztonsági elemzőként kötelességünk kiszűrni az eszközök által generált hamis pozitív eredményeket, és érvényesíteni őket annak megerősítése érdekében, hogy tényleges hibák. A megfelelő kódellenőrzés elvégzése után dokumentálnia kell a biztonsági réseket egy átfogó jelentésben, amely tartalmazza a biztonsági rés kategóriáját és azok enyhítését. Egy lépéssel előrébb járhatsz, és javasolhatsz egy biztonsági kódot. Személy szerint a kódrészleteket is belefoglalom a jelentésbe, lehetőleg egy excel fájlba, majd csatolom.

így én személy szerint megy róla. Az alábbi pontok a kód felülvizsgálata során eddig szerzett tapasztalataimon alapulnak. Még sokat kell tanulnom, és az alábbi pontok minden körülmények között igazak lehetnek, vagy nem:

mindig végezzen kézi felülvizsgálatot: az automatizált kódellenőrzés olyan folyamat, ahol futtatja a szkennelő eszközöket, mint a Rational, az Uncia Labs és a parasofton a kódbázist, majd az eredmények kézi auditálását. A szkenner az észlelés alapján az egész kódot sebezhetőségekkel jelzi. Most az auditor feladata, hogy különbséget tegyen a valós problémák és a hamis pozitív eredmények között. Itt kezdődik az igazi fájdalom. Nincs parancsod minden egyes nyelv felett. Ezért Nyelvspecifikus források igénybevételére van szükség. Most már megismerkedtem szinte az összes főbb nyelvvel (.NET, Java, PHP) specifikus biztonsági rések. Csinál egy fekete doboz értékelése soha nem jön, hogy tudja, hol az igazi probléma rejlik.

először beszéljen a fejlesztőkkel: minél jobban bevonja a fejlesztőket a kódellenőrzési folyamatba, annál hatékonyabb lesz az elemzés. Bizalmat kap abban, hogy bármit is csinál, a kód helyes megértésén alapul. Másrészt a fejlesztők örülnek annak is, hogy bizalomba veszi őket, ahelyett, hogy azonnal valami sebezhetőnek nyilvánítaná.

legyen kéznél egy notebook és toll, hogy megértse a program folyamatát. A valódi sebezhetőségek felderítéséhez meg kell érteni a szennyeződés forrását és azt, hogy hol tükröződik a kódban. Csak látni, hogy a szennyeződés belép a programba, és tükrözi a program más részét, nem mindig jelenti azt, hogy sebezhető például a webhelyek közötti szkriptek számára. Itt is segít a fejlesztőkkel való beszélgetés, mivel lehet, hogy valamilyen központosított bemeneti szűrési/érvényesítési mechanizmust hajtanak végre. Tehát ne csak következtetéseket vonjon le.

használjon előzetes szövegszerkesztőt: a szövegszerkesztőnek képesnek kell lennie egy kifejezés keresésére a teljes kódbázisban. Az egyik ilyen szövegszerkesztő a Notepad++. Megkeresi a kifejezést, és kiemeli őket, hogy láthassa, hol használják az adott kifejezést. Segít a darabok összekapcsolásában és a teljes kép látásában.

elegendő ideje van a kód felülvizsgálatára, mivel többször kell alkalmaznia gondolatait, hogy felvegye a valódi sebezhetőségeket. Ezért mindig kérjen elegendő időt ügyfeleitől a projekt teljes befejezéséhez.

az internethez való csatlakozás mindig segít a kód felülvizsgálatakor. Bizonyos kifejezések, funkciók vagy módszerek mindig bosszantanak, mivel lehet, hogy korábban nem látta őket. A Google sokat segít megérteni őket.

biztonsági rések keresése az alkalmazás összefüggésében: nemcsak az alkalmazás összefüggésében kell valós és alkalmazható biztonsági réseket észlelnie – mivel ez csökkenti a problémák számát–, hanem javasolnia kell az ellenintézkedéseket is a jelentésben. Ez boldoggá és magabiztossá teszi a fejlesztőket. A szkenner bármilyen problémát magasnak, közepesnek vagy alacsonynak jelölhet. Az Ön felelőssége, hogy megfelelő rangsorolást adjon nekik az alkalmazások kontextusa alapján.

mindenki szereti a saját programját: a Programok olyanok, mint egy fejlesztő baba. Ne mindig pontosítsa a Program gyengeségeit, hanem értékelje azokat is, ha bármilyen robusztus mechanizmust talál a programban. Így barátságossá teheti őket, és mindig használni fogják a kód felülvizsgálatát. Tehát mindketten boldogok.

Train them: végül, de nem utolsósorban, a vonat a fejlesztők a biztonsági réseket a valós világban. Adjon nekik képzést, vonja be őket, és ösztönözze őket arra, hogy a gyártás előtt vizsgálják felül kódjaikat. Mondja el nekik, hogyan takarít meg erőfeszítést és pénzt. Ha van egy szkennelő eszköz, amely támogatja a plug-inek IDE, telepítse a gépeiket, hogy meg tudják csinálni a megfelelő fejlesztés és a kézről kézre felülvizsgálat.

Minta illusztráció:

Tekintsük ezt a példát (Owasp WebGoat projekt):

karakterlánc felhasználónév = “”;

karakterlánc jelszó = “”;

felhasználónév = s.getParser ().getRawParameter (felhasználónév);

jelszó = s.getParser ().getRawParameter (jelszó);

……………..

………..……

String query = ” SELECT * FROM user_system_data WHERE user_name = ‘”

+ felhasználónév + “‘és jelszó = ‘” + jelszó + “‘”;

ec.addElement (új StringElement (lekérdezés));

a felhasználó bemeneteit a getRawParameter-en keresztül kérik, és a ‘felhasználónév’ és a ‘jelszó’ változókhoz rendelik. Ismét közvetlenül az SQL lekérdezésben használják őket bemeneti érvényesítés nélkül, valamint beágyazódnak a dinamikus lekérdezésbe. Bármely rosszindulatú felhasználó meghamisíthatja ezt a lekérdezést, hogy saját tetszőleges SQL kódjait futtassa. Tehát, ha megpróbáljuk megtalálni az összes belépési pontot a kódbázisba (ebben az esetben a getRawParameter), észlelhetjük az injekciós hibákat. Még akkor is, ha a kódban használt SQL lekérdezéseket keressük, ha úgy találjuk, hogy dinamikus lekérdezésként használják őket, lehetséges SQL-injekció esete lehet.

a neten: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf