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


Biztonsági keret: Bemeneti ellenőrzés | Enyhítése

Termék/szolgáltatás Cikk
Webalkalmazás
Adatbázis
Webes API
Azure Document DB
WCF

XSLT-szkriptek letiltása az összes átalakításhoz nem megbízható stíluslapok használatával

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák Általános
Attribútumok n/a
Hivatkozások XSLT Security, XsltSettings.EnableScript tulajdonság
Lépések Az XSLT az elem használatával támogatja a stíluslapokon belüli szkriptelést <msxml:script> . Ez lehetővé teszi az egyéni függvények használatát egy XSLT-átalakításban. A szkript végrehajtása az átalakítást végrehajtó folyamat kontextusában történik. Az XSLT-szkriptet le kell tiltani nem megbízható környezetben a nem megbízható kód végrehajtásának megakadályozása érdekében. Ha .NET-et használ: az XSLT-szkriptek alapértelmezés szerint le vannak tiltva, azonban meg kell győződnie arról, hogy a tulajdonságon keresztül XsltSettings.EnableScript nem lett explicit módon engedélyezve.

Példa

XsltSettings settings = new XsltSettings();
settings.EnableScript = true; // WRONG: THIS SHOULD BE SET TO false

Példa

Ha MSXML 6.0-t használ, az XSLT-szkriptek alapértelmezés szerint le vannak tiltva; Azonban meg kell győződnie arról, hogy nem lett explicit módon engedélyezve az AllowXsltScript XML DOM objektumtulajdonságon keresztül.

doc.setProperty("AllowXsltScript", true); // WRONG: THIS SHOULD BE SET TO false

Példa

Ha MSXML 5 vagy újabb verziót használ, az XSLT-szkriptek alapértelmezés szerint engedélyezve vannak, és explicit módon le kell tiltania. Állítsa az XML DOM-objektum AllowXsltScript tulajdonságát hamisra.

doc.setProperty("AllowXsltScript", false); // CORRECT. Setting to false disables XSLT scripting.

Győződjön meg arról, hogy a felhasználó által vezérelhető tartalmakat tartalmazó lapok nem tartalmazzák az automatikus MIME-sniffinget

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák Általános
Attribútumok n/a
Hivatkozások IE8 Security Part V – Átfogó védelem
Lépések

Minden olyan laphoz, amely felhasználó által vezérelhető tartalmat tartalmazhat, a HTTP-fejlécet kell használnia X-Content-Type-Options:nosniff. Ennek a követelménynek való megfeleléshez beállíthatja a szükséges fejlécoldalt oldal szerint csak azokra a lapokra, amelyek felhasználó által vezérelhető tartalmat tartalmazhatnak, vagy globálisan beállíthatja az alkalmazás összes lapjára vonatkozóan.

A webkiszolgálókról küldött fájlok minden egyes típusa rendelkezik egy társított MIME-típussal (más néven tartalomtípussal), amely leírja a tartalom természetét (azaz kép, szöveg, alkalmazás stb.)

Az X-Content-Type-Options fejléc egy HTTP-fejléc, amely lehetővé teszi a fejlesztők számára, hogy megadják, hogy a tartalom ne legyen MIME-sniffed. Ez a fejléc a MIME-Sniffing támadások enyhítésére szolgál. A fejléc támogatása az Internet Explorer 8 -ban (IE8) lett hozzáadva

Csak az Internet Explorer 8 (IE8) felhasználói használhatják az X-Content-Type-Options lehetőséget. Az Internet Explorer korábbi verziói jelenleg nem tartják be az X-Content-Type-Options fejlécet

Az Internet Explorer 8 (és újabb verziók) az egyetlen fő böngészők a MIME-szippantás letiltási funkció implementálásához. Ha és amikor más nagyobb böngészők (Firefox, Safari, Chrome) hasonló funkciókat implementálnak, ez a javaslat frissül, hogy a böngészők szintaxisát is tartalmazza

Példa

Ha globálisan szeretné engedélyezni a szükséges fejlécet az alkalmazás összes oldalához, tegye az alábbiak egyikét:

  • Adja hozzá a fejlécet a web.config fájlhoz, ha az alkalmazást az Internet Information Services (IIS) 7 üzemelteti
<system.webServer> 
  <httpProtocol> 
    <customHeaders> 
      <add name=""X-Content-Type-Options"" value=""nosniff""/>
    </customHeaders>
  </httpProtocol>
</system.webServer> 
  • A fejléc hozzáadása a globális Application_BeginRequest
void Application_BeginRequest(object sender, EventArgs e)
{
  this.Response.Headers[""X-Content-Type-Options""] = ""nosniff"";
} 
  • Egyéni HTTP-modul implementálása
public class XContentTypeOptionsModule : IHttpModule 
  {
    #region IHttpModule Members 
    public void Dispose() 
    { 

    } 
    public void Init(HttpApplication context)
    { 
      context.PreSendRequestHeaders += newEventHandler(context_PreSendRequestHeaders); 
    } 
    #endregion 
    void context_PreSendRequestHeaders(object sender, EventArgs e) 
      { 
        HttpApplication application = sender as HttpApplication; 
        if (application == null) 
          return; 
        if (application.Response.Headers[""X-Content-Type-Options ""] != null) 
          return; 
        application.Response.Headers.Add(""X-Content-Type-Options "", ""nosniff""); 
      } 
  } 

  • A szükséges fejlécet csak adott oldalakhoz engedélyezheti, ha hozzáadja az egyes válaszokhoz:
this.Response.Headers[""X-Content-Type-Options""] = ""nosniff""; 

XML-entitás felbontásának megerősítése vagy letiltása

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák Általános
Attribútumok n/a
Hivatkozások XML-entitásbővítés, szolgáltatásmegtagadási támadások és védelem, MSXML biztonsági áttekintés, ajánlott eljárások az MSXML-kód biztonságossá tételéhez, NSXMLParserDelegate protokollreferenciák, külső hivatkozások feloldása
Lépések

Bár nem széles körben használják, az XML egy olyan funkciója, amely lehetővé teszi az XML-elemző számára a makróentitások kibontását a dokumentumban vagy külső forrásokból meghatározott értékekkel. A dokumentum definiálhat például egy "cégnév" entitást a "Microsoft" értékkel, így a program minden alkalommal, amikor a "&cégnév;" szöveg megjelenik a dokumentumban, a rendszer automatikusan a Microsoft szövegre cseréli. Vagy a dokumentum definiálhat egy "MSFTStock" entitást, amely egy külső webszolgáltatásra hivatkozik a Microsoft-részvények aktuális értékének lekéréséhez.

