6 Web háttérkép biztonsági kockázatok, amelyeket figyelembe kell venni a fejlesztés során

Tegyen lépéseket a fejlesztés során a web háttérképének megerősítéséhez és biztonságához.


A kisvállalkozások, a bankok és sok iparág függ a webalkalmazásoktól. A webalkalmazás felépítésétől kezdve elengedhetetlen, hogy rendelkezzen protokollokkal a sebezhetőség ellenőrzésére, mivel a fejlesztés során a biztonsági sérülések, az adatok szivárgása és a pénzügyi problémák elkerülhetők..

A legveszélyesebb webes támadások azok, amelyek a szerver oldalán fordulnak elő, ahol az adatokat tárolják és elemezik.

Mi a háttér??

A webalkalmazás két részre oszlik – Frontend és Backend.

  • Az előlap kliens oldalú, ez az a része, amellyel a felhasználó kapcsolatba lép. Általában HTML, CSS és Javascript használatával készül.
  • A háttér szerver oldali. Alapvetően az, hogy az alkalmazás hogyan működik, alkalmazza az üzleti logikát, a változásokat és a frissítéseket. Néhány népszerű szerveroldali tech halom a PHP, NodeJS, Java, Ruby, C, Python, adatbázis, biztonság (hitelesítés, hozzáférés-vezérlés stb.), Szerkezet- és tartalomkezelés részét képezi..

Egy kis emlékeztető, mielőtt elkezdenénk – hitelesítés, hozzáférés-ellenőrzés & munkamenet menedzsment

Gyakori, hogy összekeverjük a fogalmakat. Tehát tisztázjuk gyorsan:

  • A hitelesítés a felhasználói identitás igazolására vonatkozik (pl. Jelszó, felhasználónév, biztonsági kérdések, ujjlenyomatok)
  • A hozzáférés-szabályozás attól függ, hogy a felhasználó miként férhet hozzá az alkalmazáshoz. Végrehozza azt az irányelvet, amely szerint a felhasználók nem léphetnek fel a tervezett engedélyeken kívül.
  • A szekciókezelés ugyanahhoz a felhasználóhoz kapcsolódó válaszokat és kérési tranzakciókat érinti. Ez egy cseremechanizmus, amelyet a felhasználó és az alkalmazás között használnak sikeres hitelesítés után.

A jobb web-háttérbiztonság érdekében vizsgáljuk meg a következőket.

Befecskendezési hibák

2010 óta az OSWAP az injektálást az egyik legveszélyesebb webes alkalmazás kockázatának minősítette.

Az injekciós hibák lehetővé teszik a felhasználó számára kulcsszavakat tartalmazó adatok szolgáltatását, amelyek módosítják az adatbázisra épített lekérdezések viselkedését. Tegyük fel például, hogy van egy SQL szkript, amely ellenőrzi, hogy létezik-e egyező bejegyzés az adatbázisban.

uname = request.POST [‘felhasználónév’]
passwd = request.POST [‘jelszó’]
sql = "Válasszon azonosítót a felhasználótól, ahol felhasználónév = ‘" + uname + "’ÉS jelszó =’" + passwd + "’"
database.execute (SQL)

A támadó most SQL injekcióval manipulálhatja a jelszómezőt, például az ‘OR 1 =’ 1 jelszó megadásával, ami a következő SQL lekérdezéshez vezet:

sql = "Válasszon azonosítót a felhasználótól, ahol felhasználónév = ” ÉS jelszó = ‘jelszó’ VAGY 1 = ‘1’

Ezzel a támadó hozzáférhet az adatbázis összes felhasználói táblájához, a jelszó mindig érvényes (1 = ‘1’). Ha rendszergazdaként jelentkeznek be, bármilyen módosítást elvégezhetnek.

Hogyan lehet megakadályozni??

Nagyon KÖNNYEN az injekciós hibák elkerülése érdekében.

A befecskendezés hiányának ellenőrzésének legjobb és egyszerű módja egy alapos kézi forráskód-áttekintés annak ellenőrzésére, hogy az adatbázisban a lekérdezések készített utasításokkal történnek-e. Használhat eszközöket a sebezhetőség ellenőrzésére is.

És a következőket is meg kell tennie.

  • Használjon ORM-eket (objektum-relációs leképező eszközök).
  • Kerülje el az összes bemenetet. A dátummezőben a dátum kivételével soha semmilyen más nem tárolható bennük.
  • Izolálja az adatait úgy, hogy csak azokat a dolgokat tartsák ott, amelyekhez egy adott helyről lehet hozzáférni.
  • Írjon jó kezelési hibakódokat. Ne tegye az adatbázisát vagy a háttér-rendszert túl pontosnak.

