Megosztás a következőn keresztül:

Biztonsági szempontok (Entity Framework)

  • Cikk

Ez a témakör az Entity Framework-alkalmazások fejlesztésére, üzembe helyezésére és futtatására vonatkozó biztonsági szempontokat ismerteti. A biztonságos .NET-keretrendszer alkalmazások létrehozására vonatkozó javaslatokat is követnie kell. További információ: Biztonsági áttekintés.

Általános biztonsági szempontok

Az alábbi biztonsági szempontok az entitás-keretrendszert használó összes alkalmazásra vonatkoznak.

Csak megbízható adatforrás-szolgáltatókat használjon.

Az adatforrással való kommunikációhoz a szolgáltatónak a következőket kell tennie:

  • Fogadja a kapcsolati sztring az Entity Frameworkből.

  • Fordítsa le a parancsfát az adatforrás natív lekérdezési nyelvére.

  • Eredményhalmazok összeállítása és visszaadása.

A bejelentkezési művelet során a felhasználói jelszón alapuló információkat a rendszer a mögöttes adatforrás hálózati kódtárain keresztül továbbítja a kiszolgálónak. A rosszindulatú szolgáltatók ellophatják a felhasználói hitelesítő adatokat, rosszindulatú lekérdezéseket hozhatnak létre, vagy módosíthatják az eredményhalmazt.

Titkosítsa a kapcsolatot a bizalmas adatok védelme érdekében.

Az Entity Framework nem kezeli közvetlenül az adattitkosítást. Ha a felhasználók nyilvános hálózaton keresztül férnek hozzá az adatokhoz, az alkalmazásnak titkosított kapcsolatot kell létesítenie az adatforrással a biztonság növelése érdekében. További információkért tekintse meg az adatforrás biztonsággal kapcsolatos dokumentációját. SQL Server-adatforrások esetén lásd: Csatlakozás ions titkosítása az SQL Serverhez.

Biztosítsa a kapcsolati sztring.

Az adatforráshoz való hozzáférés védelme az alkalmazások biztonságossá tételének egyik legfontosabb célja. A kapcsolati sztring potenciális biztonsági rést jelent, ha nincs biztosítva, vagy ha nem megfelelően van kialakítva. Ha egyszerű szövegben tárolja a kapcsolati adatokat, vagy megőrzi azokat a memóriában, a rendszer egészét veszélyeztetheti. A kapcsolati sztring biztonságossá tételéhez az alábbi módszerek ajánlottak:

  • Windows-hitelesítés használata SQL Server-adatforrással.

    Ha Windows-hitelesítéssel csatlakozik egy SQL Server-adatforráshoz, a kapcsolati sztring nem tartalmaz bejelentkezési és jelszóadatokat.

  • A konfigurációs fájlszakaszok titkosítása védett konfigurációval.

    ASP.NET egy védett konfiguráció nevű funkciót biztosít, amely lehetővé teszi a bizalmas adatok titkosítását egy konfigurációs fájlban. Bár elsősorban ASP.NET, védett konfigurációval is titkosíthatja a windowsos alkalmazások konfigurációs fájljainak szakaszait. Az új védett konfigurációs képességek részletes leírását lásd : Konfigurációs információk titkosítása védett konfiguráció használatával.

  • Biztonságos konfigurációs fájlokban tárolja a kapcsolati sztring.

    Soha ne ágyazza be kapcsolati sztring a forráskódba. A kapcsolati sztring konfigurációs fájlokban tárolhatja, így nem szükséges beágyazni őket az alkalmazás kódjába. Alapértelmezés szerint az Entitásadatmodell varázsló kapcsolati sztring tárol az alkalmazáskonfigurációs fájlban. A jogosulatlan hozzáférés megakadályozása érdekében biztonságossá kell tennie ezt a fájlt.

  • A kapcsolatok dinamikus létrehozásakor kapcsolati sztring szerkesztőket használhat.

    Ha futásidőben kell létrehoznia kapcsolati sztring, használja az osztálytEntityConnectionStringBuilder. Ez a sztringszerkesztő osztály segít megelőzni kapcsolati sztring injektálási támadásokat az érvénytelen bemeneti adatok ellenőrzésével és szökésével. További információ: Entitás létrehozása Csatlakozás ion Csatlakozás ion-sztring. Használja a megfelelő sztringszerkesztő osztályt az Entity Framework kapcsolati sztring részét képező adatforrás-kapcsolati sztring létrehozásához is. A ADO.NET-szolgáltatók kapcsolati sztring készítőiről a Csatlakozás ion String Builders című témakörben talál további információt.

További információ: Csatlakozás ion-információk védelme.