Ezután bármikor, amikor a dokumentumban megjelenik a "&MSFTStock;" kifejezés, a rendszer automatikusan lecseréli az aktuális részvényárfolyamra. Ez a funkció azonban visszaélhet a szolgáltatásmegtagadási (DoS-) feltételek létrehozásához. A támadók több entitást is beágyazhatnak egy exponenciális expanziós XML-bomba létrehozásához, amely a rendszer összes rendelkezésre álló memóriáját felhasználja.

Másik lehetőségként létrehozhat egy külső hivatkozást, amely végtelen mennyiségű adatot streamel vissza, vagy egyszerűen felakasztja a szálat. Ennek eredményeképpen minden csapatnak teljesen le kell tiltania a belső és/vagy külső XML-entitásfeloldást, ha az alkalmazás nem használja, vagy manuálisan korlátoznia kell az alkalmazás által az entitásfeloldáshoz felhasználható memória és idő mennyiségét, ha ez a funkció feltétlenül szükséges. Ha az alkalmazás nem igényel entitásfeloldást, tiltsa le.

Példa

.NET-keretrendszer kód esetében a következő módszereket használhatja:

XmlTextReader reader = new XmlTextReader(stream);
reader.ProhibitDtd = true;

XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = true;
XmlReader reader = XmlReader.Create(stream, settings);

// for .NET 4
XmlReaderSettings settings = new XmlReaderSettings();
settings.DtdProcessing = DtdProcessing.Prohibit;
XmlReader reader = XmlReader.Create(stream, settings);

Vegye figyelembe, hogy az alapértelmezett érték ProhibitDtdXmlReaderSettings igaz, de hamis XmlTextReader . Ha XmlReaderSettings-t használ, nem kell explicit módon igazra állítania a TiltottDtd értéket, de biztonsági okokból ajánlott. Azt is vegye figyelembe, hogy az XmlDocument osztály alapértelmezés szerint lehetővé teszi az entitások felbontását.

Példa

Az XmlDocuments entitásfeloldásának letiltásához használja a XmlDocument.Load(XmlReader) Load metódus túlterhelését, és állítsa be a megfelelő tulajdonságokat az XmlReader argumentumban a feloldás letiltásához, ahogyan az az alábbi kódban is látható:

XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = true;
XmlReader reader = XmlReader.Create(stream, settings);
XmlDocument doc = new XmlDocument();
doc.Load(reader);

Példa

Ha az alkalmazás nem tudja letiltani az entitásfeloldást, állítsa az XmlReaderSettings.MaxCharactersFromEntities tulajdonságot ésszerű értékre az alkalmazás igényeinek megfelelően. Ez korlátozza a potenciális exponenciális expanziós DoS-támadások hatását. Az alábbi kód erre a megközelítésre ad példát:

XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = false;
settings.MaxCharactersFromEntities = 1000;
XmlReader reader = XmlReader.Create(stream, settings);

Példa

Ha fel kell oldania a beágyazott entitásokat, de nem kell külső entitásokat feloldania, állítsa az XmlReaderSettings.XmlResolver tulajdonságot null értékre. Példa:

XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = false;
settings.MaxCharactersFromEntities = 1000;
settings.XmlResolver = null;
XmlReader reader = XmlReader.Create(stream, settings);

Vegye figyelembe, hogy az MSXML6-ban a ProhibitDTD értéke alapértelmezés szerint igaz (a DTD-feldolgozás letiltása). Apple OSX/iOS-kód esetén két XML-elemző használható: NSXMLParser és libXML2.

A http.sys használó alkalmazások URL-címkonikonicalizálási ellenőrzést végeznek

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák Általános
Attribútumok n/a
Hivatkozások n/a
Lépések

Az http.sys használó alkalmazásoknak az alábbi irányelveket kell követniük:

  • Az URL-cím hosszát legfeljebb 16 384 karakterre korlátozhatja (ASCII vagy Unicode). Ez az alapértelmezett Internet Information Services (IIS) 6-os beállításon alapuló abszolút maximális URL-hossz. A webhelyeknek ennél rövidebb hosszra kell törekednie, ha lehetséges
  • Használja a standard .NET-keretrendszer fájl I/O-osztályokat (például a FileStreamet), mivel ezek kihasználják a .NET FX-ben a canonicalization szabályokat
  • Az ismert fájlnevek engedélyezési listájának explicit létrehozása
  • Kifejezetten elutasítja az ismert fájltípusokat, amelyek nem szolgálnak ki UrlScan-elutasításokat: exe, bat, cmd, com, htw, ida, idq, htr, idc, shtm[l], stm, nyomtató, ini, pol, dat files
  • A következő kivételeket észleli:
    • System.ArgumentException (eszköznevek esetén)
    • System.NotSupportedException (adatfolyamokhoz)
    • System.IO.FileNotFoundException (érvénytelen fájlnevek esetén)
    • System.IO.DirectoryNotFoundException (érvénytelen szökött naplók esetén)
  • Ne hívja fel a Win32-fájl I/O API-jait. Érvénytelen URL-cím esetén 400-os hibát ad vissza a felhasználónak, és naplózza a valódi hibát.

Győződjön meg arról, hogy megfelelő vezérlők vannak érvényben a fájlok felhasználóktól való elfogadásakor

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák Általános
Attribútumok n/a
Hivatkozások Korlátlan fájlfeltöltés, fájladakta-tábla
Lépések

A feltöltött fájlok jelentős kockázatot jelentenek az alkalmazások számára.

Sok támadás első lépése, hogy lekér egy kódot a támadni kívánt rendszerhez. Ezután a támadásnak csak módot kell találnia a kód végrehajtására. A fájlfeltöltés segít a támadónak az első lépés végrehajtásában. A korlátlan fájlfeltöltés következményei eltérőek lehetnek, beleértve a teljes rendszerátvételt, a túlterhelt fájlrendszert vagy adatbázist, a támadások háttérrendszerekre való továbbítását és az egyszerű hibakeresést.

Ez attól függ, hogy az alkalmazás mit csinál a feltöltött fájllal, és különösen attól, hogy hol tárolja. Hiányzik a fájlfeltöltések kiszolgálóoldali ellenőrzése. A Fájlfeltöltés funkcióhoz a következő biztonsági vezérlőket kell implementálnia:

  • Fájlkiterjesztés ellenőrzése (csak az engedélyezett fájltípus érvényes készlete fogadható el)
  • Maximális fájlméretkorlát
  • A fájlt nem szabad feltölteni a webrootba; a helynek egy könyvtárnak kell lennie a nem rendszermeghajtón
  • Az elnevezési konvenciót úgy kell követni, hogy a feltöltött fájlnév véletlenszerű legyen, hogy megakadályozza a fájl felülírását
  • A lemezre való írás előtt a fájlokat vírusirtóként kell beolvasni
  • Győződjön meg arról, hogy a fájlnév és az egyéb metaadatok (például a fájl elérési útja) ellenőrizve vannak a kártékony karakterek esetében
  • Ellenőrizni kell a fájlformátum aláírását, hogy a felhasználó ne töltsön fel maszkolt fájlt (például egy exe fájl feltöltése a kiterjesztés txt fájlra való módosításával)

