Bemenetek és kimenetek
Ma az alkalmazásoknál a leggyakoribb biztonsági rés az, ha nem megfelelően dolgozzák fel a külső forrásokból érkező adatokat, különösen a felhasználói bevitelt. Mindig minden inputot gondosan ellenőrizzen, és használat előtt ellenőrizze őket. Ha elmulasztja a felhasználói adatbevitel elemzését, annak adatvesztés vagy az adatok veszélyes megjelenítése lehet az eredménye, vagy akár rosszindulatú kódokat is futtathatnak így más felhasználók gépein.
Ebben a helyzetben az a szomorú, hogy ez a probléma nagyon egyszerűen megoldható lenne. Ebben a leckében azt mutatjuk be, hogyan kezelhetők az adatok a fogadáskor, mikor jelennek meg a képernyőn, és mikor lesznek tárolva későbbi használatra.
Miért kell a bementet ellenőrizni?
Tegyük fel, hogy egy felületet hoz létre, amely lehetővé teszi a felhasználó számára, hogy fiókot hozzon létre a webhelyén. Profiladataink között szerepel egy név, egy e-mail és egy becenév, amelyet a webhely látogatóinak jelenítünk meg. De mi történik, ha egy új felhasználó létrehoz egy profilt, és a becenév helyén megad egy SQL-parancsot? Mi történik például, ha egy rosszindulatú felhasználó az alábbi részlethez hasonlót ad meg:
Eve'); DROP TABLE Users;--
Ha ezt vakon beillesztjük az adatbázisba, akkor ez a rész úgy módosíthatja az SQL-utasítást, hogy az egy nagyon nem kívánatos parancsot futtasson! Ezt SQL-injektálásos támadásnak hívjuk, és ez csupán egy abból a számtalan támadásból, amely megtörténhet, ha nem megfelelően kezeljük a felhasználói bevitelt. De mit tehetünk, hogy kivédjük ezeket? Ebben a leckében azt vizsgáljuk meg, hogyan lehet a bemenetet ellenőrizni, hogyan lehet a kimenetet titkosítani, és hogyan lehet paraméterekkel rendelkező lekérdezéseket létrehozni (ezekkel kivédhető a fenti támadás is). Ez a három legfontosabb védelmi technika, amelyekkel kivédhetők az alkalmazásokba bevitt bemenetek.
Mikor kell ellenőrizni a bemenetet?
A válasz: mindig. Az alkalmazásra irányuló összes bemenetet ellenőrizni kell. Ez magában foglalja az URL-cím paramétereit, a felhasználótól érkező bemenetet, az adatbázisból származó adatokat, az API-ból származó adatokat, valamint minden olyan adatot, amelyet a felhasználó esetleg manipulálhat. Mindig használjon engedélyezési listát, ami azt jelenti, hogy csak az "ismert jó" bemenetet fogadja el a tiltólista helyett (ahol kifejezetten rossz bemenetet keres), mert lehetetlen a potenciálisan veszélyes bemenetek teljes listájára gondolni. Ne az ügyféloldalon (vagy az ügyféloldalon kívül) működjön a kiszolgálón, hogy a védelem ne legyen megkerülhető. Az ÖSSZES adatot nem megbízhatóként kezeli, és védelmet nyújt a webalkalmazások gyakori biztonsági réseitől.
Ha ASP.NET használ, a keretrendszer nagy támogatást nyújt a bemenetek ügyfél- és kiszolgálóoldali ellenőrzéséhez.
Ha egy másik webes keretrendszert használ, az OWASP Input Validation Cheatsheetben számos kiváló módszer áll rendelkezésre a bemeneti ellenőrzés elvégzésére.
Mindig használjon paraméteres lekérdezést
Az SQL-adatbázisokat gyakran használják adatok tárolására; Az alkalmazás például egy adatbázisban tárolhatja a felhasználói profil adatait. Soha ne hozzon létre beágyazott SQL-lekérdezéseket vagy más adatbázis-lekérdezéseket a kódban nyers felhasználói bemenet használatával, és küldje el közvetlenül az adatbázisba; ez a viselkedés a katasztrófa receptje, ahogy azt korábban láttuk.
Például ne hozzon létre olyan kódot, mint a következő beágyazott SQL-példa:
string userName = Request.QueryString["username"]; // receive input from the user BEWARE!
...
string query = "SELECT * FROM [dbo].[users] WHERE userName = '" + userName + "'";
Itt a felhasználótól kapott bemeneteket használva sztringeket fűzünk össze a lekérdezés összeállításához, és egy dinamikus SQL-lekérdezést hozunk létre a felhasználó kikereséséhez. Ha azonban egy rosszindulatú felhasználó rájön, hogy ez történik, vagy egyszerűen csak kipróbál különféle bemeneteket, hogy rájöjjön, van-e valamilyen biztonsági rés, az komoly bajba sodorhat minket. Ehelyett használjon paraméteres SQL-lekérdezéseket vagy ehhez hasonló tárolt eljárásokat:
-- Lookup a user
CREATE PROCEDURE sp_findUser
(
@UserName varchar(50)
)
SELECT * FROM [dbo].[users] WHERE userName = @UserName
Ezzel a módszerrel biztonságosan meghívhatja az eljárást a kódból, és átadhatja a userName sztringet anélkül, hogy az SQL-utasítás részeként kezelné.
A kimenetet mindig titkosítsa
Minden olyan adatot titkosítania kell és feloldójelekkel (más néven ESCAPE-karakterekkel) kell ellátnia, amelyeket megjelenít vagy dokumentumokban tárol. Ez védelmet nyújthat abban az esetben, ha valami kimaradt a tisztítási bérletből, vagy a kód véletlenül létrehoz valamit, amely rosszindulatúan használható. Ez a tervezési kialakítás gondoskodik arról, hogy minden kimenetként jelenjen meg, és soha ne legyen véletlenül sem végrehajtandó kódként értelmezve, ami egy másik gyakori támadási módszer, amelyet „webhelyközi szkriptalapú támadásként” (XSS) ismerünk.
Mivel az XSS megelőzése gyakori követelmény az alkalmazásoknál, ez is egy olyan biztonsági terület, ahol a ASP.NET elvégzi a munkát Ön helyett. Alapértelmezés szerint minden kimenet eleve kódolva van. Ha egy másik webes keretrendszert használ, az OWASP XSS Prevention Cheatsheettel ellenőrizheti a webhelyeken a kimeneti kódolási lehetőségeket.
Összesítés
A bemenet megtisztítása és ellenőrzése alapvető követelmény ahhoz, hogy a bemenetet biztonságosan használhassuk és tárolhassuk. A legtöbb modern keretrendszer beépített funkciói automatizálhatják ezeket a folyamatokat. Ellenőrizze a választott keretrendszer dokumentációját, és tekintse meg annak funkcióit. Bár ez leggyakrabban webalkalmazásokban fordul elő, más típusú alkalmazások is sebezhetők lehetnek. Ne gondolja, hogy biztonságban van csak amiatt, hogy az új alkalmazása egy asztali alkalmazás. Továbbra is megfelelően kell kezelnie a felhasználói adatokat, hogy meggyőződjön arról, hogy valaki nem használja az alkalmazást az adatai sérülésére vagy a vállalat hírnevének sérülésére.