I'm using system.text.utf8encoding.utf8.getstring to convert a byte array to a string and then am sending it to my asp.net program through a regular web request as a POST value. Every now and then, I get an exception
"A potentially dangerous Request.Form value was detected from the
client "
Is it possible to get rid of that?
EDIT: never mind, I started using webclient.uploaddata to send and receiving by request.binaryread instead, this method doesn't seem to have this problem.
try to Add below code put to your web.config file.
<system.web>
<pages validateRequest="false" />
</system.web>
Related
I host a website that provides public API access for my customers to track their orders with an order number. I have allowed them to use both POST or GET (with URI parameter) to pass the order number to me. Some of them however wrote careless codes that passes illegal chars (asterisk, colon or incorrectly encoded asian characters), like this https://mycompany.com/tracking/orderno:ODR12345 which causes IIS to throw exception:
Exception information:
Exception type: HttpException
Exception message: A potentially dangerous Request.Path value was detected from the client (:).
at System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
I have inherited Application_Error method to log this exception. But it still gets thrown as a 400 Bad Request error to user browser and leave an Event 1309 in my event viewer, hence spamming the log with it.
I know I can turn off illegal-chars-exam from Web.config universally but that's a security risk. I just want to be able to handle this exception myself: capture it, log it my own way, provide useful response to user and then suppress it so it doesn't pollute my system log. How can I do this?
UPDATE
Lex gave me an idea to rewrite the URL. What I think is, I can put the parameter into the query string instead of leaving it a part of the path, so that dangerous path error will disappear. I then wrote the following rule:
<rule name="TrackingRewrite" enabled="true" stopProcessing="true">
<match url="/tracking/(.*)" />
<action type="Rewrite" url="tracking?querystring={R:1}" />
</rule>
So that https://mycompany.com/tracking/orderno:ODR12345 becomes https://mycompany.com/tracking?querystring=orderno:ODR12345 and the correct action was executed and users gets a 200 response with tracking information. However - after the controller action returned, Applciation_Error call back still gets called with the "A potentially dangerous Request.Path value was detected from the client (:)." exception and system log was added. Breaking into the Applciation_Error call back and printing the Request.Url shows the original illegal URL, not the rewritten one. How does one to comprehend this behavior?
I could not find the specific answer to this when searching so I'm posting my solution here.
We were working fine with SignalR for a long time, then some users started getting 404 errors on the start and connect calls from AngularJs/jQuery to the server. Negotiate would work fine though and return a 200 code.
It turns out by default the server side (ASP.NET 4.6.1) must impose a limit on the size of a URL and instead of returning a 414 (Request-URI Too Long) like you might expect it must just truncate the URL at a length around 2,083 and still try to process it. I'm assuming the 404 is the SignalR hub responding because now the truncated string has query string parameters that don't match what is expected. We were seeing it because we were passing a couple custom values and the security access token via query string parameters which increased the size. The access token was passed via query string because we wanted to use websockets and headers don't exist for websockets. As you add more attributes and roles to your token it will grow which is what put us over the default size limit.
The fix is easy. Just update your server web.config to allow longer URLs.
<system.web>
<httpRuntime targetFramework="4.5" maxRequestLength="30000000" maxUrlLength="40960" maxQueryStringLength="2097151" />
</system.web>
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="30000000" maxUrl="40960" maxQueryString="2097151" />
</requestFiltering>
</security>
</system.webServer>
I have a WCF service (over a webHttpBinding) using ASP.NET 4/IIS 8 and I had no problems communicating with it using JSON with GET. However, today I needed to implement a method that sends a large query string (about 3000 characters, not that long but longer than that I've been using). I called the service and immediately got a 404 error, without even stepping into my code at my debug machine. The first thing that came to my mind is the maximum query string length limit. I've added this to my web.config:
<system.webServer>
<directoryBrowse enabled="true" />
<security>
<requestFiltering>
<requestLimits maxQueryString="8000"></requestLimits>
</requestFiltering>
</security>
</system.webServer>
Now, I am getting this server error when I call the service: The length of the query string for this request exceeds the configured maxQueryStringLength value. Weird enough, I've tried other values such as 200000, way over my query string and URL, which is about 3000 characters. Am I missing something?
Maybe set maxQueryStringLength in the httpRuntime element.
It's a bit confusing to have two configuration settings, but I believe they can be interpreted as follows:
The httpRuntime maxQueryStringLength property is new to ASP.NET 4 and configures the maximum query string length that can be processed by the ASP.NET HTTP runtime. Prior to ASP.NET 4 this was a hardwired value of 2048; it can now be increased.
The system.web/security/requestFiltering maxQueryStringLength property is an IIS 7 setting and allows an administrator to restrict the maximum query string length. This setting isn't specific to ASP.NET.
I've inherited an MVC asp.net app using framework 4.0.
I'm getting the dreaded "A potentially dangerous Request.Form value was detected from the client" error and all my research leads me to believe that this should fix it:
<system.web>
<httpRuntime requestValidationMode="2.0" />
<pages validateRequest="false" />
</system.web>
However, I've added that to my web.config and still get the error. I'm at the end of my rope here, what am I missing?
In addition to what you did you also have to decorate your methods with the ValidateInput attribute.
[ValidateInput(false)]
public ActionResult MyActionMethod(string myParameter)
{
// Method implementation goes here...
}
There is an alternative though, you can implement your own request validator and bind that in your web.config if you want to handle validation for your entire site. Take a look at this blog post on how to fully implement it.
Basically, create a class that inherits from RequestValidator and then hook it up on the web.config.
<httpRuntime requestValidationType=”Globals.CustomRequestValidation”/>
Hopefully this helps!
Take another approach. In the httpRuntime, point to your custom validation class. This way have the complete control over incoming requests as the validator is fired upon each single request, at the beginning of the processing pipeline.
In particular, if you implement your validator to return true, you will unconditionally accept all incoming requests.
http://msdn.microsoft.com/en-us/library/system.web.util.requestvalidator.aspx
The simplest way is to remove the characters you want from the validation system.
Here is the requestPathInvalidCharacters attribute from the httpRuntime element with its default value.
<httpRuntime requestPathInvalidCharacters="<,>,*,%,&,:,\" />
<!-- the unescaped characters are: < > * % & : \ -->
Remove the characters you want to authorize and the request will work.
Sorry for my English.
I have a strange problem.
When user click adword link, Google write tracking cookie like that
1813234232.1302674912.30.51.utmgclid=CcgezrsXjagCFcs-zAod_h2oCQ|utmccn=(not set)|utmcmd=(not set)|utmctr= CAA:89 AB0=40#B%20>:
In keyword section(utmctr) there is bad braskets, that cause request validation exception
A potentially dangerous Request.Cookies value was detected from the client (__utmz="...0=40#B%20> at System.Web.HttpRequest.ValidateCookieCollection(HttpCookieCollection cc)
Is there any way to solve this problem without turning off request validation?
Edited
I'm probably found obvious solution: write own request validation module http://jefferytay.wordpress.com/2010/04/15/creating-your-own-custom-request-validation/
By default asp.net validate and check the data for potential attacts.
You can disable this automatic validation by set validateRequest="false" ether on page
<%# Page validateRequest="false" %>
ether on web.config that affect all pages.
<configuration>
<system.web>
<pages validateRequest="false" />
</system.web>
</configuration>
The only think that you need to check by your self after that, is if someone enters any script data to your inputs. Your inputs then need to check out when you render them on the page, and when you enter them on the database.