Troy vadászat ragyogó tanfolyamot kapott az SQL-injektálásról. Ha érdekli, akkor felfedezheti ezt.

Törött hitelesítés

Mint korábban említettük, a hitelesítés a hitelesítő adatok megadásával foglalkozik. Ez a korlátlan hozzáférés elleni védelem élvonalában. A biztonsági politika rossz végrehajtása és nem tiszteletben tartása azonban meghibásodott hitelesítéshez vezethet.

A megszakadt hitelesítés többnyire három mintával történik:

  • Hitelesítő adatok töltelékei: ahol a támadó rendelkezik érvényes felhasználónevek és jelszavak listájával, és képes automatizálni a támadást a hitelesítő adatok kiszámításához.
  • Bruteforce támadás: ahol az alkalmazás gyenge jelszavakat enged a felhasználóknak vagy a rendszergazdáknak.
  • Munkamenet eltérítése: ahol az alkalmazás lefedi a munkamenet azonosítóját, URL-jét, vagy nem forog be a bejelentkezés után.

A támadó minden esetben hozzáférhet egy fontos számlához, és attól függ, hogy mely üzleti vállalkozás pénzmosást, személyazonosság-lopást okozhat, vagy jogilag védett, nagyon érzékeny információkat tehet közzé..

Hogyan lehet megakadályozni??

A hitelesítési rendszer bevezetése előtt kérdezze meg magától – mit érhet el egy támadó, ha a hitelesítési rendszer veszélybe kerül?

És a válasz szerint az alábbiakat teheti meg.

  • Végezzen több tényezőjű hitelesítést az automatikus támadások megelőzése érdekében.
  • Ösztönözze (vagy kényszerítse) a felhasználót, hogy fogadjon el egy jó jelszószabályt.
  • Korlátozza a sikertelen bejelentkezéseket.
  • Használjon hatékony algoritmus-kivonatot. Algoritmus kiválasztásakor vegye figyelembe a jelszó maximális hosszát.
  • Tesztelje a munkamenet időtúllépési rendszerét, és ellenőrizze, hogy a munkamenet-token érvénytelenné vált-e a kijelentkezés után.

Törött hozzáférés-vezérlés

A hozzáférés-vezérlés biztosítja annak biztosítását, hogy mit tehessenek a hitelesített felhasználók. A hitelesítés és a munkamenedzsment az alap vagy hozzáférés-vezérlő szabályok. De ha ezeket a szabályokat nem állítják be megfelelően, ez jelentős kérdéseket vethet fel.