Példa

A fájlformátum aláírásának érvényesítésével kapcsolatos utolsó pontért tekintse meg az alábbi osztályt a részletekért:

        private static Dictionary<string, List<byte[]>> fileSignature = new Dictionary<string, List<byte[]>>
                    {
                    { ".DOC", new List<byte[]> { new byte[] { 0xD0, 0xCF, 0x11, 0xE0, 0xA1, 0xB1, 0x1A, 0xE1 } } },
                    { ".DOCX", new List<byte[]> { new byte[] { 0x50, 0x4B, 0x03, 0x04 } } },
                    { ".PDF", new List<byte[]> { new byte[] { 0x25, 0x50, 0x44, 0x46 } } },
                    { ".ZIP", new List<byte[]> 
                                            {
                                              new byte[] { 0x50, 0x4B, 0x03, 0x04 },
                                              new byte[] { 0x50, 0x4B, 0x4C, 0x49, 0x54, 0x55 },
                                              new byte[] { 0x50, 0x4B, 0x53, 0x70, 0x58 },
                                              new byte[] { 0x50, 0x4B, 0x05, 0x06 },
                                              new byte[] { 0x50, 0x4B, 0x07, 0x08 },
                                              new byte[] { 0x57, 0x69, 0x6E, 0x5A, 0x69, 0x70 }
                                                }
                                            },
                    { ".PNG", new List<byte[]> { new byte[] { 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A } } },
                    { ".JPG", new List<byte[]>
                                    {
                                              new byte[] { 0xFF, 0xD8, 0xFF, 0xE0 },
                                              new byte[] { 0xFF, 0xD8, 0xFF, 0xE1 },
                                              new byte[] { 0xFF, 0xD8, 0xFF, 0xE8 }
                                    }
                                    },
                    { ".JPEG", new List<byte[]>
                                        { 
                                            new byte[] { 0xFF, 0xD8, 0xFF, 0xE0 },
                                            new byte[] { 0xFF, 0xD8, 0xFF, 0xE2 },
                                            new byte[] { 0xFF, 0xD8, 0xFF, 0xE3 }
                                        }
                                        },
                    { ".XLS", new List<byte[]>
                                            {
                                              new byte[] { 0xD0, 0xCF, 0x11, 0xE0, 0xA1, 0xB1, 0x1A, 0xE1 },
                                              new byte[] { 0x09, 0x08, 0x10, 0x00, 0x00, 0x06, 0x05, 0x00 },
                                              new byte[] { 0xFD, 0xFF, 0xFF, 0xFF }
                                            }
                                            },
                    { ".XLSX", new List<byte[]> { new byte[] { 0x50, 0x4B, 0x03, 0x04 } } },
                    { ".GIF", new List<byte[]> { new byte[] { 0x47, 0x49, 0x46, 0x38 } } }
                };

        public static bool IsValidFileExtension(string fileName, byte[] fileData, byte[] allowedChars)
        {
            if (string.IsNullOrEmpty(fileName) || fileData == null || fileData.Length == 0)
            {
                return false;
            }

            bool flag = false;
            string ext = Path.GetExtension(fileName);
            if (string.IsNullOrEmpty(ext))
            {
                return false;
            }

            ext = ext.ToUpperInvariant();

            if (ext.Equals(".TXT") || ext.Equals(".CSV") || ext.Equals(".PRN"))
            {
                foreach (byte b in fileData)
                {
                    if (b > 0x7F)
                    {
                        if (allowedChars != null)
                        {
                            if (!allowedChars.Contains(b))
                            {
                                return false;
                            }
                        }
                        else
                        {
                            return false;
                        }
                    }
                }

                return true;
            }

            if (!fileSignature.ContainsKey(ext))
            {
                return true;
            }

            List<byte[]> sig = fileSignature[ext];
            foreach (byte[] b in sig)
            {
                var curFileSig = new byte[b.Length];
                Array.Copy(fileData, curFileSig, b.Length);
                if (curFileSig.SequenceEqual(b))
                {
                    flag = true;
                    break;
                }
            }

            return flag;
        }

Győződjön meg arról, hogy a webalkalmazás típusbiztos paramétereket használ az adathozzáféréshez

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák Általános
Attribútumok n/a
Hivatkozások n/a
Lépések

Ha a Paraméterek gyűjteményt használja, az SQL a bemenetet nem végrehajtható kódként, hanem konstans értékként kezeli. A paraméterek gyűjteményével típus- és hosszkorlátozásokat kényszeríthet ki a bemeneti adatokra. A tartományon kívüli értékek kivételt váltanak ki. Ha nem használ típusbiztos SQL-paramétereket, előfordulhat, hogy a támadók képesek lesznek a szűretlen bemenetbe beágyazott injektálási támadásokat végrehajtani.

Az SQL-lekérdezések létrehozásakor használjon biztonságos típusparamétereket, hogy elkerülje a szűretlen bemenettel esetlegesen előforduló SQL-injektálási támadásokat. A biztonságos típusparamétereket tárolt eljárásokkal és dinamikus SQL-utasításokkal is használhatja. A paramétereket az adatbázis konstans értékként kezeli, nem pedig végrehajtható kódként. A paraméterek típusát és hosszát is ellenőrzi a rendszer.

Példa

Az alábbi kód bemutatja, hogyan használhat biztonságos típusparamétereket az SqlParameterCollection használatával tárolt eljárás meghívásakor.

using System.Data;
using System.Data.SqlClient;

using (SqlConnection connection = new SqlConnection(connectionString))
{ 
DataSet userDataset = new DataSet(); 
SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure", connection); 
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure; 
myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11); 
myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text; 
myCommand.Fill(userDataset);
}  

Az előző kód példában a bemeneti érték nem lehet hosszabb 11 karakternél. Ha az adatok nem felelnek meg a paraméter által meghatározott típusnak vagy hosszúságnak, az SqlParameter osztály kivételt okoz.

