ManagedPipeLineHandler generates 400 on Document Upload - asp.net

i have been trying to upload a PDF document and facing 400 bad request issues. Surprising this is working on another machine but not the production machine
After enabling Failed Request Tracing
ManagedPipeLineHandler generates 400 bad request. but I can't find any clue why it is, I have already checked maxRequestLength and maxAllowedContentLength.
<httpRuntime targetFramework="4.8" maxRequestLength="1048576" />
<requestLimits maxAllowedContentLength="1048576000" />
apparently, nothing much is wrong . from failed request its quite clear IIS has received document bytes and then generate an error
any advice or help will surely be appreciated.

Related

iis asp.net Failed to load resource: the server responded with a status of 403 () randomly

my website is hosted on iis 10
Since my pages change frequently I have inserted this in the headers:
cache-control: no-cache, no-store, must-revalidate
pragma: no-cache
expires: 0
After doing this all my pages have resources that don't load.
I think the problem was already there, but having the resources in the cache I didn't notice it.
Failed to load resource: the server responded with a status of 403 ()
In the Event Viewer on the server I saw these errors:
The description for Event ID 1 from source ModSecurity cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
[client 207.46.13.73] ModSecurity: collection_retrieve_ex: Unable to retrieve collection (name "ip", key "207.46.13.73_4f1ba30e7e0a1348a60fa661e5bb8b958e7f7aa5"). Use SecDataDir to define data directory first. [hostname "VULTR-GUEST"] [uri "/"] [unique_id "12105675809109317484"]
and
The Application Host Helper Service encountered an error trying to delete the history directory 'C:\inetpub\history\CFGHISTORY_0000000214'. The directory will be skipped and ignored. Note that the directory may still get deleted in the future if the service restarts. The data field contains the error number.
So I tried to disable ModSecurity, but the problem didn't go away. There are just no more errors in the EventViewer.
The amazing thing is that every time I refresh the page (ctrl + F5) the blocked resources change. Sometimes some images, others some css, others the fonts etc.
They always change, it uploads the images that it did not upload before and it does not upload the images it had uploaded before.
I had checked everything, but I don't understand what is happening. The problem exists in all devices.
The only particular thing is that I use CORS in the web.config
I don't know if it's relevant.
<cors enabled="true" failUnlistedOrigins="true">
<add origin="https://example.com" allowed="true" allowCredentials="true" maxAge="120" />
<add origin="https://*.example.com" allowed="true" allowCredentials="true" maxAge="120" />
</cors>
I contacted support, but they also don't know what to do.
Do you have any ideas?
Thanks
Luca
The Hypertext Transfer Protocol (HTTP) status codes in Microsoft Internet Information Services says:
403.502 - Forbidden: Too many requests from the same client IP; Dynamic IP Restriction Maximum request rate limit reached.
So I increased it to 50 calls in 200 milliseconds and the site started working again.

How do I ensure that X-HTTP-Method headers are ignored?

I'm currently applying security fixes for a vulnerability which was found by a third party software. This is the issue (Often Misused: HTTP Method Override vulnerability).
The request from the software was similar to:
POST /Home/ViewProfile HTTP/1.1
Referer: https://somesite.com/Home/ViewProfile?qrystr=blahblah
[...]
X-HTTP-METHOD: PUT
X-HTTP-Method-Override: PUT
X-METHOD-OVERRIDE: PUT
[...]
And the response was:
HTTP/1.1 200 OK
[...]
The web application is not a RESTful API, it's just a an ASP.NET MVC site which only has GET and POST actions.
I have a few questions:
Is this a false positive given the type of app?
By default, does ASP.NET do anything with these headers X-HTTP-Method, X-HTTP-Method-Override, X-METHOD-OVERRIDE if not explicitly told to do so such as in this example?
Regarding the first linked issue above, what is the best way to go about achieving the recommended remediations if they're necessary/applicable based on my case:
"Ensure that only the required headers are allowed, and that the allowed headers are properly configured."
and
"Ensure that no workarounds are implemented to bypass security measures implemented by user-agents, frameworks, or web servers."
Another thing to note is I don't have access to modify IIS settings, but I can modify the Web.Config.
I had the same problem with a scan from my security team. What I did was limiting the size of those requests to zero (0) in the web.config. The server then returns a "HTTP Error 431.0 - Request Header Fields Too Large", effectively blocking the overrides.
</system.webServer>
...
<security>
<requestFiltering>
<requestLimits>
<headerLimits>
<add header="X-Http-Method-Override" sizeLimit="0" />
<add header="X-Method-Override" sizeLimit="0" />
<add header="X-HTTP-Method" sizeLimit="0" />
</headerLimits>
</requestLimits>
...
</requestFiltering>
</security>
...
</system.webServer>
However, I haven't checked yet if this effectively cancels the alert by the security scanner. I suspect it might still show, but I'm ready to report back as a false positive because the server is blocking all calls with those headers. I'll let you know as soon as I get a response from the security team.

RequestFiltering not working for MS-DOS device name paths

