Webes Alkalmazások Biztonsági Tesztelése

Mivel a számítógépes támadások továbbra is pánikot keltenek, fokozódik a digitális szektor alkalmazásainak és adatainak veszélyeztetettsége. Világhálón muködo vállalkozásoknak fel kell ismerniük, hogy webes alkalmazásaikhoz a biztonsági tesztelés elengedhetetlen. Modern, mindenre kiterjedo biztonsági tesztelési terveket kell létrehozniuk a biztonságos felhasználói élmény megtartása érdekében. Néhány tipp, hogyan fogjunk hozzá.

A különböző szolgáltatások webes alkalmazásai az évek során megszerezték az ügyfelek bizalmát. Adatok terabájtjait töltik fel és osztják meg az egyes platformokon, feltételezve, hogy az ügyleteket biztonságosan felügyelik.
Mivel a számítógépes támadások továbbra is pánikot okoznak, a növekvő digitális térben napról napra csökken alkalmazásaink és adataink biztonsága. 
A netes világban részt vevő vállalkozásoknak fel kell ismerniük a legfontosabb okokat, amelyek miatt a biztonsági tesztelés elengedhetetlen a webes alkalmazásokhoz. Ezeknek a vállalkozásoknak modern, mindenre kiterjedő biztonsági tesztelési terveket kell kidolgozniuk a projektjeik legelején, a biztonságos felhasználói élmény fokozása érdekében.
Pár tipp, hogyan is fogjunk hozzá

Keressünk potenciális biztonsági réseket

Az első lépés átnézni a kódot a lehetséges sebezhetőségek után. A biztonsági hiányosságok az alábbi területeken gyakoriak:

• Rejtett mező manipulációk: leginkább e-kereskedelmi webhelyek sebezhetőek ilyen módon. Az alkalmazások rejtett mezőket ágyaznak be a weboldalakba, és a rossz kódolási színvonalnak köszönhetően ezek a rejtett mezők gyakran bizalmas információkat tartalmazhatnak, például termékárakat.
• Cross-site scripting: ez az egyik leggyakoribb sebezhetőség. Ennek segítségével a hackerek session-öket tudnak ellopni, hogy eltorzítsanak oldalakat, tartalmat ágyazzanak be vagy felhasználókat irányítsanak át rosszindulatú weboldalakra.
• Cross-site request forgery: sok fejlesztő elhanyagolja a véletlenszerű tokenek és az újra hitelesítés fontosságát egy adatkritikus oldalon. Ezek nélkül a támadók kezdeményezni tudnak tevékenységeket a felhasználók nevében, például egy fiók kedvezményezettjének hozzáadását vagy törlését vagy egy felhasználói profil módosítását.

Végezzük el a biztonsági tesztelést lépésről lépésre

Nézzünk meg egy olyan forgatókönyvet, ahol a vállalatnak ASP.NET-ben készült alkalmazásaihoz szüksége van biztonsági tesztelésre. Milyen elvárásokat támaszt ez a tesztcsapattal szemben? Íme, egy megközelítés lépésről-lépésre, amely megoldást nyújthat a követelmények teljesítéséhez.

1. Terv és stratégia megvalósítása

A biztonsági tesztelés első lépéseként egy terv és stratégia kidolgozása szükséges. A tesztelőknek ismerniük kell az üzleti igényt, az alkalmazást igénylő felhasználók számát és az alkalmazás munkafolyamatait, hogy azonosíthassák az egyes forgatókönyvek speciális tesztjeit.

Fontos megbeszélést tartani a fejlesztőkkel még a tervezési fázisban, hogy a tesztelők megértsék az alkalmazás menetét. Ez segíti őket a logikai sebezhetőségek beazonosításában, például az engedélyezési folyamat megkerülését, amelyet az automatizált eszközök nem tudnak beazonosítani.
A vállalkozásnak rendelkeznie kell egy becsléssel, hogy durván hány felhasználó férhet hozzá az alkalmazáshoz. A felhasználók maximális számának ismerete segíti a tesztelőket abban, hogy virtuális felhasználókat generáljanak a lehetséges szolgáltatást bénító támadások azonosítására. Napjainkban ezeket a támadásokat könnyű kihasználni.

2. Fenyegetésmodellezés végrehajtása

Az alkalmazással kapcsolatos magas szintű fenyegetések modellezése lehetővé teszi a tesztelők számára felmérni a lehetséges kockázatokat és a hozzá kapcsolódó forgatókönyveket. A fenyegetésmodellezés azonosítja az alkalmazás gyenge pontjait, ami segít a tesztek testre szabásában.
Miután elkészült egy alkalmazás terve, elindul a technikai folyamat, ahol meghatározásra kerülnek a komponensek a fejlesztéshez. Ezek lehetnek kód nyelvek, platformok, technológiai kötegek stb. Minden komponens saját erősségekkel és gyengeségekkel rendelkezik, ezért a kódolási fázis előtt fontos azonosítani a biztonsági réseket. Ez segít beazonosítani azokat a lehetőségeket, amelyek nagyobb biztonságot adnak és jelentősen csökkentik a javítási költségeket.

Például, ha az alkalmazást a .NET-ben kell kifejleszteni, fontos ismerni az alkalmazást támogató különféle összetevők gyenge pontjait, például a .NET-verziót, az IIS-verziót stb. Ez segít az üzleti és architektúrális fenyegetések azonosításában.

