Friends I am in trouble and need your help.
For database management in the admin section of my website I have few text fields where I would like to input data along with HTML tags.
As soon as i add any HTML tag such as < BR /> the SQLDATASOURCE Update gives an error "A potentially dangerous Request.Form value was detected from the client"
Already tried ValidateRequest="false" but it didnt work
Can not use AJAX Editor due to space issue.
<httpRuntime requestValidationMode="2.0" />
If i use httpRuntime requestValidationMode then it disable validation on the whole website making it open for hackers.
Friends how can i disable ValidateRequest only for specific page(s) in the admin section only
In .Net Framework 4.0, if you set requestValidationMode="2.0" in web.config, it doesn't means the whole site be will disabled for validation. It just changed back to 2.0 validation mode which validate only for .aspx pages. So you can apply validateRequest page driective attribute to false for the pages you want to disable after setting to 2.0 mode.
MSDN: requestValidationMode=2.0. Request validation is enabled only for pages, not for all HTTP requests. In addition, the request validation settings of the pages element (if any) in the configuration file or of the # Page directive in an individual page are used to determine which page requests to validate.
You can set an attribute on your controller methods or controller to disable the validationRequest
[ConfigurationPropertyAttribute("validateRequest", DefaultValue= false)]
You are missing the ValidateRequest="false" in your page directive
Related
We've just upgraded to ASP.NET 4.0, and found that requestValidation no longer works. The MSDN docs suggest we need to set requestValidationMode in web.config to 2.0:
4.0 (the default). The HttpRequest object internally sets a flag that indicates that request validation should be triggered whenever
any HTTP request data is accessed. This guarantees that the request
validation is triggered before data such as cookies and URLs are
accessed during the request. The request validation settings of the
pages element (if any) in the configuration file or of the # Page
directive in an individual page are ignored.
2.0. Request validation is enabled only for pages, not for all HTTP requests. In addition, the request validation settings of the pages
element (if any) in the configuration file or of the # Page directive
in an individual page are used to determine which page requests to
validate.
This will work for us, however I'm a little puzzled. It seems that we're putting this into a legacy/compatibility mode. Surely it should be possible to have the 4.0 behaviour, but still have an option to turn this off on a page?
I found a way to achieve this without changing RequestValidationMode to 2.0 to the whole site:
You can crate a sub-directory for the page you want to disable the request validation and add a new web.config to this directory with RequestValidationMode set to 2.0, this way only this directory will work in 2.0 mode without affecting all other requests that will work in 4.0 mode.
I think you can add an location section to your main web.config specifying only one page, but I didn't tested this yet.
Something like this:
<location path="Admin/Translation.aspx">
<system.web>
<httpRuntime requestValidationMode="2.0"/>
</system.web>
</location>
Hope it helps you as helped me !
Your best bet is to override the requestValidationType with your own code:
<httpRuntime requestValidationType="YourNamespace.YourValidator" />
MSDN link
It appears that it is not possible to turn this on or off for a page in requestValidationMode 4.0.
This whitepaper outlines breaking changes in .Net 4.0, of which this seems to be one. Even the whitepaper suggests reverting back to requestValidationMode 2.0
To revert to the behavior of the ASP.NET 2.0 request validation feature, add the following setting in the Web.config file:
<httpRuntime requestValidationMode="2.0" />
Although it also helpfully recommends
that you analyze any request validation errors to determine whether existing handlers, modules, or other custom code accesses potentially unsafe HTTP inputs that could be XSS attack vectors.
without giving any guidance on how best to resolve these issues
Set requestValidationMode="0.0" to disable ASP.NET pages and HTTP requests validation.
Value 0.0 recognized in ASP.NET 4.6 and later. MSDN
<configuration>
<system.web>
<httpRuntime requestValidationMode="0.0" />
You can set ValidateRequest to false in the page directive:
<%# Page ValidateRequest="false" %>
I use Asp.Net 4 and C#.
I would like to know how to change the default beahviour of Asp.Net customErrors.
In my Web.Config file I use this settings.
<customErrors mode="On" defaultRedirect="/ErrorPages/Oops.aspx">
<error statusCode="404" redirect="/ErrorPages/404.aspx" />
</customErrors>
As you can expect if a page is not found a redirect occur to the custom page specified in Web.Config.
Requested page:
http://localhost:1372/nopagehere
Result page:
http://localhost:1372/ErrorPages/404.aspx?aspxerrorpath=/nopagehere
When I analyse the Http Header for the Result page I can see:
a 404 Status when the page is not found
a 302 Status for the new created url
I would like change this behavior in this way:
when a request to a not found page has been made http://localhost:1372/nopagehere
the result should be only http://localhost:1372/nopagehere (no 302 redirect) and with status code only on 404.
Any idea how to do it? Thanks for your time on this.
I guess you are looking for the redirectMode attribute on your <customErrors> section.
See: http://msdn.microsoft.com/en-us/library/h0hfz6fc.aspx
I think you want to set it to redirectMode="ResponseRewrite". This throws a 404 and shows the content of your 404 page, but without redirecting to the actual 404 page.
Maybe removing the status code 404 from the custom errors and let the default redirect page handle it.
I use Asp.net 4.
Here setting for my Web.Config file.
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="/ErrorPages/Oops.aspx">
<error statusCode="404" redirect="/ErrorPages/404.aspx" />
</customErrors>
I need to apply the defaultRedirect url for any Exception, and use the redirectMode="ResponseRewrite" for only Page Not Found 404.
With this setting at the moment I can manage properly the Page Not Found (I'm able to get the 404.aspx page) but if an exception arise on any other page I get the "Internet Explorer cannot display the webpage" and I'm not able to reach the defaultRedirect Oops.aspx.
What I'm doing here wrong?
One problem with having an aspx page as the target of a custom errors redirect is that errors that aren't specific to a page (e.g. errors in global.asax; errors processing web.config) will also be thrown by the target page, which can result in an infinite redirect loop.
For this reason, it's often better to have a static html page as the target of at least the defaultRedirect.
Try putting the ~ in the redirect URL.
redirect="~/ErrorPages/404.aspx"
How many bytes is the error page content and does it set an HTTP status code other than 200 OK? In Internet Explorer with "Show friendly HTTP error messages" on, which is the default, custom error pages that have content under 512 bytes in length will be suppressed by the IE browser and replaced with the "friendly" error message.
To see if this is your problem, you can try turning off the "Show friendly HTTP error messages" option under Tools, Internet Options, Advanced, Settings. It'll be under the Browsing category in the Settings area.
If the page shows up with the option turned off, try turning it back on and changing your page to add an image or some other element that will make the size over 512 bytes long.
we've modified our customErrors section to protect against the recent ASP.NET vulnerability.
Our problem is, that HttpRequestValidationException's are now causing a YSOD's to be shown, other exceptions and page not found errors are showing our custom error page.
If we change the redirectMode to ResponseRedirect everything works fine.
This is our modified section:
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/Error.aspx"/>
This question has nothing to do with the recent ASP.NET vulnerability!It's about the ResponseRewrite redirectMode in combination with HttpRequestValidationException's. We know there will soon be a patch and that we could change back to ResponseRedirect.
Kind regards, Martin
This happens when your error page generates an error.
Make sure you turn off request validation on your error page. <%# Page ValidateRequest="false" %>
You then of course need to encode any user input that displays on your error page. eg. Server.HtmlEncode(ex.Message)
Running the ASP.NET webforms run the application works fine. When the application is idle for 4 to 5 minutes, it is giving this error:
Validation of viewstate MAC failed. If
this application is hosted by a Web
Farm or cluster, ensure that
configuration specifies
the same validationKey and validation
algorithm. AutoGenerate cannot be used
in a cluster.
How can this be solved?
This free online tool: http://aspnetresources.com/tools/machineKey generates a machineKey element under the system.web element in the web.config file.
Here is an example of what it generates:
<machineKey validationKey="1619AB2FDEE6B943AD5D31DD68B7EBDAB32682A5891481D9403A6A55C4F91A340131CB4F4AD26A686DF5911A6C05CAC89307663656B62BE304EA66605156E9B5" decryptionKey="C9D165260E6A697B2993D45E05BD64386445DE01031B790A60F229F6A2656ECF" validation="SHA1" decryption="AES" />
Once you see this in your web.config, the error itself suddenly makes sense.
The error you are getting says
"ensure that configuration specifies the same
validationKey and validation algorithm".
When you look at this machineKey element, suddenly you can see what it is talking about.
Modifying the pages element under the system.web element may not be necessary with this in place. This avoids the security problems associated with those attributes.
By "hard coding" this value in your web.config, the key that asp.net uses to serialize and deserialize your viewstate stays the same, no matter which server in a server farm picks it up. Your encryption becomes "portable", thus your viewstate becomes "portable".
I'm just guessing also that maybe the very same server (not in a farm) has this problem if for any reason it "forgets" the key it had, due to a reset on any level that wipes it out. That is perhaps why you see this error after an idle period and you try to use a "stale" page.
See http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate-mac-failed-error.aspx
This isn't your problem but it might help someone else. Make sure you are posting back to the same page. Check the action on your form tag and look at the URL your browser is requesting using Firefox Live HTTP Headers.
I ran into this because I was posting back to a page with the same name but a different path.
Modify your web.config with this element:
<pages validateRequest="false"
enableEventValidation="false"
viewStateEncryptionMode ="Never" />
Any more info required, refer to the ASP.NET Forums topic