I'm trying to appease a PCI scan failure we recently had done, in which it states:
Microsoft ASP.NET MS-DOS Device Name DoS
Synopsis :
A framework used by the remote web server has a denial of service vulnerability.
Impact:
The web server running on the remote host appears to be using Microsoft
ASP.NET, and may be affected by a denial of service vulnerability. Requesting a URL
containing an MS-DOS device name can cause the web server to become
temporarily unresponsive.
In a nutshell, we visit a URL on our app such as /AUX/.aspx we get a 500 error.
I'm using RequestFiltering to filter these requests out, and return 404's instead, without the server trying to process the request.
An excerpt of my web.config is below:
<system.webServer>
<security>
<requestFiltering>
<denyUrlSequences>
<add sequence="/AUX/.aspx" />
</denyUrlSequences>
</requestFiltering>
</security>
</system.webServer>
However, this isn't working, it's still returning a 500.
I would expect it to return a 404.
If I add the following catch-all url to the denyUrlSequences then the whole site produces the expected 404.
<add sequence="/" />
It's worth mentioning the application in question is an MVC app running on IIS 7.5 (Windows 2008 R2)
Just had to solve this problem.
My solution was to disable .Net Error Pages and enable IIS Error Pages.
When you move the custom error handling from the higher .Net level to the lower IIS level the HTTP response code changes from 500 to 404.
PCI Test Passed :-)
I struggled with this for quite some time myself. I think the 500 response code is correct for MS-DOS names in the URL, and you do not need to add anything to request filtering.
You'll notice that you will get a 500 error if you use any of the MS-DOS names (https://support.microsoft.com/en-us/kb/74496) without doing anything to your configuration. However, if you add a RequestFiltering denySequence for something else, like "foo", then you will see the 404.5 error when browsing to /foo.
If you add relaxedUrlToFileSystemMapping="true" to the httpRuntime element along with your request filtering denySequence entries, then you will get the 404.5 for MS-DOS names.
But disabling the default asp.net configuration just so you can get something other then a 500 response for a URL with MS-DOS name is a rediculous request from a PCI compliance check.

ASP.Net web service large URL

We have to send a large packet to an ASP.Net web service through the URL. We cannot use POST for certain reasons, so we are URL encoding an XML package and we make a GET request to the service.
http://service.example.com/collect?content=AAAAAAAA...(+5000 characters)
The service responds with
Error 404 - File or directory not found.
I have read that there is no error code for max-content-length-exceeded so IIS sends back this 404 error. Knowing that, I have changed the configuration in the following way to allow large requests:
Changed query string length, max URL length, max request length and deactivated validation
<httpRuntime
requestValidationMode="2.0"
maxQueryStringLength="262144000"
maxUrlLength="262144000"
maxRequestLength="262144000" />
...
<pages validateRequest="false" />
...
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="262144000" />
</requestFiltering>
</security>
</system.webServer>
I still receive the same error. How do I make a request to my web service with an extremely large/long URL?
Update 1
I am not sending images. The content is something like:
<packet date="1243235246436">
<param type="1" id="45">
5
</param>
</packet>
without the new line characters and URL encoded.
Update 2
After setting the limits to a larger number in the IIS Request Filtering the 404 is now transformed to
HTTP Error 400. The size of the request headers is too long.
This is because the size of the headers is too large now. Tried to follow the instructions from this article by adding the MaxFieldLength and MaxRequestBytes registry entries, but I am still capped at 16k URL length.
What can I do to be able to send 1,000,000 long URLs? Is this even possible? What can I do to send at least 65k long URLs? This is the max length a header can have, but my settings are not taken into consideration.
The MSDN documentation of maxQueryStringLength also talks about IIS filtering in case of very long URLs. Have you checked this ?
The property names mentioned there are a bit different: maxQueryString, maxUrl.
A GET request is only limited by a browser's limit on the length of the URL string.
In IE it is 2,083 characters, minus the number of characters in the actual path. Other browsers do not have a clearly defined limit on the length of the URL string. These articles might be helpful to you.
http://www.boutell.com/newfaq/misc/urllength.html
http://support.microsoft.com/kb/q208427
RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1," does not specify any requirement for URL length, so browsers are free to stipulate what they deem fit.

While uploading large files getting error

I am using .net 4.5. I set maximum request length and maxAllowedContentLength in config file as 100 mb. When I try to upload larger than 100 mb file (like 200mb to 1000mb) I am getting an error
The request filtering module is configured to deny a request that exceeds the request content length
This is normal and expected error but when I try to larger than 1 gb, I am getting error "internet explorer cannot display page".
I think it is due to a timeout issue but I really can't figure out actual reason of this error.
Thank u.
This has been asked about on StackOverflow many times. I'll continue the tradition :) For large uploads you need to set two parameters:
maxAllowedContentLength is measured in bytes, so make sure you've actually set it correctly. To allow 1GB uploads, it should be 134217728.
You also need to configure maxRequestLength as well as maxAllowedContentLength. Note though that it is measured in kilobytes, so it will be different.
For example:
<configuration>
<system.web>
<httpRuntime maxRequestLength="1048576" />
</system.web>
</configuration>
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
</security>
</system.webServer>
It's a little unclear, but what I think you're running into is IIS's normal behavior reguarding exceptions: any issue with the request returns a 500 server error response.
In oder to view exceptions you can either disable this behavior in the configuration file (MSDN Link), or transfer the file while logged into the server (connections from localhost bypass this behavior by default).

Resources