Ik ben me ervan bewust dat dit een nogal controversieel standpunt, Ik moet uitleggen een aantal van mijn eigen achtergrond als een voorloper van mijn afkeer van dit. In de slechte oude dagen, Ik was een penetratie tester; Ik liep mijn eigen kleine bedrijf dat deze dienst aan een aantal klanten, mijn taak was om in wezen te kraken / op andere manieren breken websites en 'andere' netwerken. In mijn tijd als een pen tester, een van de meest vervelende dingen was gebreken die een groot aantal sites / installaties op hetzelfde moment kunnen effect hebben, klassiekers waren Cisco wachtwoord gebreken, Perl en PHP beveiligingsfouten en, het ergste van alle, backdoors in Web Applications. Naarmate de tijd vordert en ik meer in het eigenlijk schrijven van applicaties verhuisde in plaats van ze te breken, ben ik me er altijd van bewust geweest dat applicatiebeveiligingssystemen niet inherent vertrouwd zouden moeten zijn, terwijl het minder waarschijnlijk is dat ze gebrekkig zijn dan een of andere ad-hoc implementatie, die fout kan potentieel ernstiger zijn omdat het vrijwel zeker is dat ze binnen een zeer korte tijd op grote schaal bekend en geëxploiteerd zullen worden. Dat is een deel van het probleem dat ik heb met ValidateRequest, het biedt een kruk, een snelkoppeling voor de luie ontwikkelaar. OK, het is handig, het blokkeert elke binnenkomende 'html' zoals aanvraag informatie - en zal daarom blokkeren veel XSS (Cross Site Scripting) aanvallen die vrij ernstig kunnen zijn. Probleem is, Er zijn al gebreken gevonden in deze en de patch is niet voor de hand liggend / gemakkelijk te vinden (had je er eerder van gehoord?) - dus er is geen probleem dat effect zal hebben ALLE ASP.NET 1.1 sites die vertrouwen op deze functie om ze te beschermen tegen XSS-aanvallen. Nog erger, hoeveel sites denk je dat extra voorzorgsmaatregelen zal nemen over en boven dit om hun invoer te beschermen - weet je of het beschermt u tegen SQL Injectieaanvallen, Buffer Overflow aanvallen en diverse andere (met inbegrip van edelstenen als eenvoudige achterdeur, Cookie kaping en dergelijke).

Mijn punt is, naar mijn mening, verantwoordelijkheid voor applicatiebeveiliging moet liggen bij de ontwikkelaar - ze moeten begrijpen en plannen voor de gevolgen van keuzes die ze maken in de toepassingsontwerp. Lees een boek als Michael Howard schrijft Secure Code [VS] - krijgen om te weten waar de kwetsbaarheden in uw aanvraag kan liggen en compenseren voor hen. Kortom, vertrouw niet op dingen als ValidateRequest als uw enige verdedigingslijn - gebruik het met alle middelen, het zal stoppen veel dingen te krijgen waardoor je misschien niet wilt - maar leren wat het eigenlijk doet En wat het niet doet.

Bijvoorbeeld, wat ga je doen als je alleen wilt dat bepaalde tags te krijgen door en niet anderen? Je kan nodig hebben om te kijken naar Zoiets als dit.(Ik schreef dit een tijdje geleden - ik zeg niet dat het geheel of zelfs gedeeltelijk waterdicht is - gewoon bewijs van een concept).

Hoe dan ook, meningen altijd welkom - hoeveel applicatiebeveiliging moet u delegeren aan het kader - heeft iemand anders bedacht met hun eigen kleine 'veiligheid' speelgoed dat ze gebruiken om gebruikersinvoer te valideren?

UPDATE: Vergeet te vermelden, als je nog steeds op IIS 5.0 zeker om uit te checken IISLockdown - u MOET dit geïnstalleerd hebben, het zal u helpen voorkomen dat een groot aantal beveiligingsgaten, bekend / toekomst...als u IIS 6.0 hebt, het is er al, maar zorg ervoor dat Moet je dit zien. om eventuele ontwikkelingsproblemen te vermijden...