A közös hozzáférés-szabályozási hibák a következők:

  • A CORS téves konfigurációja lehetővé teszi az illetéktelen API-hozzáférést.
  • Metaadatok kezelése a módszerekhez való közvetlen hozzáférés érdekében.
  • Kényszerített böngészés: A támadó megkísérel egy URL-t, módosítja az elérési útvonalakat (pl. Http: //website.domain/user/ – http: //website.domain/admin), és akár fontos fájlokat is felfedezhet..

Hogyan lehet megakadályozni??

A hozzáférési hibákat leginkább a hatékony hozzáférés-kezelés alapvető követelményeinek tudatlansága okozza.

  • Alapértelmezés szerint tagadja meg, kivéve az állami forrásokat.
  • Tilos letiltani a kiszolgáló könyvtárak felsorolását, és ellenőrizze, hogy nincs-e biztonsági mentési fájlok.
  • Értékeld az API-hozzáférés korlátozását az automatikus támadások hatásának csökkentése érdekében.
  • Érvénytelen a JWT jogkivonatok a hátoldalon történő kijelentkezés után.

Adat expozíció

Az adatsértésnek – adatmegsértésnek is nevezik – az adatkitettség olyan számítógépes fenyegetés, amely fenyegeti a vállalkozásokat és ügyfeleiket.

Akkor fordul elő, amikor az alkalmazás nem védi megfelelően az olyan információkat, mint például hitelesítő adatok vagy érzékeny adatok, például hitelkártyák vagy egészségügyi nyilvántartások. Több mint 4000 lemez minden percben megsértették.

Az üzleti életre gyakorolt ​​hatás pénzügyi szempontból nagy: az átlagos jogsértés 3,92 millió USD – t jelenthet, a IBM.

Hogyan lehet megakadályozni??

Háttér fejlesztőként fel kell kérdeznie, hogy mi az a védelemre szoruló információ.

És akkor az ilyen hibák elkerülése érdekében:

  • Titkosítsa az érzékeny adatokat: A REST adatokhoz mindent titkosítson. A továbbított adatokhoz feltétlenül használjon biztonságos átjárókat (SSL)
  • Azonosítsa az extra védelmet igénylő adatokat, és csak a leghatékonyabb felhasználók körére korlátozza a hozzáférhetőséget, csak kulcs-alapú titkosítás végrehajtásával.
  • Kerülje a gyenge titkosítási algoritmust: használjon naprakész és erős algoritmusok.
  • Van biztonságos biztonsági mentési terv.

Nem biztonságos érdeklődés

A sorosítás és a érdemesítés fogalmak, amikor az adatokat objektum formátumban konvertálják tárolásra, vagy egy másik alkalmazáshoz történő elküldéshez. A sorosítás az adatok objektumformátumban, például XML vagy JSON formátumban történő konvertálásából áll, hogy ezeket felhasználhatóvá tegyék. A deszerializáció csak fordított folyamat.

A méltányosítókkal szembeni támadások szolgáltatásmegtagadáshoz, hozzáférés-vezérléshez és távoli kódfuttatáshoz (RCE) irányuló támadásokhoz vezethetnek, ha vannak osztályok, amelyek módosíthatók a viselkedés megváltoztatására.

Az OWASP top 10 dokumentumának második példája jól szemlélteti a PHP objektum sorosítóját:

Egy: 4: {i: 0; i: 132; i: 1; s: 7:"Mallory"; I: 2; s: 4:"használó";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Ez egy supercookie, amely olyan információkat tartalmaz, mint a felhasználói azonosító, a felhasználó szintje és a kivonatjelszó.

A támadó megváltoztathatja a sorosított objektumot, hogy hozzáférjen az adminisztrátori jogokhoz:

Egy: 4: {i: 0; i: 1; i: 1; s: 5:"Alice"; I: 2; s: 5:"admin";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Hogyan lehet megakadályozni??

Döntő fontosságú, hogy ne fogadjanak el a sorozat nélküli objektumokat megbízhatatlan forrásokból.

Önnek is:

  • Soha ne bízzon a felhasználói adatokban.
  • Adatok érvényesítése: Ha az alkalmazás egy karakterlánc kivételével, ellenőrizze, hogy az adott karakterlánc-e-e
  • Ellenőrizze, hogy az adatok nem változtak-e. Hasznos, ha adatokat küld két megbízható forrás között (pl. Adattárolás kliensoldalon)..

XSS szerver

XSS szerver (Helyszíni szkriptek) egy olyan típusú injekció, amikor a támadó egy webalkalmazást használ rosszindulatú kód küldésére a különböző felhasználók számára. Akkor fordul elő, amikor a támadó elkészít valamilyen olyan rosszindulatú kódot tartalmazó, kialakított adatot, amelyet az alkalmazás tárol. Ez a biztonsági rés szerver oldali; a böngésző egyszerűen megjeleníti a választ.

Például egy fórumban a felhasználói üzeneteket adatbázisba menti, gyakran ellenőrzés nélkül. A támadók megragadják ezt a lehetőséget, és rosszindulatú szkriptekkel ellátott hozzászólásokat adnak hozzá. Ezt követően más felhasználók e-mailen megkapják ezt a linket, vagy megtekintették a kérdéses bejegyzést, majd rákattintottak.

Hogyan lehet megakadályozni??

Az összes olyan művelet elsődleges azonosítása után, amelyeket potenciálisan veszélyeztet az XSS, és amelyeket meg kell védeni, fontolja meg a következőket.

  • Érvényesítse a bemenetet: ellenőrizze a bemeneti hosszúságot, használja a regex illesztést, és csak egy bizonyos karakterkészletet engedélyez.
  • Érvényesítse a kimenetet: Ha az alkalmazás válaszaiba másolja az adatok bármely elemét, amely valamilyen felhasználótól vagy harmadik féltől származik, ezeket az adatokat HTML-kódolásúaknak kell lenniük a potenciálisan rosszindulatú karakterek fertőtlenítésére..
  • Engedélyezzük a korlátozott HTML-t: például, ha van egy megjegyzés blogrendszere, csak bizonyos címkék használatát engedje meg. Ha igen, használjon megfelelő keretet a felhasználó által megadott HTML-jelöléshez, hogy megbizonyosodjon arról, hogy nem tartalmaz-e eszközöket a JavaScript végrehajtásához.

Következtetés

A fejlesztési szakasz kulcsfontosságú a webes alkalmazások biztonsága szempontjából. És fontolóra kell vennie egy biztonsági rést okozó szkenner bevonását a fejlesztési életciklusba, így az azonosított problémákat a gyártás előtt javítják..

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map