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" %>
Related
ASP.NET MVC application, target framework: .NET Framework 4.7.2
Pretty old project with a bunch of legacy code.
Web.config file in Views folder contains the following part:
<system.web>
<!--
Enabling request validation in view pages would cause validation to occur
after the input has already been processed by the controller. By default
MVC performs request validation before a controller processes the input.
To change this behavior apply the ValidateInputAttribute to a
controller or action.
-->
<pages validateRequest="false" />
</system.web>
This part had been autogenerated upon the project creation several years ago.
If to create an ASP.NET MVC project for .NET Framework 4.7.2 now, then the Web.config will miss the above autogenerated part.
Do we still need this pages element and validateRequest="false" attribute?
Or in some point on the way from the WebPages to the MVC for .NET Framework 4.7.2 there were breaking changes that canceled the need of this setting?
MVC will prevent against potentially dangerous requests by default.
To post any sort of script or HTML you need to add either:
1 - The ValidateInput attribute on a controller action method
[ValidateInput(false)]
public ActionResult AddEntry(MyModel model) {
:
}
2 - The AllowHtml attribute on a model property
public class MyModel
{
[AllowHtml]
public string HtmlContent { get; set; }
}
The Pages Section of the Web Config is a WebForms thing
"Directives [in the pages element] specify settings used by the page and user-control compilers when they process ASP.NET Web Forms page (.aspx) and user control (.ascx) files." see (here)
<pages validateRequest="false" />
Is a left over from WebForms and is no longer needed by an MVC application.
So because MVC does not use any of that it is now irrelevant. Unless of course your application contains a mix of MVC and Webforms logic.
Bottom Line
Ideally you should never set validateRequest to false when using WebForms, or use AllowHtml or ValidateInput(false) in an MVC app because all three open security vulnerabilities in your code.
So should you remove it? Yes. It should probably not have been there in the first place.
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
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
We have a web application where we are using global.asax for url rewriting. We use a compiled version of the site on the live server.
As a part of modification request, we had to add some custom native AJAX code where javascript would call a webservice to update the content of the page. For being able to call the webservice with extension .asmx, we modified the url rewriting code to handle asmx requests seperately.
this arrangement works fine on the local machine, but when we publish the site and deploy it on the live server, the new code doesnt seem to get included. It still skips the condition to check the ".asmx" extension, and throws a page not found exception considering the webservice name as a page name.
We have tried looking all over and googled for such things as well.. but no avail..
any pointers on what might be going wrong.. ?
Assuming your URL rewriting is good (isn't that normally implemented as a HttpModule?) I'd check to make sure that there's an ISAPI mapping in IIS on production that sends .asmx requests to ASP.NET.
If you think your changes to the global.asax haven't been rejitted then you can always stop the application pool, go find your web applications compiled bits in c:\windows\microsoft.net\framework[version]\temporary asp.net files... and delete the jitted version. I've seen ASP.NET miss when it comes to Jitting changes before.
I'd also consider running http fiddler (IE) or tamper data (FireFox extension) on one of the pages that makes calls to the web service. It will tell you exactly how the page is calling the web service and you can validate that the called URL is correct.
There is machine.config file where you can add HttpModules. I also think that you can do that through web.config.
One reason I can think of is that in the Web.config, you might have configured the routing module in the system.web section but not in system.webServer (or at least forgot something in there).
I the similar problem before and the solution was to remove the module & add it again in the system.webServer section of the Web.config like this:
<system.webServer>
<modules>
<remove name="UrlRoutingModule" />
<add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, e="RoleManager" type="System.Web.Security.RoleManagerModule"/>
</modules>
</system.webServer>
It might be a different module or handler but the idea is basically the same. It's important to "remove" the module first.
I am using ASP.NET C#.
How do I implement URL re-writing procedure that is similar to StackOverflow.com?
http://stackoverflow.com/questions/358630/how-to-search-date-in-sql
Also, what is the meaning of values such as "358630" in the URL? Is this the question ID (the basis for which they use to fetch the data from the table)? Whatever it is, in my application I am identifying records using an "ID" field. This field is an identity column in an SQL table. Right now, my URLs are like the following:
http://myweb.com/showdetails.aspx?id=9872
But I'd like them to appear like:
http://myweb.com/showdetails/9872/my_question_title
Or:
http://myweb.com/9872/my_question_title
Or whatever the best way, which will taste good to search bots.
My application is hosted on Go Daddy's shared hosting service, and I feel that no customized ASP.NET "HTTP module" or no customized DLL for URL re-writing is working on their server. I tried many samples but no luck yet!
I found that Stack Overflow is hosted on Go Daddy (shared hosting?). Maybe Stack Overflow's method will work for me.
SO is using ASP.NET MVC. You really need to read in details how MVC URL rewriting works, but the gist of it is that the 'questions' part in the URL is the name of the Controller class (which roughly corresponds to the 'showdetails' in your URL) and the number is a ID parameter for the default action on that Controller (same as the parameter 'id' in your URL).
Since MVC isn't an option you can try redirecting the 404s. This will work in ASP.NET 1.1 and above: Redirect 404s and 405s to your own handler using either IIS config or web.config, parse out the request in the handler and redirect to the appropriate resource.
<configuration>
<system.web>
<customErrors mode="On" defaultRedirect="error.html">
<error statusCode="404" redirect="newHandler.aspx"/>
</customErrors>
</system.web>
</configuration>
Before the advent of System.Web.Routing, the common practice was to use UrlRewriter.NET. Worked well enough, but could bite you when configuring IIS. I'm not sure if there are any simple ways of using the new Routing classes in ASP.NET (i.e., drop it in and go vs. refactoring code).
please explain the meaning of values
such as "358630" in the URL
That is (presumably) the ID for the question in the database. In the MVC model
myurl.com/questions/358630
is analogous to
myurl.com/questions.aspx?id=358630
The question title on the end of the URL is actually being ignored by the app. It's generally "tacked on" for search engine optimization and human readability purposes. In fact, you can change the title of this question in the URL and notice the page still loads just fine.
The new System.Web.Routing dll is part of ASP.NET 3.5 SP1, and is bin deployable on ASP.NET 3.5, so you could use the features of that on a classic ASP.NET WebForms site.
You'll probably want to take note of Phil Haack's comments in his post on using MVC on IIS 6 as you'll probably need to include the .aspx extension in your routed urls
http://www.mysite.com/controler.aspx/action/id
You might also want to check out Questions Tagged SEO.
The ignored question name at the end of the url is often called a "Slug", and is used for SEO purposes to include the page title in the url.