Číst v angličtině

Sdílet prostřednictvím


Zabezpečení LINQ to XML

Tento článek popisuje problémy se zabezpečením související s LINQ to XML a poskytuje pokyny pro zmírnění ohrožení zabezpečení.

Přehled zabezpečení LINQ to XML

LINQ to XML je navržený pro usnadnění programování než pro aplikace na straně serveru s přísnými požadavky na zabezpečení. Většina scénářů XML se skládá ze zpracování důvěryhodných dokumentů XML místo zpracování nedůvěryhodných dokumentů XML, které se nahrají na server. LINQ to XML je optimalizovaný pro tyto scénáře.

Pokud musíte zpracovat nedůvěryhodná data z neznámých zdrojů, Microsoft doporučuje použít instanci XmlReader třídy, která byla nakonfigurována k filtrování známých útoků DOS (XML Denial of Service).

Pokud jste nakonfigurovali XmlReader zmírnění útoků na odepření služeb, můžete pomocí této čtečky naplnit strom LINQ to XML a stále využívat vylepšení produktivity programátora LINQ to XML. Mnoho technik zmírnění rizik zahrnuje vytváření čtenářů, které jsou nakonfigurovány pro zmírnění problému se zabezpečením, a následné vytvoření instance stromu XML prostřednictvím nakonfigurované čtečky.

KÓD XML je vnitřně zranitelný vůči útokům na dostupnost služby, protože dokumenty jsou nevázané na velikost, hloubku, velikost názvu elementu a další. Bez ohledu na komponentu, kterou používáte ke zpracování XML, byste měli být vždy připraveni recyklovat doménu aplikace, pokud používá nadměrné prostředky.

Zmírnění útoků XML, XSD, XPath a XSLT

LINQ to XML je postaven na XmlReader a XmlWriter. LINQ to XML podporuje XSD a XPath prostřednictvím rozšiřujících metod v oborech System.Xml.Schema názvů a System.Xml.XPath oborů názvů. Pomocí XmlReader, XPathNavigatora XmlWriter třídy ve spojení s LINQ to XML můžete vyvolat XSLT transformovat stromy XML.

Pokud pracujete v méně zabezpečeném prostředí, existuje řada problémů se zabezpečením, které jsou přidružené k XML a použití tříd v System.Xml, System.Xml.Schema, System.Xml.XPatha System.Xml.Xsl. Mezi tyto problémy patří:

  • XSD, XPath a XSLT jsou jazyky založené na řetězcích, ve kterých můžete určit operace, které spotřebovávají hodně času nebo paměti. Je zodpovědností programátorů aplikací, kteří přebírají řetězce XSD, XPath nebo XSLT z nedůvěryhodných zdrojů, aby ověřili, že řetězce nejsou škodlivé, nebo monitorovat a zmírnit možnost, že vyhodnocení těchto řetězců povede k nadměrné spotřebě systémových prostředků.
  • Schémata XSD (včetně vložených schémat) jsou ze své podstaty zranitelná vůči útokům na odepření služeb; Neměli byste přijímat schémata z nedůvěryhodných zdrojů.
  • XSD a XSLT můžou zahrnovat odkazy na jiné soubory a tyto odkazy můžou vést k útokům mezi zónami a mezi doménami.
  • Externí entity v jednotkách DTD můžou vést k útokům napříč zónami a útoky mezi doménami.
  • DTD jsou zranitelné vůči útokům na odepření služeb.
  • Výjimečně hluboké dokumenty XML mohou představovat problémy s odepřením služeb; Možná budete chtít omezit hloubku dokumentů XML.
  • Nepřijme podpůrné komponenty, například NameTable, XmlNamespaceManagera XmlResolver objekty, z nedůvěryhodných sestavení.
  • Čtení dat v blocích za účelem zmírnění velkých útoků na dokumenty
  • Bloky skriptů v šablonách stylů XSLT můžou vystavit řadu útoků.
  • Před vytvořením dynamických výrazů XPath pečlivě ověřte.

Problémy se zabezpečením LINQ to XML

Problémy se zabezpečením v tomto článku nejsou uvedeny v žádném konkrétním pořadí. Všechny problémy jsou důležité a měly by být vyřešeny podle potřeby.

Úspěšný útok na zvýšení oprávnění dává škodlivému sestavení větší kontrolu nad jeho prostředím. Úspěšný útok na zvýšení oprávnění může vést k vyzrazení dat, odepření služby a další.

Aplikace by neměly zpřístupnit data uživatelům, kteří nemají oprávnění k jejich zobrazení.

Útoky na dostupnost služby způsobují, že analyzátor XML nebo LINQ to XML spotřebovávají nadměrné množství paměti nebo času procesoru. Útoky na dostupnost služby se považují za méně závažné než útoky na zvýšení oprávnění nebo zpřístupnění datových útoků. Jsou ale důležité ve scénáři, kdy server potřebuje zpracovat dokumenty XML z nedůvěryhodných zdrojů.

Nezpřístupňujte chybové zprávy nedůvěryhodným volajícím

Popis chyby může odhalit data, například transformovaná data, názvy souborů nebo podrobnosti implementace. Chybové zprávy by neměly být vystaveny volajícím, kteří nejsou důvěryhodní. Všechny chyby byste měli zachytit a hlásit chyby vlastními chybovými zprávami.

Nevolejte CodeAccessPermissions.Assert v obslužné rutině události.

Sestavení může mít menší nebo větší oprávnění. Sestavení, které má větší oprávnění, má větší kontrolu nad počítačem a jeho prostředím.

