.NET 4 broke ValidateRequest=“false” for some reason.
The solution is -- just put <httpRuntime requestValidationMode="2.0" /> into your web.config file.
The problem with that solution is that it breaks support for .NET 2.0!
IIS refuses to accept unknown attributes in web.config. Also I don't like the all or nothing nature of this.
Can I set requestValidationMode (or in some other way disable request validation) for a single page that needs it? Without breaking backwards compatibility of web.config with 2.0?
I can confirm that the approach of adding validateRequest="true" to the web.config file works and it is marvellous!
Using this makes the page-level directives work correctly again and it avoids the need to change the behaviour back to the ASP.Net2.0 mode.
Strange that it has any effect, seeing as request validation is normally enabled by default anyway, but no matter.
if you are using .net4 then add this line to web config
<pages validateRequest="false">
and no need to use <httpRuntime requestValidationMode="2.0" /> at all
OK, looks like this can't be done and I can just escape the data easily, but I think this was a legitimate question -- at least to make a note here that this can't be done.
I found a better way, I think. I didn't like the option of reverting back to a 2.0 setting while in 4.0. I also don't like the all or none option.
I played around with a few things and I have at least in my mind a practical solution.
By default all pages are validated regardless of the page directive of "ValidateRequest="false"
I found where to make this setting in the web.config in the system.web section called pages.
(http://msdn.microsoft.com/en-us/library/system.web.configuration.pagessection.validaterequest.aspx)
If the validateRequest attribute is added into the pages element you can control the validation for the whole site.
But I stumbled across a happy thing while testing this. I couldn't find docuementation for this, but here is what I've experienced.
By default validation is turned on everywhere, but if I set the validateRequest to "true" my individual page directives work as they did in 2.0. I don't know why, but I'm happy.
So in summary...
Set the validateRequest to true.
Like here.
Then any page directives work for that validation.
I just put this in my web.config in the system.web node.
<httpRuntime requestValidationMode="2.0" />
Related
I have published an ASP.NET MVC3 site. It runs great. However, looking back at my web.config file, I was not sure if some of the values I used are correct for publishing versus for developing. These configurations are in the <system.web> section.
...
<system.web>
<httpRuntime requestValidationMode="2.0" executionTimeout="200" maxRequestLength="20000000"/>
<compilation debug="true" targetFramework="4.0">
...
I read here ( http://msdn.microsoft.com/en-us/library/e1f13641.aspx ) that using debug=true in compilation will disregard the executionTimeout of 200, and use a default value of 110. This seems to be the case, and the site is setup to allow very large amounts of files to be uploaded all at once. However, with only 110 seconds, not much can be uploaded.
My question is this: Is the correct setting to publish a live site for debug "false"? In addition, is requestValidationMode="2.0" still safe to use considering asp.net is now on version 4 (soon to be 4.5)?
Validationmode 2.0 is not the framework version and can stay like that.
Put debug=false and you are fine.
requestValidationMode... As far as I'm aware, this has to be set to 2.0 if you want to allow special characters (<, >, % etc.) in request data to pass ASP.NET's request validation at all. requestValidationMode="2.0" means "only enforce validation on pages (i.e. .aspx), rather than on every request (as was introduced in 4.0). That allows ASP.NET MVC to take over the validation - and hence also lets you turn it off for specific requests.
Is it safe? It is, if you've made sure that any actions or controllers that have [ValidateInput(false)] applied or models with [AllowHtml] have been properly secured against attacks. Imran Baloch has a full explanation here.
And yes, debug should be "false" for several reasons, including performance and memory usage. Also, debug="true" changes the default cache policy for static files to never cache the files in the browser, meaning tons of redundant requests for scripts, CSS etc.
As for the image upload, other than the suggestions given, check in Event Viewer that it's not really the application pool recycling for one reason or other, rather than an execution timeout.
I have an issue where adding this to any asp.net request causes and unhandled error (regardless of CustomErrors setting): ?aspxerrorpath=<script
The weird thing is that I have two applications that are totally immune to the problem, but I can't spot the difference. I'm running on IIS 7 and using the 4.0 Framework. But this also happens on my 3.5 IIS 6 apps. Again, I have two sites that are fine (IIS 7, 4.0) but can't determine why. I have tried turning off request validation to no avail. Has anyone encountered something similar?
FIXED:
This looks like it was an Umbraco issue. It was ignoring my validateRequest="false" in the web.config. Adding this to the template fixed it:
<umbraco:DisableRequestValidation runat="server"/>
This looks like it was an Umbraco issue. It was ignoring my validateRequest="false" in the web.config.
Adding this to the template fixed it:
<umbraco:DisableRequestValidation runat="server"/>
In your section, ensure the following is set:
<pages validateRequest="false">
Is anyone aware of any situations in which an ASP.NET 2.0 webservice might be unable to read the appSettings values from the web.config? I seem to have exactly that problem - the code thinks the appSettings is empty when it isn't.
In more detail: This code:
Dim settings = ConfigurationManager.AppSettings
Dim count = settings.Count ' always gives zero
Incorrectly shows that there is no data in the app settings.
My web config looks like this
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<!-- lots of other stuff -->
<appSettings>
<add key="SomeKey" value="Some Data" />
<!-- other keys -->
</appSettings>
</configuration>
I've verified that the code can see the web.config file (by the simple device of commenting out everything in the file, and seeing that when I try to run the service, it complains that the web.config is invalid).
The code is production code which does in principle work, just not apparently on my machine - so I'm guessing the problem has something to do with my environment, it's almost certainly not a problem with the code.
Ah, it seems the reason was absurdly simple. I just needed to recompile the VB code! What happened was that, because I was (correctly, as it happens) convinced there was nothing wrong with the VB code, I focused all my efforts on fiddling with the web.config and with the IIS settings (because those were the things that might conceivably be different between my machine and the known working live program). Eventually I gave up on that, and decided to temporarily work around by changing the VB code to use hardcoded values instead. As soon as I did that and rebuilt, I found that the program now picked up the appSettings correctly (and my hack became unnecessary).
So, my guess is that somehow the VB code became detached from the web.config, and needed recompiling to re-attach it. I'm somewhat puzzled because I thought that ASP.NET would automatically detect changes to the web.config and so recompile anyway, but evidently not.
If anyone can satisfy my curiosity by explaining what might have been going on in ASP.NET that could result in an explicit code-recompile being necessary to read the web.config correctly, then I'll mark that as the answer to my original question. (If noone does after a day or so, I'll mark this post as the answer).
I want to be able to save things like:
<script src="https://spreadsheets.google.com/gpub?url=http%3A%2F%2Foj0ijfii34kccq3ioto7mdspc7r2s7o9-ss-opensocial.googleusercontent.com%2Fgadgets%2Fifr%3Fup_title%3DBrands%26up_initialstate%26up__table_query_url%3Dhttps%253A%252F%252Fspreadsheets.google.com%252Fspreadsheet%252Ftq%253Frange%253DA%25253AE%2526key%253D0AqFjLMbUaBn_>
In an nvarchar(max) field, I get the following when I try to insert:
"Server Error in
'/TheScienceAndArtOfDataVisualization'
Application. A potentially dangerous
Request.Form value was detected from
the client
(ctl00$MainContent$txtCode="<script
src="https:/...")."
DeadYCool's answer will work if you want to disable request validation on all pages, if you just want to disable it on a specific page, you can set ValidateRequest="false" in the Page directive of the .aspx file.
<%# Page ValidateRequest="false"...
If you're using ASP.NET 4.0 you may also have to make a change to web.config:
<configuration>
<system.web>
<!-- Sad requirement to allow ValidateRequest="false" -->
<httpRuntime requestValidationMode="2.0" />
But it should be avoided if possible.
Please try not to disable this. HtmlEncode your results before you send them to the server. Disabling disabled some built in protections. Either way also use the Anti Cross site scripting libraries GetSafeHtmlFragment. By allowing html you can open yourself up to a cross site scripting attack. See my talk here to understand the issues:
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV333
In web.config find the following:
<pages validateRequest="true">
and change to:
<pages validateRequest="false">
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.