# Säkerhet genom mångfald - varför jag inte gillar ValidateRequest Jag är medveten om att detta är en [Rätt kontroversiellt synsätt](http://weblogs.asp.net/ShankuN/archive/2004/03/02/82534.aspx), Jag borde förklara några av min egen bakgrund som en föregångare till min ogillande av detta. På den dåliga gamla tiden, Jag var en penetration tester; Jag drev min egen lilla företag som gav denna tjänst till ett antal kunder, mitt jobb var att i huvudsak spricka / på andra sätt bryta webbplatser och "andra" nätverk. På min tid som en penntestare, en av de mest irriterande saker var brister som kunde påverka ett stort antal webbplatser / installationer på samma gång, klassiker var Cisco lösenord brister, Perl och PHP säkerhetsbrister och, värst av allt, bakdörrar i Web Applications. Så, som tiden har gått och jag flyttade mer till faktiskt skriva ansökningar snarare än att bryta dem har jag alltid varit medveten om att program säkerhetssystem inte bör i sig litas, medan mindre sannolikt att vara defekt än någon ad-hoc genomförande, kan den bristen vara potentiellt allvarligare eftersom det är nästan säkert att bli allmänt känt och utnyttjas inom en mycket kort tid. Det är en del av problemet jag har med ValidateRequest, det ger en krycka, en genväg för lat utvecklare. OK, det är användbart, det blockerar alla inkommande "html" som begäran information - och kommer därför att blockera många XSS (Cross Site Scripting) attacker som kan vara ganska allvarliga. Problemet är, [Man har redan funnit brister i detta](http://weblogs.asp.net/gad/archive/2003/11/12/37219.aspx) och plåstret är inte uppenbart / lätt att hitta (hade du hört talas om det tidigare?) - så det finns inte ett problem som kommer att påverka ALL ASP.NET 1.1 webbplatser som förlitar sig på denna funktion för att skydda dem från XSS attacker. Ännu värre, hur många webbplatser tror du kommer att vidta ytterligare försiktighetsåtgärder utöver detta för att skydda sin ingång - vet du om det skyddar dig från [SQL- injektionsattacker](http://www.developer.com/db/article.php/2243461), [Buffertöverflödesattacker](http://nts.jhu.edu/alerts/alert.detail.cfm?aid=218) och diverse andra (inklusive ädelstenar som enkla bakdörrar, [Kakkapning](http://www.experts-exchange.com/Security/Q_20851738.html) och liknande). Min poäng är, enligt min mening, att ansvaret för applikationssäkerhet bör ligga hos utvecklaren - de bör förstå och planera för konsekvenserna av val de gör i applikationsdesign. Läs en bok som [Michael Howard skriver säker kod](http://www.amazon.co.uk/exec/obidos/ASIN/0735617228/mostlylucid-21) [[Förenta staterna](http://www.amazon.com/exec/obidos/ASIN/0735617228/mostlylucid-21)] - få veta var sårbarheterna i din ansökan kan ligga och kompensera för dem. Kort sagt, lita inte på saker som ValidateRequest som din enda försvarslinje - använd den med alla medel, det kommer att stoppa många saker som du kanske inte vill ha - men lär dig [vad den faktiskt gör](http://weblogs.asp.net/vga/archive/2003/05/02/6329.aspx) Och vad det inte gör. Till exempel, vad kommer du att göra när du bara vill att vissa taggar att komma igenom och inte andra? Du kan behöva titta på [Nåt sånt här.](/uploads/HtmlTagRemover.zip)(Jag skrev detta för ett tag sedan - jag påstår inte att det är helt eller delvis idiotsäker - bara bevis på ett koncept). Hur som helst är åsikterna alltid välkomna - hur mycket tillämpningssäkerhet bör du delegera till ramen - har någon annan kommit på sina egna små "säkerhetsleksaker" som de använder för att validera användarinmatning? UPPDATERING: Glömt att nämna, om du fortfarande är på IIS 5.0 se till att kolla in [IISLockdown](http://www.microsoft.com/windows2000/downloads/recommended/iislockdown/default.asp) - du MÅSTE ha detta installerat, det kommer att hjälpa dig att undvika ett stort antal säkerhetshål, känd / framtid ... om du har IIS 6.0 , det är redan där men vara säker på att [Kolla in det här.](http://weblogs.asp.net/lbarbieri/archive/2003/10/06/30678.aspx) för att undvika utvecklingsproblem...