3. Vizsgálati eszközök kiválasztása

Az alkalmazás felméréséhez elengedhetetlen a megfelelő eszközök használata. Minden nyílt forráskódú és szabadalmaztatott eszköznek megvan a saját erőssége és gyengesége, ezért az eszközöket úgy kell megválasztani, hogy tesztelés alatt melyik fogja a legtöbbet nyújtani az alkalmazás részére. A nyílt forráskódú eszközök, például a Zed Attack Proxy és az Nmap lehetővé teszik a tesztelők számára a módosítást egyéni szkriptek használatával.

4. Legyünk kreatívak a tesztelés során

Annak ellenére, hogy egyes biztonsági teszteket automatizált eszközökkel kell végrehajtani, mivel a hackerek egyre okosabbak, fontos, hogy a tesztelő szakemberek a teszteléskor a doboz keretein túl is tudjanak gondolkodni. A logikai sebezhetőségek azonosítása különbözteti meg a tapasztalt tesztelőt egy átlagos tesztelőtől. 
Például, amikor a HTTP-hozzáférés-vezérlésről van szó, a CORS-mechanizmusnak (Cross-Origin Resource Sharing: kérés küldése a háttérben egy másik domainre) állítólag kis információs sebezhetősége van, de ha CSRF-hez (cross-site request forgery: oldalon-keresztüli kéréshamisítás) van kapcsolva, nagy hatást gyakorolna az alkalmazásra. Ez egy nagy európai bankkal történt meg. Egy másik eset a fiók átvétele host header támadásokon keresztül. Egy egyszerű változtatás a host névben a jelszó-visszaállítási link kérése során károsnak bizonyulhat, mivel a link többi része a támadó domain-jét tartalmazná, és így hozzáférhetnek a fiókok jelszavaihoz. Ez akkor fordulhat elő, ha a fejlesztők elfelejtik korlátozni a jelszó-visszaállító hivatkozások újra felhasználását, de egy intelligens tesztelő tudná, hogy mit kell megnéznie.

5. Minden lépésnél gondoljon a biztonságra

Amíg egy manuális webes alkalmazás biztonsági tesztje korlátozhatja a tesztelést egy bizonyos számú nyilvánvaló paraméterig, egy automatizált webes sebezhetőség ellenőrző tudja biztosítani azt, hogy minden paraméter át legyen kutatva hiányosságok után. A szoftverfejlesztés teljes életciklusában beépített biztonsági folyamat eredménye, hogy az alkalmazás biztonságosabb lesz, mivel a hibák nagy része már nagyon korai szakaszban mérséklődik.

A biztonsági tesztelés automatizálható, ha a fejlesztés befejeződik, a Jenkins vagy bármely más automata keretrendszer előállítja a tesztelendő bildet, és az IP és az URL dinamikusan megadható valamilyen nyílt forráskódú eszköznek, mint például a Zed Attack Proxy vagy w3af vagy valamilyen egyéb kereskedelmi eszköznek.

A különböző típusú biztonsági tesztek egyesítése

Általánosságban az előbbi öt lépés jól szolgálatot tesz, viszont ha a biztonsági tesztelés során valami speciálisabbat szeretnénk, több szempontot is figyelembe kell venni.

A Statikus alkalmazás biztonsági tesztelés (SAST) az alkalmazás belső ellenőrzését tartalmazza, ahol a biztonsági auditot végző ember, vagy egy eszköz teszteli az alkalmazást korlátlan hozzáféréssel a forráskódhoz vagy a bináris formátumhoz. Manuálisan és automatikusan is elvégezhető. Olyan bonyolult sebezhetőségek után nyomoznak, amelyek korábban észrevétlenek maradtak.

A Dinamikus alkalmazás biztonsági tesztelés (DAST) külsőleg teszteli az alkalmazást, mialatt az teszt üzemmódban vagy éles környezeten fut. Segít nyomon követni a vállalati biztonsági stratégiának megfelelően az alkalmazás gyorsaságát, rugalmasságát és mérhetőségét.

Az Interaktív alkalmazásbiztonsági tesztelés (IAST) kombinálja az előző kettőt, és ötvözi mindkét megközelítés erősségeit. A biztonsági tesztelés típusai teljes mértékben az üzleti követelményektől és céloktól függenek, de a két módszer alkalmazása mindenképpen hatékonyan csökkenti a számítógépes támadások kockázatát.

Tartsa biztonságban a felhasználóit

Ahogy más fajta tesztelésnél, a web alkalmazásokra szánt biztonsági tesztelésnél is egy komplett terv meghatározásával, és a valószínűsíthető kockázatok és támadások felmérésével kellene kezdeni, azon célból, hogy kirajzolódjanak a leghatékonyabb tesztek.

Miközben a biztonsági tesztelés automatizálása megkönnyíti az erőfeszítéseket, gyorsabbá és sokkal hatékonyabbá teszi a folyamatot, meg kell érteni és előre látni a lehetséges hackerek gondolkodásmódját. A tesztelőknek kreatívnak kell lenniük, hogy a felhasználók termékeik használata során biztonságban érezzék magukat.

Forrás: https://www.stickyminds.com/article/conducting-security-testing-web-applications 
Szerző: Ketan Sirigiri