Ne tegyen közzé entitást Csatlakozás nem megbízható felhasználók számára.

Egy EntityConnection objektum elérhetővé teszi a mögöttes kapcsolat kapcsolati sztring. Az objektumhoz EntityConnection hozzáféréssel rendelkező felhasználók módosíthatják a ConnectionState mögöttes kapcsolatot is. Az EntityConnection osztály nem biztonságos.

Ne adjon át kapcsolatokat a biztonsági környezeten kívül.

A kapcsolat létrejötte után nem szabad a biztonsági környezeten kívül átadni. Egy kapcsolat megnyitására engedéllyel rendelkező szál például nem tárolhatja a kapcsolatot globális helyen. Ha a kapcsolat egy globális helyen érhető el, akkor egy másik rosszindulatú szál anélkül használhatja a nyitott kapcsolatot, hogy ehhez külön engedélyt adna.

Vegye figyelembe, hogy a bejelentkezési adatok és jelszavak egy memóriaképben is megjelenhetnek.

Amikor az adatforrás bejelentkezési és jelszóadatait a kapcsolati sztring adja meg, az adatok a memóriában maradnak, amíg a szemétgyűjtés vissza nem kéri az erőforrásokat. Ez lehetetlenné teszi annak meghatározását, hogy egy jelszósztring már nem szerepel-e a memóriában. Ha egy alkalmazás összeomlik, a memóriaképfájl bizalmas biztonsági információkat tartalmazhat, és az alkalmazást futtató felhasználó és a számítógéphez rendszergazdai hozzáféréssel rendelkező felhasználók megtekinthetik a memóriaképfájlt. Windows-hitelesítés használata a Microsoft SQL Serverrel való kapcsolatokhoz.

Csak a szükséges engedélyeket adja meg a felhasználóknak az adatforrásban.

Az adatforrás-rendszergazdáknak csak a szükséges engedélyeket kell megadniuk a felhasználóknak. Annak ellenére, hogy az Entity SQL nem támogatja az adatokat módosító DML-utasításokat(például IN Standard kiadás RT, UPDATE vagy DELETE), a felhasználók továbbra is hozzáférhetnek az adatforráshoz való csatlakozáshoz. A rosszindulatú felhasználók ezzel a kapcsolattal DML-utasításokat hajthatnak végre az adatforrás anyanyelvén.

Futtassa a minimális engedélyekkel rendelkező alkalmazásokat.

Ha engedélyezi, hogy egy felügyelt alkalmazás teljes megbízhatósági engedéllyel fusson, a .NET-keretrendszer nem korlátozza az alkalmazás számítógéphez való hozzáférését. Ez lehetővé teheti, hogy az alkalmazás biztonsági rése a teljes rendszert veszélyeztetje. A kódhozzáférés biztonsági és egyéb biztonsági mechanizmusainak a .NET-keretrendszer való használatához részleges megbízhatósági engedélyekkel és az alkalmazás működéséhez szükséges minimális engedélykészlettel kell futtatnia az alkalmazásokat. Az alábbi kódhozzáférés-engedélyek az Entity Framework-alkalmazás minimális engedélyeinek száma:

További információ: Code Access Security és ADO.NET.

Ne telepítse a nem megbízható alkalmazásokat.

Az Entity Framework nem kényszerít biztonsági engedélyeket, és meghívja a felhasználó által megadott, folyamatban lévő adatobjektum-kódot, függetlenül attól, hogy megbízható-e vagy sem. Győződjön meg arról, hogy az ügyfél hitelesítését és engedélyezését az adattár és az alkalmazás végzi.

Az összes konfigurációs fájlhoz való hozzáférés korlátozása.

A rendszergazdáknak korlátozniuk kell az írási hozzáférést az alkalmazások konfigurációját meghatározó összes fájlhoz, beleértve az enterpriseec.config, a security.config, a machine.conf és az alkalmazáskonfigurációs fájlalkalmazás <.exe.config fájlalkalmazást>.

A szolgáltató invariáns neve módosítható az app.configban. Az ügyfélalkalmazásnak felelősséget kell vállalnia azért, hogy a mögöttes szolgáltatót a standard szolgáltató-gyári modellen keresztül, erős név használatával érheti el.

A modellre és a leképezési fájlokra vonatkozó engedélyek korlátozása.

A rendszergazdáknak csak a modellt vagy leképezéseket módosító felhasználókra kell korlátozniuk a modellhez és a leképezési fájlokhoz (.edmx, .csdl, .ssdl és .msl) való írási hozzáférést. Az Entity Framework csak olvasási hozzáférést igényel ezekhez a fájlokhoz futásidőben. A rendszergazdáknak korlátozniuk kell az entitás adatmodell eszközei által létrehozott objektumréteghez és előre lefordított nézet forráskódfájljaihoz való hozzáférést.

