I've seen this error before but cannot seem to get around it. In this case, I have an ASHX page spitting out a simple HTML form with a textbox into which XML may be posted. When I try to read the form, I receive the "A potentially dangerous Request.Form value...".
Since it's a generic handler the "ValidateRequest" attribute isn't available. However I already had this defined in web.config:
<location path="xml/MyGenericHandler.ashx">
<system.web>
<pages validateRequest="false" />
</system.web>
</location>
This snippet predates a move from .NET 3.5 to 4.0 so I'm guessing that's where the breakage originated.
Any idea how to get around this error for ASHX pages?
The 3.5-4.0 change that clipped you was some stepped up runtime security features for ASP.NET 4.0. The quick fix is to apply the following attribute:
<httpRuntime requestValidationMode="2.0" />
Unfortunately, that opens all pages up to 2.0 request validation, so I'd only do this if you've got a relatively small attack surface.
While not a direct answer to your question, I would say to read this previous post. it does give you a way to ensure that the error is not thrown. It's a risky way in one sense, because it means turning off a basic protection. However, the answer is well-reasoned, and the it clearly states that you should only implement it when you're absolutely sure you're encoding all output.
A potentially dangerous Request.Form value was detected from the client
As a side note, I would also recommend using the Microsoft Anti-Xss Library rather than the built in Server.HtmlEncode functions.
However, if you can modify the ashx, a simpler solution would be to just modify the error code and add an "if" statement to not log errors if the error message contains the string you want to filter.
You'd better disable validation for you handler page only:
<location path="MyGenericHandler.ashx">
<system.web>
<!-- requestValidationMode is to avoid HTML-validation of data posted to the handler -->
<httpRuntime requestValidationMode="2.0"/>
</system.web>
</location>
Or use this property from within your handler to avoid triggering the exception:
context.Request.Unvalidated.Form
Related
It looks like there is a bug in customErrors default redirect in web.config. In my web.config file I have the following customErrors setting
<customErrors defaultRedirect="~/generalerror.html?" mode="On" />
As far as I know this should send all errors to the custom generalerror.html page. It seems to work for some invalid URLS like
http://website.com/?x="<p>"
http://website.com/"<p>"
BUT it is not working when “&” is used in the URL and there is no “?” and there is an HTML tag. So this
http://website.com/&x="<p>"
totally ignores customErrors and you are given the default yellow Runtime Error instead of being sent to the custom generalerror.html page. How do I get this URL to also be redirected to the custom error page ?
If I turn mode="Off" in the web.config I get the following error
A potentially dangerous Request.RawUrl value was detected from the client (="/&x="<p>"").
Since you are passing HTML tags in the URL, it could be an indicative of cross-site scripting attack. Not all HTML tags are dangerous, but when HTML characters are followed by certain characters like '&' in your case, asp.net considers it as a cross-site scripting attack and doesn't allow it by default.
You should consider encoding the URL to get around this. And it is always a best practice. Here is a good explanation about XSS. And here is a link that explains in detail how to get around this issue.
To change this behavior, you can set request validation to false in web.config.
<configuration>
<system.web>
<pages validateRequest="false" />
</system.web>
</configuration>
But in this case, requests need to be validated in the pages.
Breaking changes were made to ASP.NET request validation in .NET 4.0 and this entry is required to revert the behavior to .NET 2.0 where invalid URLs will redirect to custom error page.
<httpRuntime requestValidationMode="2.0" />
First I got an exception : System.Web.HttpRequestValidationException (0x80004005): A potentially dangerous Request.Form value....
from searching the web I found that adding to my web.config :
<system.web>
<httpRuntime requestValidationMode="2.0" />
</system.web>
should solve the problem, but I get an error : requestValidationMode is not allowed.
I am using framework 3.5, maybe thats the reason... can someone help ?
In 3.5, you don't need the requestvalidationmode. To suppress asp.net validation on postback, just set the #Page parameter validaterequest="false" in the .aspx.
You need this if, for example, you are handling submitted HTML. You also then need to sanitize your input carefully.
I have a .NET 4 WCF service running as an IIS website with ASP.NET compatibility mode. Once of the service methods accepts a string parameter and when there is a value which contains a '&' the ASP.NET pipeline raises a validation exception. I've assigned the following config settings:
<system.web>
<httpRuntime requestValidationMode="2.0"/>
<pages validateRequest="false"/>
</system.web>
And the error persists. The error occurs regardless of whether the input is encoded. I found a potential solution here which suggests providing a custom implementation of System.Web.Util.RequestValidator, however I was wondering whether there are alternatives that can be done with configuration settings only.
EDIT:
I've also found this, however the proposed solution does not fix the problem.
I've found the solution. I set the following configuration setting:
<system.web>
<httpRuntime requestPathInvalidCharacters=""/>
</system.web>
By default, and ampersand is an invalid path character.
Some links that may help:
summary: MS is stating that you should use %26 if the ampersand appears in the query string.
http://connect.microsoft.com/wcf/feedback/details/527185/wcf-rest-uritemplate-does-not-recognise-or-amp-ampersand-as-same-character
summary: poster is talking about encoding the & in the body of the WCF message using &
XmlReader chopping off whitespace after ampersand entity?
So, if it's in the query string encode it with %26. If it's in the body of the message encode as an html entity: &
I am using freetextbox and have added to the web.config of my app but I still get the following error when submitting text with html:
A potentially dangerous Request.Form value was detected from the client (ctl00_MainContent_FreeTextBox1="
I know this is not the preferred way to set up an app but why am I getting these errors even though I have turned off request validation in my app?
The short answer is you shouldn't be getting such an error if you turned off Request Validation.
Did you do one of these two things correctly?
Disable on the page by inserting this at the top of the ASPX
Add the below section to your web.config.
<configuration>
<system.web>
<pages validateRequest="false" />
</system.web>
</configuration>
If that doesn't work then check the machine.config and see if the pages validaterequest value is set to true in there as that would override the web.config.
I had the same problem, and it was actually my fault. Maybe you have done the same mistake: I placed <httpRuntime requestValidationMode="2.0"/> inside
<configuration><location><system.web> instead of <configuration><system.web>.
Ensure that you haven't enabled request validation for this page. I would keep validation running for your site - but turn it off on pages where you need this control.
Be sure to sanitize anything that gets posted and be prudent about security.
I'm trying to put in an exception in my web.config so that one page does not require authentication. However, it still redirects to the login page.
The question isn't how to setup the web.config. Why? Our system (for better or worse) has a bunch of instrumentation besides the web.config. We have global.asax and custom HttpHandlers. The code base isn't huge, but there's a lot of potential causes for the redirect.
What I do want to know is how to best determine the cause of the redirect. Is there some way to find out what code triggered the redirect?
If you can debug the app, starting from HttpApplication.BeginRequest in global.asax and stepping through System.Web's reference source would be the brute force way.
Alternatively, set a breakpoint on HttpResponse.Redirect(string, bool) and follow the call stack - I doubt there's any other ways that the runtime uses to redirect a request.
If that doesn't turn anything up (or you can't debug), and since the brute force method is likely to lead through a lot of code - and it seems your problem is security related - you could probably just hook HttpApplication. AuthenticateRequest and HttpApplication. AuthorizeRequest, (and it's associated Post* events) and seeing what things look like there.
If you're using Forms Authentication, I happen to know that the FormsAuthenticationModule looks for a status code of 401 at HttpApplication.EndRequest to decide whether to redirect the request. Anything that sets 401 (access denied) will result in a redirect - not the 401 being returned to the browser.
When a request is made to an asp.net page requiring authentication, asp.net redirects to the specified login page with supplying a ReturnUrl querystring argument identifying the original requested page by default. While this ReturnUrl is configurable, if you have not modified the configuration, it's presence should indicate that authentication failed.
In this case, you should be focused on troubleshooting the authentication settings for the page. Gordon Bell's answer looks good for this.
<system.web>
...
</system.web>
<location path="NoAuthNeeded.aspx">
<system.web>
<authorization>
<allow roles="*" />
<allow roles="?" />
</authorization>
</system.web>
</location>
Also, if this is only happening in your production app, you might be able to find out what is going on using WinDBG. Loosely following this article you'd do the following:
Fire up WinDBG and attach to the w3wp process
WinDBG will breakpoint, so do a .loadby sos mscorwks which will load the SOS module
type sxe clr to breakpoint on CLR exceptions
type g to continue on
Now your app will break on any exception. Since Response.Redirect typically throws a ThreadAbortException it might be a simple way to break. Then do a !printexception to get the stack trace. You can also do a ~*e!clrstack if my WinDBG foo isn't failing me to see the managed stack for all the threads currently executing.
Note that you freeze the w3wp process while you are broken in, so be quick!
Hopefully you can use another method instead, but if all else fails, this might help you get started.
Have you tried turning on Tracing? That may help.
How are you specifying the page doesn't require authentication, like:
<system.web>
...
</system.web>
<location path="NoAuthNeeded.aspx">
<system.web>
<authorization>
<allow roles="*" />
<allow roles="?" />
</authorization>
</system.web>
</location>
Put a breakpoint at the beginning of each HTTP handler and notice which one is the last invoked handler before the redirect occurs. You will probably find the cause of the problem in that one.
You can use the following method to find a redirect in your own code:
Open the Exception Settings window and search for "threadabort". Check the checkbox for the ThreadAbortException. Now, when a redirect is executed from code, your debug session will enter break mode.
But since you are talking about the authentication in the web.config, it's highly likely that the issue is there, and not in the code.
Double-check that all the authorization elements like mentioned in HectorMac's answer are correct.