Webalkalmazások biztonsági tesztelése 1

csirkeA tömegek életének mind több mozzanatának online irányba való elmozdulásával egyre inkább érzékenyek kell lennünk olyan témákra amelyek eddig esetleg többnyire nem igazán mozgatták meg a fejlesztői fantáziánkat. Az eddig ilyen a webalkalmazások biztonsága. A téma egyre fontosabb és fontosabb lesz és láthatjuk, hogy még az olyan nagyok mint a twitter vagy az amazon is belefut időnként egy-egy ilyen jellegű problémába.

Kezdődjön hát a hacker tanfolyam!

Megjegyzés: Ebben a sorozatban a webalkalmazások biztonsági teszteléséről, a biztonsági hibák felderítéséről és javításuk mikéntjéről írok. Célom ezzel az, hogy a fejlesztők számára bemutassam, hogy egy lehetséges támadó hogyan gondolkozik, és mire kell felkészülnünk. Ezzel együtt az itt bemutatott tanácsok legalább annyira használhatók más rendszerekbe való betöréshez mint a saját rendszerünk teszteléséhez. Ez van srácok.

Mi az a biztonsági tesztelés?

A biztonsági tesztelés egy olyan folyamat amelynek során egy adott webalkalmazás, weblap normál működését felhasználva megpróbálunk valami ártalmasat véghezvinni. Az ártalom lehet személyes adatok megszerzése, a weboldal feltörése (azaz tartalmának módosítása), ingyenes vásárlás egy webshopban, spam küldése vagy éppen a rendszer teljes összeomlasztása.

Kinek van rá szüksége?

A válasz egyszerű. Azoknak akik veszthetnek valamit azzal, hogy ha valaki betör a rendszerükbe. Mondhatnánk, hogy azoknak az üzleteknek akik a weben működnek, webáruházaknak, és más webes szolgáltatóknak, de praktikusan mindenkinek aki valamiféle jövedelemhez jut egy adott weblap működtetésével.

Sajnos elterjedt tévhit, hogy egy kis cég nincs veszélyben. Egy támadó szempontjából egy kis weblapocska ugyanolyan célpont lehet mint egy nagy, sőt ha a támadó magát a szervert célozza meg, akkor a kicsik általában sokkal könnyebb falatnak ígérkeznek a nagyoknál.

A másik tévhit, hogy intranetre készülő alkalmazások esetében nem fontos a biztonsági kérdésekkel foglalkozni. Egyrészről a betörések jelentős része valamilyen belső ember közreműködésével történik, másrészről sok intranetes alkalmazás egyszer csak kimászik az internetre, mert a vállalati igények azt megkívánják.

Ki teszteljen?

Lehetőleg valaki más mint aki magát a rendszert leprogramozta. A programozó általában olyan előfeltételezésekkel indul amely meg fogja nehezíteni a saját biztonsági hibáinak feltárását. Velem is előfordult már, hogy egy form esetében mindig enterrel küldtem el az adatokat és kiélesítés után az első felhasználó aki kattintással akarta elküldeni egyből belefutott egy hibába.
Másrészt aki benne volt a program létrehozásában annak olyan információi vannak a rendszer belső működéséről amely segíthet neki egy sikeres támadás végig vitelében, amely ezek nélkül az infók nélkül sikertelen lenne.

Ideális esetben egy biztonsági kérdésekben jártas független szakembert vagy céget érdemes erre a feladatra felkérni.

Mikor teszteljünk?

A biztonsági szempontoknak ott kell lenni a tervezési fázistól kezdve a megvalósításig. Azaz érdemes tesztelni minden jelentősebb fejlesztési ütemben.

Biztonsági tesztelést mind már működő mind még indulóban lévő szolgáltatások esetében lehet végezni. Mivel néha elég könnyen beletenyerelhetünk valami csúnyaságba (mint például “véletlenül” kitöröljük a teljes adatbázist) működő rendszerek esetén érdemes egy a működő rendszer környezetével azonos vagy nagyon hasonló környezetet létrehozni a teszteléshez, amit aztán bátran lehet gyűrni.

Mennyibe kerül a biztonsági tesztelés?

Az árszabás jelentősen eltér tesztelőnként és feladatonként. Amit érdemes itt átgondolnunk, hogy mennyit veszíthetünk egy esetleges betörés alkalmával.

Sok esetben ezt nem egyszerű kikalkulálni. Egy webshop akinek a napi forgalma mondjuk 200e Ft egy 10-12 órás leállással biztosan veszít 150-200e Ft-ot. A felhasználók bizalmának megrendülése már nehezebben mérhető.

A biztonsági tesztelők első feladata valójában egy kockázati lista, vagy kockázati tanulmány összeállítása lenne. Az ebben leírtak alapján dönthetjük el, hogy a tesztelésért fizetendő összeg mennyire elfogadható.

A kockázati tanulmányokért külön kell fizetni, de néhány tesztelő elengedi az árát ha végül ténylegesen megbízzák a teszteléssel.

Mennyire biztos a tesztelés eredménye?

Praktikusan lehetetlen minden lehetséges támadási formát letesztelni és felkészülni azok elhárítására. A tesztelés során az általánosan használt támadási eljárásokat járjuk végig – a tesztelőtől függő alapossággal és szakértelemmel. Így vagy úgy, de a webalkalmazások 70-80%-ánál fog a tesztelő találni valami javítandó funkciót és ezzel már csökkentjük a sikeres támadások kockázatát.

A következő részben a weblapok feltörésének első feladatával, az alkalmazás feltérképezésével fogunk foglalkozni.

4 thoughts on “Webalkalmazások biztonsági tesztelése 1

  1. ‘;alert(String.fromCharCode(88,83,83))//\’;alert(String.fromCharCode(88,83,83))//”;alert(String.fromCharCode(88,83,83))//\”;alert(String.fromCharCode(88,83,83))//–>”>’>alert(String.fromCharCode(88,83,83))

  2. Szia RRD!

    Bocsánat az előbbi bejegyzésért.
    Csak egy szimpla javascript alertet akartam küldeni, de látom le van kezelve.
    Megbántam a tettem, csak májerkodni akartam a többieknek.

    Jó volt cikked így tovább!

    Goranga!

    Üdv,

    Nono, aki most szégyenli magát.

    • @nono Semmi gond. Egy ilyen témáról írva várható, hogy a kedves olvasók be fognak próbálni mindent amit csak lehet 🙂 Remélem annyira legalább értékelni fogják az itt olvasottakat, hogy ha találtok is valami csúnyaságot, akkor megírjátok mielőtt kinyírnátok a teljes blogot 🙂

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.