A lekérdezések biztonsági szempontjai

Az alábbi biztonsági szempontok vonatkoznak egy elméleti modell lekérdezésére. Ezek a szempontok az EntityClientet használó Entity SQL-lekérdezésekre, valamint a LINQ, az Entity SQL és a lekérdezésszerkesztő metódusok használatával végzett objektumlekérdezésekre vonatkoznak.

Sql-injektálási támadások megakadályozása.

Az alkalmazások gyakran külső bemenetet használnak (egy felhasználótól vagy egy másik külső ügynöktől), és ezen bemenet alapján hajtanak végre műveleteket. A felhasználótól vagy külső ügynöktől közvetlenül vagy közvetve származó bemenetek olyan tartalommal rendelkezhetnek, amely a célnyelv szintaxisát használja jogosulatlan műveletek végrehajtásához. Ha a célnyelv egy strukturált lekérdezési nyelv (SQL), például Transact-SQL, ezt a manipulációt SQL-injektálási támadásnak nevezzük. A rosszindulatú felhasználók közvetlenül a lekérdezésbe injektálhatnak parancsokat, és elvethetnek egy adatbázistáblát, szolgáltatásmegtagadást okozhatnak, vagy más módon módosíthatják a végrehajtott művelet jellegét.

  • Entitás SQL-injektálási támadásai:

    Az SQL-injektálási támadások az Entity SQL-ben végezhetők el úgy, hogy rosszindulatú bemenetet adnak a lekérdezési predikátumban és a paraméternevekben használt értékekhez. Az SQL-injektálás kockázatának elkerülése érdekében soha ne kombinálja a felhasználói bemenetet az Entity SQL parancsszöveggel.

    Az entity SQL-lekérdezések mindenhol elfogadják a paramétereket, ahol a konstansokat elfogadják. Paraméteres lekérdezéseket kell használnia ahelyett, hogy konstansokat injektálhat egy külső ügynökből közvetlenül a lekérdezésbe. Érdemes megfontolnia a lekérdezésszerkesztő metódusok használatát is az Entity SQL biztonságos létrehozásához.

  • LINQ to Entities injektálási támadások:

    Bár a lekérdezések összeállítása a LINQ-ban az Entitások között lehetséges, az objektummodell API-n keresztül történik. Az Entity SQL-lekérdezésekkel ellentétben az entitások közötti LINQ-lekérdezések nem sztringmanipulációval vagy összefűzéssel állnak össze, és nem érzékenyek a hagyományos SQL-injektálási támadásokra.

Nagyon nagy eredményhalmazok megakadályozása.

Egy nagyon nagy eredményhalmaz miatt az ügyfélrendszer leállhat, ha az ügyfél olyan műveleteket hajt végre, amelyek az eredményhalmaz méretével arányos erőforrásokat használnak fel. Váratlanul nagy eredményhalmazok fordulhatnak elő a következő feltételek mellett:

  • Olyan nagy adatbázis lekérdezéseiben, amelyek nem tartalmaznak megfelelő szűrési feltételeket.

  • A kiszolgálón Cartesian-illesztéseket létrehozó lekérdezésekben.

  • Beágyazott Entity SQL-lekérdezésekben.

A felhasználói bemenet elfogadásakor győződjön meg arról, hogy a bemenet nem okozhatja az eredményhalmazok nagyobbá válását, mint amit a rendszer kezelni tud. Az eredményhalmaz méretének korlátozásához használhatja a Take LINQ metódust az Entitások vagy az Entity SQL LIMIT operátorában is.

Kerülje az IQueryable-eredmények visszaadását, ha metódusokat ad ki a potenciálisan nem megbízható hívóknak.

Kerülje a típusok visszaadását IQueryable<T> olyan metódusokból, amelyek potenciálisan nem megbízható hívóknak vannak kitéve a következő okokból:

  • Egy olyan lekérdezés felhasználója, amely egy típust IQueryable<T> tesz elérhetővé, meghívhat olyan metódusokat az eredményen, amelyek biztonságos adatokat tehetnek közzé, vagy növelhetik az eredményhalmaz méretét. Vegyük például a következő metódus-aláírást:

    public IQueryable<Customer> GetCustomer(int customerId)

    A lekérdezés egy felhasználója meghívhatja .Include("Orders") a visszaadott IQueryable<Customer> adatokat olyan adatok lekérésére, amelyeket a lekérdezés nem kívánt elérhetővé tenni. Ez elkerülhető a metódus IEnumerable<T> visszatérési típusának módosításával, és egy olyan metódus meghívásával (például .ToList()) amely az eredményeket eredményezi.

  • Mivel IQueryable<T> a lekérdezések végrehajtása az eredmények iterated után történik, egy olyan lekérdezés felhasználója, amely egy típust tesz elérhetővé IQueryable<T> , elkaphatja a kidobott kivételeket. A kivételek tartalmazhatnak olyan információkat, amelyeket nem a fogyasztónak szántak.