Az MVC tömeges hozzárendelési biztonsági résének elkerülése érdekében használjon külön modellkötési osztályokat vagy kötésszűrő-listákat

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák MVC5, MVC6
Attribútumok n/a
Hivatkozások Metaadat-attribútumok, nyilvános kulcs biztonsági rése és elhárítása, teljes útmutató a tömeges hozzárendeléshez ASP.NET MVC-ben, bevezetés az EF használatába az MVC használatával
Lépések
  • Mikor érdemes túlfelfedő biztonsági réseket keresni? - A túlzott közzétételi biztonsági rések minden olyan helyen előfordulhatnak, ahol a modellosztályokat a felhasználói bemenetből köti össze. Az MVC-hez hasonló keretrendszerek egyéni .NET-osztályok felhasználói adatait jelölhetik, beleértve az egyszerű régi CLR-objektumokat (POCO-kat). Az MVC automatikusan kitölti ezeket a modellosztályokat a kérésből származó adatokkal, így kényelmesen ábrázolja a felhasználói bemenetek kezelését. Ha ezek az osztályok olyan tulajdonságokat tartalmaznak, amelyeket a felhasználónak nem kell beállítania, az alkalmazás sebezhető lehet a túlzott közzétételi támadásokkal szemben, amelyek lehetővé teszik az alkalmazás által soha nem tervezett adatok felhasználói ellenőrzését. Az MVC-modell kötéséhez hasonlóan az adatbázis-hozzáférési technológiák, például az objektum-/relációs leképezők, például az Entity Framework is gyakran támogatják a POCO-objektumok használatát az adatbázisadatok megjelenítéséhez. Ezek az adatmodell-osztályok ugyanolyan kényelmesen kezelik az adatbázisadatokat, mint az MVC a felhasználói bemenetek kezelése során. Mivel az MVC és az adatbázis is támogatja a hasonló modelleket, például a POCO-objektumokat, úgy tűnik, hogy mindkét célra könnyen újra felhasználhatja ugyanazokat az osztályokat. Ez a gyakorlat nem őrzi meg az aggodalmak elkülönítését, és ez az egyik gyakori terület, ahol a nem szándékolt tulajdonságok ki vannak téve a modellkötésnek, ami lehetővé teszi a túlzott közzétételi támadásokat.
  • Miért nem használhatom a szűretlen adatbázismodell-osztályaimat paraméterként az MVC-műveletekhez? - Mivel az MVC-modell kötése az adott osztályban bármit megköt. Még akkor is, ha az adatok nem jelennek meg a nézetben, a rosszindulatú felhasználók http-kérést küldhetnek az adatokkal együtt, és az MVC örömmel köti azokat, mert a művelet szerint az adatbázisosztály azoknak az adatoknak az alakja, amelyeket el kell fogadnia a felhasználói bevitelhez.
  • Miért fontos a modellkötéshez használt alakzat? - Ha ASP.NET MVC-modellkötést használ túl széles modellekkel, az alkalmazás túlküldéses támadásokat tesz elérhetővé. A túlzott közzététel lehetővé teheti a támadók számára az alkalmazásadatok módosítását a fejlesztő szándéka felett, például egy elem árát vagy egy fiók biztonsági jogosultságainak felülbírálását. Az alkalmazásoknak műveletspecifikus kötési modelleket (vagy adott engedélyezett tulajdonságszűrő-listákat) kell használniuk ahhoz, hogy explicit szerződést adjanak arról, hogy milyen nem megbízható bemenet legyen engedélyezve a modellkötésen keresztül.
  • A különálló kötési modellek csak duplikálják a kódot? - Nem, az aggodalmak elkülönítéséről van szó. Ha a műveleti módszerekben újra felhasználja az adatbázismodelleket, azt mondja, hogy az osztály bármely tulajdonságát (vagy altulajdonságát) beállíthatja a felhasználó egy HTTP-kérésben. Ha nem ezt szeretné, akkor szűrőlistára vagy külön osztályalakzatra van szükség, hogy az MVC megjelenítse, hogy milyen adatok származhatnak a felhasználói bemenetből.
  • Ha külön kötési modellekkel rendelkezem a felhasználói bemenethez, meg kell duplikálnom az összes adatjegyzet-attribútumomat? - Nem feltétlenül. Az adatbázismodell-osztály MetadataTypeAttribute parancsával hivatkozhat a modellkötési osztály metaadataira. Vegye figyelembe, hogy a MetadataTypeAttribute által hivatkozott típusnak a hivatkozási típus részhalmazának kell lennie (kevesebb tulajdonsággal rendelkezhet, de nem több).
  • Az adatok oda-vissza mozgatása a felhasználói bemeneti modellek és az adatbázismodellek között fárasztó. Átmásolhatom az összes tulajdonságot tükröződés használatával? - Igen. A kötési modellekben csak azok a tulajdonságok jelennek meg, amelyekről úgy döntött, hogy biztonságos a felhasználói bevitelhez. Nincs olyan biztonsági ok, amely megakadályozza a tükröződés használatát a két modell között közösen létező összes tulajdonság másolásához.
  • Mi a helyzet [Bind(Exclude ="â €¦")]. Használhatom ezt ahelyett, hogy külön kötési modelleket használnék? - Ez a megközelítés nem ajánlott. A [Bind(Exclude ="â €¦")] használata azt jelenti, hogy minden új tulajdonság alapértelmezés szerint köthető. Ha új tulajdonságot ad hozzá, egy további lépést kell szem előtt tartania, hogy ne kelljen alapértelmezés szerint biztonságossá tenni a kialakítást. Attól függően, hogy a fejlesztő minden alkalommal ellenőrzi ezt a listát, amikor hozzáad egy tulajdonságot, kockázatos.
  • Hasznos a [Bind(Include ="â €¦")] a szerkesztési műveletekhez? - Szám A [Bind(Include ="â €¦")] csak INSERT stílusú műveletekhez (új adatok hozzáadásával) használható. AZ UPDATE-stílusú műveletekhez (a meglévő adatok felülvizsgálatához) használjon másik módszert, például külön kötési modelleket, vagy adjon át explicit listát az engedélyezett tulajdonságokról az UpdateModel vagy a TryUpdateModel számára. Ha hozzáad egy [Bind(Include ="â €¦")] attribútumot egy szerkesztési művelethez, az azt jelenti, hogy az MVC létrehoz egy objektumpéldányt, és csak a felsorolt tulajdonságokat állítja be, és az összes többit az alapértelmezett értékükön hagyja. Ha az adatok megmaradnak, az teljesen lecseréli a meglévő entitást, és visszaállítja a kihagyott tulajdonságok értékeit az alapértelmezett értékre. Ha például az IsAdmin nincs megadva egy szerkesztési művelet [Bind(Include ="â €¦")] attribútumából, minden felhasználó, akinek a nevét ezen a műveleten keresztül szerkesztette, visszaállítja az IsAdmin = hamis értékre (bármely szerkesztett felhasználó elveszíti a rendszergazdai státuszt). Ha meg szeretné akadályozni bizonyos tulajdonságok frissítését, használja a fenti módszerek egyikét. Vegye figyelembe, hogy az MVC-eszközök egyes verziói a [Bind(Include ="â €¦")] vezérlőosztályokat hoznak létre a szerkesztési műveleteken, és azt jelentik, hogy egy tulajdonság eltávolítása a listából megakadályozza a túlzott közzétételi támadásokat. A fentiekben leírtak szerint azonban ez a megközelítés nem a kívánt módon működik, és ehelyett a kihagyott tulajdonságokban lévő adatokat visszaállítja az alapértelmezett értékekre.
  • A létrehozási műveletek esetében vannak-e olyan kikötések, amelyek a [Bind(Include ="â €¦")]-t használják külön kötési modellek helyett? - Igen. Először is ez a megközelítés nem működik szerkesztési forgatókönyvekben, ezért két külön megközelítést kell fenntartani az összes túlzott közzétételi biztonsági rés enyhítéséhez. Másodszor, a különálló kötési modellek a felhasználói bemenethez használt alakzat és az adatmegőrzéshez használt alakzat közötti aggodalmak elkülönítését kényszerítik ki, a [Bind(Include ="â €¦")] nem működik. Harmadszor, vegye figyelembe, hogy a [Bind(Include ="â €¦")] csak a legfelső szintű tulajdonságokat tudja kezelni; Az attribútumban nem engedélyezheti csak az altulajdonságok egy részét (például "Details.Name"). Végül, és ami talán a legfontosabb, a [Bind(Include ="â €¦")] használatával hozzáad egy további lépést, amelyet minden alkalommal meg kell jegyezni, amikor az osztályt a modellkötéshez használják. Ha egy új műveletmetódus közvetlenül az adatosztályhoz kötődik, és elfelejt belefoglalni egy [Bind(Include ="â €¦")] attribútumot, az sebezhető lehet a túlzott közzétételi támadások ellen, ezért a [Bind(Include ="…")] megközelítés alapértelmezés szerint kevésbé biztonságos. Ha a [Bind(Include ="â €¦")]-t használja, mindig ügyeljen rá, hogy minden alkalommal meg kell adnia, amikor az adatosztályok műveletmetódus-paraméterekként jelennek meg.
  • A létrehozási műveletek esetében mi a helyzet a [Bind(Include ="â €¦")] attribútumnak a modellosztályra való helyezésével? Ez a megközelítés nem kerüli el, hogy ne felejtse el az attribútumot minden műveletmetódusra helyezni? - Ez a megközelítés bizonyos esetekben működik. A [Bind(Include ="â €¦")] használata magában a modelltípusban (az osztályt használó műveleti paraméterek helyett) nem szükséges minden műveletmetódushoz belefoglalni a [Bind(Include ="â €¦")] attribútumot. Az attribútum közvetlenül az osztályon való használatával hatékonyan létrehoz egy külön felületet ennek az osztálynak a modellkötési célokra. Ez a megközelítés azonban csak egy modellkötési alakzatot tesz lehetővé modellosztályonként. Ha egy műveletmetódusnak engedélyeznie kell egy mező modellkötését (például egy rendszergazda által csak a felhasználói szerepköröket frissíti), és más műveleteknek meg kell akadályoznia a mező modellkötését, ez a módszer nem fog működni. Minden osztály csak egy modellkötési alakzatot tartalmazhat; Ha a különböző műveleteknek eltérő modellkötési alakzatokra van szükségük, ezeket a különálló alakzatokat külön modellkötési osztályok vagy külön [Bind(Include ="â €¦")] attribútumokkal kell ábrázolniuk a műveleti módszereken.
  • Mik azok a kötési modellek? Ugyanazok, mint a modellek megtekintése? - Ez két kapcsolódó fogalom. A kötési modell kifejezés a művelet paraméterlistájában használt modellosztályra vonatkozik (az MVC-modell kötéséből a műveletmetódusnak átadott alakzatra). A kifejezésnézet-modell egy műveletmetódusból egy nézetbe átadott modellosztályra utal. A nézetspecifikus modell használata gyakori módszer az adatok műveletmetódusból nézetbe való továbbítására. Ez az alakzat gyakran modellkötésre is alkalmas, és a kifejezésnézeti modell használható arra, hogy ugyanazt a modellt használja mindkét helyen. Pontosabban ez az eljárás kifejezetten a kötési modellekről szól, a műveletnek átadott alakzatra összpontosítva, ami a tömeges hozzárendelés szempontjából fontos.