Pokud kód v sestavení s většími oprávněními volání CodeAccessPermission.Assert v obslužné rutině události a pak se strom XML předá škodlivému sestavení s omezenými oprávněními, může škodlivé sestavení způsobit vyvolání události. Vzhledem k tomu, že událost spouští kód, který je v sestavení s většími oprávněními, bude škodlivé sestavení fungovat se zvýšenými oprávněními.

Microsoft doporučuje, abyste nikdy nezavolali CodeAccessPermission.Assert obslužnou rutinu události.

Nepřijmutí DTD z nedůvěryhodných zdrojů

Entity v DTD nejsou ze své podstaty zabezpečené. Je možné, že dokument XML se zlými úmysly obsahující DTD způsobí, že analyzátor použije veškerou dobu paměti a procesoru, což způsobí útok na dostupnost služby. Proto v LINQ to XML je zpracování DTD ve výchozím nastavení vypnuto. DTD byste neměli přijímat z nedůvěryhodných zdrojů.

Jedním z příkladů přijetí DTD z nedůvěryhodných zdrojů je webová aplikace, která umožňuje webovým uživatelům nahrát soubor XML, který odkazuje na DTD a soubor DTD. Po ověření souboru může útok DTD se zlými úmysly na váš server spustit útok na dostupnost služby. Dalším příkladem přijetí DTD z nedůvěryhodných zdrojů je odkazování na DTD ve sdílené síťové složce, která také umožňuje anonymní přístup FTP.

Vyhněte se nadměrnému přidělování vyrovnávací paměti

Vývojáři aplikací by měli vědět, že extrémně velké zdroje dat můžou vést k vyčerpání prostředků a útokům na dostupnost služby.

Pokud uživatel se zlými úmysly odešle nebo nahraje velmi velký dokument XML, může to způsobit, že LINQ to XML spotřebuje nadměrné systémové prostředky. To může představovat útok na dostupnost služby. Chcete-li tomu zabránit, můžete nastavit XmlReaderSettings.MaxCharactersInDocument vlastnost a vytvořit čtenáře, který je pak omezen velikostí dokumentu, který může načíst. Pak pomocí čtečky vytvoříte strom XML.

Pokud například víte, že maximální očekávaná velikost dokumentů XML pocházejících z nedůvěryhodného zdroje bude menší než 50 bajtů, nastavená XmlReaderSettings.MaxCharactersInDocument na 100 000. Nebude to zahltit zpracování dokumentů XML a zároveň se zmírní hrozby v odepření služeb, kdy se můžou nahrávat dokumenty, které spotřebovávají velké množství paměti.

Vyhněte se nadbytečnému rozšíření entity

Jedním ze známých útoků na dostupnost služby při použití DTD je dokument, který způsobuje nadměrné rozšíření entit. Chcete-li tomu zabránit, můžete nastavit XmlReaderSettings.MaxCharactersFromEntities vlastnost a vytvořit čtenáře, který je pak omezen počtem znaků, které jsou výsledkem rozšíření entity. Pak pomocí čtečky vytvoříte strom XML.

Omezení hloubky hierarchie XML

Jedním z možných útoků na dostupnost služby je odeslání dokumentu s nadměrnou hloubkou hierarchie. Chcete-li tomu zabránit, můžete zabalit do XmlReader vlastní třídy, která spočítá hloubku prvků. Pokud hloubka překročí předem stanovenou rozumnou úroveň, můžete zpracování škodlivého dokumentu ukončit.

Ochrana před nedůvěryhodnými implementacemi XmlReader nebo XmlWriter

Správa istrátory by měly ověřit, že všechny externě zadané XmlReader nebo XmlWriter implementace mají silné názvy a byly zaregistrovány v konfiguraci počítače. Tím zabráníte načtení škodlivého kódu jako čtečky nebo zapisovače.

Pravidelně bezplatné objekty, které odkazují na XName

Kvůli ochraně před určitými druhy útoků by programátoři aplikací měli uvolnit všechny objekty, které odkazují na XName objekt v doméně aplikace pravidelně.

Ochrana před náhodnými názvy XML

Aplikace, které přebírají data z nedůvěryhodných zdrojů, by měly zvážit použití XmlReader zabalené ve vlastním kódu ke kontrole možnosti náhodných názvů a oborů názvů XML. Pokud jsou zjištěny takové náhodné názvy XML a obory názvů, aplikace může ukončit zpracování škodlivého dokumentu.

Počet názvů v libovolném oboru názvů (včetně názvů v žádném oboru názvů) můžete omezit na rozumný limit.

Serializace objektů LINQ to XML do textu XML před předáním dat do nedůvěryhodné komponenty

LINQ to XML se dá použít k vytváření kanálů zpracování, ve kterých se různé komponenty aplikace načítají, ověřují, dotazují, transformují, aktualizují a ukládají data XML, která se předávají mezi komponentami jako stromy XML. To může pomoct optimalizovat výkon, protože režie při načítání a serializaci objektů do textu XML se provádí pouze na koncích kanálu. Vývojáři ale musí vědět, že všechny poznámky a obslužné rutiny událostí vytvořené jednou komponentou jsou přístupné pro jiné komponenty. To může vytvořit řadu ohrožení zabezpečení, pokud mají komponenty různé úrovně důvěryhodnosti. Chcete-li vytvořit zabezpečené kanály napříč méně důvěryhodnými komponentami, musíte před předáním dat nedůvěryhodné komponentě serializovat objekty LINQ to XML do textu XML.

Některé zabezpečení poskytuje modul CLR (Common Language Runtime). Například komponenta, která neobsahuje soukromou třídu, nemá přístup k poznámkám, které tato třída obsahuje. Poznámky ale můžou být odstraněny komponentami, které je nemůžou číst. Může se použít jako útok na manipulaci.

Viz také