Az entitások biztonsági szempontjai

Az entitástípusok létrehozásakor és használatakor az alábbi biztonsági szempontok érvényesek.

Ne ossza meg az ObjectContextet az alkalmazástartományokban.

Ha ObjectContext több alkalmazástartományt is megoszt egy alkalmazástartománysal, az információkat közzéteheti a kapcsolati sztring. Ehelyett szerializált objektumokat vagy objektumgráfokat kell átvinnie a másik alkalmazástartományba, majd csatolnia kell ezeket az objektumokat egy adott alkalmazástartományhoz ObjectContext . További információ: Objektumok szerializálása.

A típusbiztonsági szabálysértések megakadályozása.

A típusbiztonság megsértése esetén az Entity Framework nem tudja garantálni az objektumokban lévő adatok integritását. A típusbiztonság megsértése akkor fordulhat elő, ha engedélyezi, hogy a nem megbízható alkalmazások teljes megbízhatóságú kódhozzáférési biztonsággal fussanak.

Kivételek kezelése.

Egy kipróbálási blokkon belüli hozzáférési módszerek és tulajdonságok ObjectContext . A kivételekkel megakadályozható, hogy a kezeletlen kivételek felfedjék az alkalmazás felhasználóinak a modellinformációkban vagy a ObjectStateManager modelladatokban szereplő bejegyzéseket (például táblaneveket).

Biztonsági szempontok az ASP.NET-alkalmazásokhoz

Az alábbi szempontokat érdemes figyelembe vennie, amikor ASP.NET alkalmazások elérési útjaival dolgozik.

Ellenőrizze, hogy a gazdagép végrehajtja-e az útvonal-ellenőrzéseket.

Ha a |DataDirectory| (csőszimbólumok közé foglalt) helyettesítési sztringet használja, ADO.NET ellenőrzi, hogy a feloldott elérési út támogatott-e. A ".." például nem engedélyezett a háttérben DataDirectory. Ugyanezt az ellenőrzést a webalkalmazás fő operátorának (~) a ASP.NET üzemeltető folyamat végzi el. Az IIS elvégzi ezt az ellenőrzést; az IIS-nek nem megfelelő gazdagépek azonban nem feltétlenül ellenőrzik, hogy a feloldott elérési út támogatott-e. Ismernie kell annak a gazdagépnek a viselkedését, amelyen egy Entity Framework-alkalmazást helyez üzembe.

Ne tegyen feltételezéseket a feloldott elérési utak nevével kapcsolatban.

Bár a gyökér operátor (~) és a DataDirectory helyettesítési sztring feloldása az alkalmazás futásideje alatt állandó marad, az Entity Framework nem korlátozza a gazdagépet az értékek módosításában.

Ellenőrizze az elérési út hosszát az üzembe helyezés előtt.

Egy Entity Framework-alkalmazás üzembe helyezése előtt győződjön meg arról, hogy a gyökéroperátor (~) és DataDirectory a helyettesítési sztring értékei nem lépik túl az operációs rendszerben az elérési út hosszának korlátait. ADO.NET adatszolgáltatók nem biztosítják, hogy az elérési út hossza érvényes korlátokon belül legyen.

A ADO.NET metaadataival kapcsolatos biztonsági szempontok

A modell- és leképezési fájlok létrehozásakor és használatakor az alábbi biztonsági szempontok érvényesek.

Ne tegye közzé a bizalmas adatokat naplózással.

ADO.NET metaadat-szolgáltatás összetevői nem naplóznak semmilyen személyes adatot. Ha vannak olyan eredmények, amelyeket a hozzáférési korlátozások miatt nem lehet visszaadni, az adatbázis-kezelő rendszereknek és a fájlrendszereknek nulla eredményt kell visszaadnia ahelyett, hogy bizalmas információkat tartalmazó kivételt emelnének ki.

Ne fogadja el a MetadataWorkspace objektumokat nem megbízható forrásokból.

Az alkalmazások nem fogadják el az MetadataWorkspace osztály példányait nem megbízható forrásokból. Ehelyett explicit módon kell létrehoznia és feltöltenie egy munkaterületet egy ilyen forrásból.

Lásd még