Nem megbízható webes kimenet kódolása a renderelés előtt

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák Általános, Webes űrlapok, MVC5, MVC6
Attribútumok n/a
Hivatkozások Helyek közötti szkriptelés megakadályozása ASP.NET, helyek közötti szkriptelés, XSS (helyek közötti szkriptelés) megelőzési csalilapon
Lépések A helyek közötti szkriptelés (általában XSS-ként rövidítve) egy támadási vektor online szolgáltatások vagy bármely olyan alkalmazás/összetevő számára, amely a webes bemenetet használja fel. Az XSS biztonsági rései lehetővé tehetik, hogy a támadó szkripteket hajthasson végre egy másik felhasználó gépén egy sebezhető webalkalmazáson keresztül. Rosszindulatú szkriptekkel ellophatja a cookie-kat, és egyéb módon módosíthatja az áldozat gépét JavaScript használatával. Az XSS-t megelőzi a felhasználói bemenet ellenőrzése, amely biztosítja, hogy megfelelően formázott és kódolású legyen, mielőtt megjelenítené azt egy weblapon. A bemeneti ellenőrzés és a kimeneti kódolás a Web Protection Library használatával végezhető el. Felügyelt kód (C#, VB.NET stb.) esetén használjon egy vagy több megfelelő kódolási módszert a Web Protection (Anti-XSS) kódtárból, attól függően, hogy a felhasználói bemenet milyen környezetben nyilvánul meg:

Példa

* Encoder.HtmlEncode 
* Encoder.HtmlAttributeEncode 
* Encoder.JavaScriptEncode 
* Encoder.UrlEncode
* Encoder.VisualBasicScriptEncode 
* Encoder.XmlEncode 
* Encoder.XmlAttributeEncode 
* Encoder.CssEncode 
* Encoder.LdapEncode 

Bemeneti ellenőrzés és szűrés végrehajtása az összes sztringtípus modelltulajdonságán

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák Általános, MVC5, MVC6
Attribútumok n/a
Hivatkozások Érvényesítés hozzáadása, modelladatok érvényesítése MVC-alkalmazásokban, a ASP.NET MVC-alkalmazások alapelvei
Lépések

Az összes bemeneti paramétert ellenőrizni kell, mielőtt az alkalmazásban használták őket, hogy az alkalmazás védve legyen a rosszindulatú felhasználói bemenetekkel szemben. Ellenőrizze a bemeneti értékeket a kiszolgálóoldali reguláris kifejezésérvényesítésekkel egy engedélyezett listaérvényesítési stratégiával. A metódusoknak átadott nem egyhangú felhasználói bemenetek/paraméterek kódinjektálási biztonsági réseket okozhatnak.

Webalkalmazások esetén a belépési pontok űrlapmezőket, QueryStrings-eket, cookie-kat, HTTP-fejléceket és webszolgáltatás-paramétereket is tartalmazhatnak.

A modellkötéskor a következő bemeneti ellenőrzési ellenőrzéseket kell elvégezni:

  • A modelltulajdonságokat RegularExpression jegyzetekkel kell eljegyezni az engedélyezett karakterek és a megengedett legnagyobb hossz elfogadásához
  • A vezérlő metódusainak a ModelState érvényességét kell végrehajtaniuk

A tisztítást olyan űrlapmezőkre kell alkalmazni, amelyek minden karaktert elfogadnak, például rich text editor

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák Általános
Attribútumok n/a
Hivatkozások Kódolás nem biztonságos bemenet, HTML-fertőtlenítő
Lépések

Azonosítsa az összes használni kívánt statikus korrektúracímkét. Gyakori eljárás a formázás biztonságos HTML-elemekre való korlátozása, például <b> (félkövér) és <i> (dőlt).

Az adatok írása előtt HTML-kódolást kell elvégeznie. Ez biztonságossá teszi a rosszindulatú szkripteket, mivel nem végrehajtható kódként, hanem szövegként kezeli.

  1. Tiltsa le ASP.NET kérésérvényesítést a ValidateRequest="false" attribútum @ Page direktívához való hozzáadásával
  2. A sztringbemenet kódolása a HtmlEncode metódussal
  3. Használjon StringBuildert, és hívja meg a Replace metódust a engedélyezni kívánt HTML-elemek kódolásának szelektív eltávolításához

A hivatkozások lapja letiltja ASP.NET kérések érvényesítését a beállítással ValidateRequest="false". Html-kódolja a bemenetet, és szelektíven engedélyezi a <b><i> .NET-kódtárat is a HTML-tisztításhoz.

A HtmlSanitizer egy .NET-kódtár a HTML-töredékek és dokumentumok XSS-támadásokhoz vezető szerkezetekből való tisztítására. Az AngleSharp használatával elemzi, manipulálja és rendereli a HTML-t és a CSS-t. A HtmlSanitizer NuGet-csomagként telepíthető, a felhasználói bemenet pedig a megfelelő HTML- vagy CSS-fertőtlenítő módszereken keresztül továbbítható a kiszolgálóoldalon. Vegye figyelembe, hogy a fertőtlenítés biztonsági vezérlőként csak az utolsó lehetőségnek tekinthető.

A bemeneti ellenőrzés és a kimeneti kódolás jobb biztonsági vezérlőknek minősül.

Ne rendeljen DOM-elemeket olyan fogadókhoz, amelyekhez nincs beépített kódolás

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák Általános
Attribútumok n/a
Hivatkozások n/a
Lépések Sok JavaScript-függvény alapértelmezés szerint nem végez kódolást. Ha nem megbízható bemenetet rendel a DOM-elemekhez az ilyen függvényeken keresztül, a helyek közötti szkriptek (XSS) végrehajtásához vezethetnek.

Példa

Az alábbiakban nem biztonságos példákat láthat:

document.getElementByID("div1").innerHtml = value;
$("#userName").html(res.Name);
return $('<div/>').html(value)
$('body').append(resHTML);   

Ne használja innerHtml; ehelyett használja innerText. Hasonlóképpen, ahelyett $("#elm").html(), hogy a $("#elm").text()

Ellenőrizze, hogy az alkalmazáson belüli összes átirányítás bezárva van-e vagy biztonságosan van-e végrehajtva

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák Általános
Attribútumok n/a
Hivatkozások Az OAuth 2.0 engedélyezési keretrendszere – Open Redirectors
Lépések

A felhasználó által megadott helyre való átirányítást igénylő alkalmazástervezésnek korlátoznia kell a lehetséges átirányítási célokat a webhelyek vagy tartományok előre definiált "biztonságos" listájára. Az alkalmazás minden átirányításának zárva/biztonságosnak kell lennie.

Megvalósítás:

  • Az összes átirányítás azonosítása
  • Minden átirányításhoz megfelelő kockázatcsökkentést kell végrehajtania. A megfelelő kockázatcsökkentések közé tartozik az átirányításra engedélyezett lista vagy a felhasználó megerősítése. Ha egy nyílt átirányítási biztonsági rést tartalmazó webhely vagy szolgáltatás Facebook/OAuth/OpenID identitásszolgáltatókat használ, a támadó ellophatja a felhasználó bejelentkezési jogkivonatát, és megszemélyesítheti a felhasználót. Ez eredendő kockázat az OAuth használatakor, amelyet az RFC 6749 "The OAuth 2.0 Authorization Framework" (OAuth 2.0 engedélyezési keretrendszer) 10.15"Open Redirects" szakaszában dokumentálunk. Hasonlóképpen, a felhasználók hitelesítő adatai is sérülhetnek a nyílt átirányítások használatával végrehajtott adathalász támadásokkal.

Bemeneti ellenőrzés implementálása a Vezérlő metódusok által elfogadott összes sztringtípus-paraméteren

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák Általános, MVC5, MVC6
Attribútumok n/a
Hivatkozások Modelladatok érvényesítése MVC-alkalmazásokban, a ASP.NET MVC-alkalmazások alapelvei
Lépések Az olyan metódusok esetében, amelyek csak primitív adattípust fogadnak el, és nem a modelleket argumentumként, a reguláris kifejezéssel végzett bemeneti ellenőrzést kell elvégezni. A Regex.IsMatch itt érvényes regex mintával használható. Ha a bemenet nem egyezik a megadott reguláris kifejezéssel, a vezérlő nem folytathat tovább, és megfelelő figyelmeztetést kell megjeleníteni az érvényesítési hibára vonatkozóan.

A normál kifejezésfeldolgozás felső korlátjának időtúllépésének beállítása, hogy megakadályozza a DoS-t a helytelen reguláris kifejezések miatt

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák Általános, Webes űrlapok, MVC5, MVC6
Attribútumok n/a
Hivatkozások DefaultRegexMatchTimeout tulajdonság
Lépések Annak érdekében, hogy a szolgáltatásmegtagadási támadások a rosszul létrehozott reguláris kifejezések ellen, amelyek sok visszakövetést okoznak, állítsa be a globális alapértelmezett időtúllépést. Ha a feldolgozási idő hosszabb ideig tart, mint a megadott felső korlát, időtúllépési kivételt eredményezne. Ha nincs konfigurálva semmi, az időtúllépés végtelen lenne.

Példa

Az alábbi konfiguráció például regexMatchTimeoutException értéket ad vissza, ha a feldolgozás több mint 5 másodpercet vesz igénybe:

<httpRuntime targetFramework="4.5" defaultRegexMatchTimeout="00:00:05" />

A Html.Raw használatának elkerülése Razor-nézetekben

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Létrehozás
Alkalmazható technológiák MVC5, MVC6
Attribútumok n/a
Hivatkozások n/a
Lépés ASP.NET WebPages (Razor) automatikus HTML-kódolást végez. A beágyazott kódfüggékekkel (@ blokkokkal) nyomtatott összes sztring automatikusan HTML-kódolású lesz. A metódus meghívásakor HtmlHelper.Raw azonban olyan korrektúrát ad vissza, amely nem HTML-kódolású. Ha Html.Raw() segédmetódust használ, a Razor által biztosított automatikus kódolási védelmet használja.

Példa

Az alábbiakban egy nem biztonságos példát mutatunk be:

<div class="form-group">
            @Html.Raw(Model.AccountConfirmText)
        </div>
        <div class="form-group">
            @Html.Raw(Model.PaymentConfirmText)
        </div>
</div>

Csak akkor használja Html.Raw() , ha korrektúrát kell megjelenítenie. Ez a metódus nem hajtja végre implicit módon a kimeneti kódolást. Más ASP.NET segítők használata, például: @Html.DisplayFor()

Ne használjon dinamikus lekérdezéseket tárolt eljárásokban

Cím Részletek
Komponens Adatbázis
SDL-fázis Létrehozás
Alkalmazható technológiák Általános
Attribútumok n/a
Hivatkozások n/a
Lépések

Az SQL-injektálási támadás kihasználja a bemeneti ellenőrzés biztonsági réseit, hogy tetszőleges parancsokat futtasson az adatbázisban. Ez akkor fordulhat elő, ha az alkalmazás bemenetet használ dinamikus SQL-utasítások létrehozására az adatbázis eléréséhez. Akkor is előfordulhat, ha a kód olyan tárolt eljárásokat használ, amelyek nyers felhasználói bemenetet tartalmazó sztringeket adnak át. Az SQL-injektálási támadással a támadó tetszőleges parancsokat hajthat végre az adatbázisban. Minden SQL-utasítást (beleértve a tárolt eljárások SQL-utasításait is) paraméteresen kell megadni. A paraméteres SQL-utasítások olyan karaktereket fogadnak el, amelyek speciális jelentéssel bírnak az SQL-hez (például egy idézőjelhez) probléma nélkül, mert erősen be vannak gépelve.

Példa

Az alábbiakban egy példa látható a nem biztonságos dinamikus tárolt eljárásra:

CREATE PROCEDURE [dbo].[uspGetProductsByCriteria]
(
  @productName nvarchar(200) = NULL,
  @startPrice float = NULL,
  @endPrice float = NULL
)
AS
 BEGIN
  DECLARE @sql nvarchar(max)
  SELECT @sql = ' SELECT ProductID, ProductName, Description, UnitPrice, ImagePath' +
       ' FROM dbo.Products WHERE 1 = 1 '
       PRINT @sql
  IF @productName IS NOT NULL
     SELECT @sql = @sql + ' AND ProductName LIKE ''%' + @productName + '%'''
  IF @startPrice IS NOT NULL
     SELECT @sql = @sql + ' AND UnitPrice > ''' + CONVERT(VARCHAR(10),@startPrice) + ''''
  IF @endPrice IS NOT NULL
     SELECT @sql = @sql + ' AND UnitPrice < ''' + CONVERT(VARCHAR(10),@endPrice) + ''''

  PRINT @sql
  EXEC(@sql)
 END

Példa

A következő tárolt eljárás biztonságosan implementálva van:

CREATE PROCEDURE [dbo].[uspGetProductsByCriteriaSecure]
(
             @productName nvarchar(200) = NULL,
             @startPrice float = NULL,
             @endPrice float = NULL
)
AS
       BEGIN
             SELECT ProductID, ProductName, Description, UnitPrice, ImagePath
             FROM dbo.Products where
             (@productName IS NULL or ProductName like '%'+ @productName +'%')
             AND
             (@startPrice IS NULL or UnitPrice > @startPrice)
             AND
             (@endPrice IS NULL or UnitPrice < @endPrice)         
       END

Győződjön meg arról, hogy a modell érvényesítése webes API-metódusokon történik

Cím Részletek
Komponens Webes API
SDL-fázis Létrehozás
Alkalmazható technológiák MVC5, MVC6
Attribútumok n/a
Hivatkozások Modellérvényesítés a ASP.NET Webes API-ban
Lépések Amikor egy ügyfél adatokat küld egy webes API-nak, a feldolgozás előtt kötelező ellenőrizni az adatokat. Azon ASP.NET webes API-k esetében, amelyek bemenetként fogadják el a modelleket, adatjegyzetekkel állítsa be a modell tulajdonságaira vonatkozó érvényesítési szabályokat.

Példa

A következő kód ugyanezt mutatja be:

using System.ComponentModel.DataAnnotations;

namespace MyApi.Models
{
    public class Product
    {
        public int Id { get; set; }
        [Required]
        [RegularExpression(@"^[a-zA-Z0-9]*$", ErrorMessage="Only alphanumeric characters are allowed.")]
        public string Name { get; set; }
        public decimal Price { get; set; }
        [Range(0, 999)]
        public double Weight { get; set; }
    }
}

Példa

Az API-vezérlők műveleti módszerében a modell érvényességét kifejezetten ellenőrizni kell az alábbiak szerint:

namespace MyApi.Controllers
{
    public class ProductsController : ApiController
    {
        public HttpResponseMessage Post(Product product)
        {
            if (ModelState.IsValid)
            {
                // Do something with the product (not shown).

                return new HttpResponseMessage(HttpStatusCode.OK);
            }
            else
            {
                return Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState);
            }
        }
    }
}

Bemeneti ellenőrzés implementálása a webes API-metódusok által elfogadott összes sztringtípus-paraméteren

Cím Részletek
Komponens Webes API
SDL-fázis Létrehozás
Alkalmazható technológiák Általános, MVC 5, MVC 6
Attribútumok n/a
Hivatkozások Modelladatok érvényesítése MVC-alkalmazásokban, a ASP.NET MVC-alkalmazások alapelvei
Lépések Az olyan metódusok esetében, amelyek csak primitív adattípust fogadnak el, és nem a modelleket argumentumként, a reguláris kifejezéssel végzett bemeneti ellenőrzést kell elvégezni. A Regex.IsMatch itt érvényes regex mintával használható. Ha a bemenet nem egyezik a megadott reguláris kifejezéssel, a vezérlő nem folytathat tovább, és megfelelő figyelmeztetést kell megjeleníteni az érvényesítési hibára vonatkozóan.

Győződjön meg arról, hogy a web API típusbiztos paramétereket használ az adathozzáféréshez

Cím Részletek
Komponens Webes API
SDL-fázis Létrehozás
Alkalmazható technológiák Általános
Attribútumok n/a
Hivatkozások n/a
Lépések

Ha a Paraméterek gyűjteményt használja, az SQL a bemenetet nem végrehajtható kódként, hanem konstans értékként kezeli. A paraméterek gyűjteményével típus- és hosszkorlátozásokat kényszeríthet ki a bemeneti adatokra. A tartományon kívüli értékek kivételt váltanak ki. Ha nem használ típusbiztos SQL-paramétereket, előfordulhat, hogy a támadók képesek lesznek a szűretlen bemenetbe beágyazott injektálási támadásokat végrehajtani.

Az SQL-lekérdezések létrehozásakor használjon biztonságos típusparamétereket, hogy elkerülje a szűretlen bemenettel esetlegesen előforduló SQL-injektálási támadásokat. A biztonságos típusparamétereket tárolt eljárásokkal és dinamikus SQL-utasításokkal is használhatja. A paramétereket az adatbázis konstans értékként kezeli, nem pedig végrehajtható kódként. A paraméterek típusát és hosszát is ellenőrzi a rendszer.

Példa

Az alábbi kód bemutatja, hogyan használhat biztonságos típusparamétereket az SqlParameterCollection használatával tárolt eljárás meghívásakor.

using System.Data;
using System.Data.SqlClient;

using (SqlConnection connection = new SqlConnection(connectionString))
{ 
DataSet userDataset = new DataSet(); 
SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure", connection); 
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure; 
myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11); 
myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text; 
myCommand.Fill(userDataset);
}  

Az előző kód példában a bemeneti érték nem lehet hosszabb 11 karakternél. Ha az adatok nem felelnek meg a paraméter által meghatározott típusnak vagy hosszúságnak, az SqlParameter osztály kivételt okoz.

Paraméteres SQL-lekérdezések használata az Azure Cosmos DB-hez

Cím Részletek
Komponens Azure Document DB
SDL-fázis Létrehozás
Alkalmazható technológiák Általános
Attribútumok n/a
Hivatkozások SQL-paraméterezés bejelentése az Azure Cosmos DB-ben
Lépések Bár az Azure Cosmos DB csak írásvédett lekérdezéseket támogat, az SQL-injektálás akkor is lehetséges, ha a lekérdezések a felhasználói bemenettel összefűzve jönnek létre. Előfordulhat, hogy a felhasználó rosszindulatú SQL-lekérdezések készítésével hozzáférést kap azokhoz az adatokhoz, amelyeket nem kellene ugyanabban a gyűjteményben elérnie. Paraméteres SQL-lekérdezéseket használjon, ha a lekérdezések felhasználói bemenet alapján vannak létrehozva.

WCF-bemenet érvényesítése sémakötéssel

Cím Részletek
Komponens WCF
SDL-fázis Létrehozás
Alkalmazható technológiák Általános, NET-keretrendszer 3
Attribútumok n/a
Hivatkozások MSDN
Lépések

Az ellenőrzés hiánya különböző típusú injektálási támadásokat eredményez.

Az üzenetérvényesítés egy védelmi vonalat jelöl a WCF-alkalmazás védelmében. Ezzel a módszerrel sémákkal ellenőrizheti az üzeneteket, hogy megvédje a WCF szolgáltatás műveleteit egy rosszindulatú ügyfél támadásaitól. Ellenőrizze az ügyfél által fogadott összes üzenetet, hogy megvédje az ügyfelet egy rosszindulatú szolgáltatás támadásától. Az üzenetérvényesítés lehetővé teszi az üzenetek érvényesítését, ha a műveletek üzenetszerződéseket vagy adatszerződéseket használnak, amelyeket nem lehet paraméterérvényesítéssel elvégezni. Az üzenetérvényesítés lehetővé teszi, hogy érvényesítési logikát hozzon létre a sémákban, ezáltal nagyobb rugalmasságot és a fejlesztési idő csökkentését. A sémák a szervezet különböző alkalmazásai között újra felhasználhatók, és szabványokat hozhatnak létre az adatreprezentációhoz. Emellett az üzenetérvényesítés lehetővé teszi a műveletek védelmét, ha összetettebb adattípusokat használnak, beleértve az üzleti logikát képviselő szerződéseket.

Az üzenetérvényesítés végrehajtásához először létre kell készítenie egy sémát, amely a szolgáltatás műveleteit és a műveletek által felhasznált adattípusokat jelöli. Ezután létre kell hoznia egy .NET-osztályt, amely egyéni ügyfélüzenet-felügyelőt és egyéni kézbesítőüzenet-felügyelőt implementál a szolgáltatásba/szolgáltatásból küldött/fogadott üzenetek ellenőrzéséhez. Ezután egy egyéni végponti viselkedést valósít meg, amely lehetővé teszi az üzenetek érvényesítését mind az ügyfélen, mind a szolgáltatáson. Végül implementálhat egy egyéni konfigurációs elemet az osztályon, amely lehetővé teszi a kiterjesztett egyéni végpont viselkedésének a szolgáltatás vagy az ügyfél konfigurációs fájljában való felfedésére"

WCF – Bemeneti ellenőrzés paramétervizsgálókon keresztül

Cím Részletek
Komponens WCF
SDL-fázis Létrehozás
Alkalmazható technológiák Általános, NET-keretrendszer 3
Attribútumok n/a
Hivatkozások MSDN
Lépések

A bemeneti és adatérvényesítés a WCF-alkalmazás védelmének egyik fontos védelmi vonalát képviseli. Ellenőrizze a WCF szolgáltatásműveletekben közzétett összes paramétert, hogy megvédje a szolgáltatást a rosszindulatú ügyfél támadásaitól. Ezzel szemben ellenőriznie kell az ügyfél által kapott összes visszatérési értéket is, hogy megvédje az ügyfelet a rosszindulatú szolgáltatás támadásaitól.

A WCF különböző bővíthetőségi pontokat biztosít, amelyek lehetővé teszik a WCF-futtatókörnyezet viselkedésének testreszabását egyéni bővítmények létrehozásával. Az üzenetfelügyelők és a paraméterfelügyelők két bővíthetőségi mechanizmust használnak az ügyfél és a szolgáltatás közötti adatátadás jobb szabályozására. A paraméterellenőrzőket csak akkor érdemes használni a bemeneti ellenőrzéshez, és csak akkor használja az üzenetfelügyelőket, ha meg kell vizsgálnia a szolgáltatásba be- és kifelé áramló teljes üzenetet.

A bemeneti ellenőrzés végrehajtásához létre kell készítenie egy .NET-osztályt, és implementálnia kell egy egyéni paraméterfelügyelőt, hogy érvényesítse a paramétereket a szolgáltatás műveletein. Ezután egyéni végponti viselkedést fog implementálni, amely lehetővé teszi az érvényesítést mind az ügyfélen, mind a szolgáltatáson. Végül implementálni fog egy egyéni konfigurációs elemet az osztályon, amely lehetővé teszi a kiterjesztett egyéni végpont viselkedésének a szolgáltatás vagy az ügyfél konfigurációs fájljában való felfedéséhez