I am using ARR and ISAPI with IIS7.5.
Whenever forwarding URL including specific character :
400 Bad request occurs.
How can I solve it?
I guess there is no problem in ARR and ISAPI because no problem in development server(same Env as operating server) it only occurs in operating server.
By default IIS 7.5 rejecects certain characters in the path -- the default is the follwing comma separated list: <,>,*,%,&,:,\\. If a request hits that list it will return a http 400 error as the request is bad insofar as the server is configured. See this blog post and this MSDN page for a little background. Specifically, you'll likely want to update the httpRuntime configuration to something like:
<httpRuntime requestValidationMode="2.0"
requestPathInvalidCharacters="<,>,*,%,&,\"
/>
The : character is only permitted in URLs as part of an IPv6 address. Either encode it as %3A, or don't use it.
You can find the reference in RFC3986
Related
Here's the thing. I'm trying to protect my server from XSS Attacks (And so far with no trouble at all, changing HTTP response Headers and other things) But a Generic vulnerability is still going on, and it happens because in the URL some javascript code can be inserted
(i.e. http://myhost.com/thisfile.jsp?<script>alert("hello")</script> )
when I type this, the response is HTTP 202 OK Status (It redirects to my 404 page). But I need to do one of these actions:
throw another HTTP Status (405, 500, Or any status giving an error)
Throw an error.
What can I do? Is there any way to strip the tags or recognize them via web.config file to throw an error?... I've been trying with the rewrite module and the request filtering with no success at all.
Thank you so much in advance, regards.
Thank you... I solved it and it was so easy (I can't believe i didn't try that first).
I went to IIS manager and then click on request filtering.
Then, on the "Rules" tab I added a "Filtering Rule". Applying to all file extensions and in the field "Deny Query String" I added <script>, <scr+ipt>, etc. So when the URL comes with a tag like that the connection is closed without showing 404 or any error page.
It worked and now the vulnerability scanner doesn't show any risk.
I've got 6 identical machines running IIS and Apache. Today one of them decided to just stop serving requests. I can access all of the webapps when I try from localhost/resource but when I try from url/resource I get a 404. I did a Get request against the machine that isn't working and I get this back:
Server: Microsoft-HTTPAPI/2.0
Connection: close
Compared to a working server:
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Content-Type: text/html
Tried searching for this problem but came up with nothing, anyone got any idea's?
Windows has an HTTP service that manages calls to IIS and other HTTP enabled services on a windows machine. Either you need to configure it to handle your calls, or, in the case of WAMP or similar non-IIS-web-server-on-windows scenarios you may just need to turn it off.
When you see "Microsoft-HttpApi/2.0" returning error, such as 400 "bad URL" or "bad header", etc. the problem is most likely because the HTTP.sys service is intercepting your http request and terminating it because it does not meet with the minimum validation rules that are configured.
This configuration is found in the registry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters. In my case, it was choking because I had a RESTful call that had a 400 character segment in the url which was 160 characters more than the default value of 260, so I
added the registry parameter UrlSegmentMaxLength with a DWORD value of 512,
stopped the service using net stop http
started the service using net start http
I've run into these issues before and it is easy to troubleshoot but there is very little on the web that addresses it.
Try these links
"the underlying problem is that the client has sent a request to IIS that breaks one or more rules that HTTP.sys is enforcing"
enabling logging on HTTP.sys is described here
a list of the HTTP.sys parameters that you can control in the registry is found here.
A bit late, so put here for posterity ;-)
After trying all sorts of solutions found on the web, I almost gave up, but found this little nugget.
If the response's Server header returns Microsoft-HttpApi/2.0, it means that the HTTP.sys is being called, not IIS.
As a result, a lot of the workarounds will not work (URLScan, etc).
This worked however:
Open regedit
Navigate HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\
If DisableServerHeader doesn't exist, create it (DWORD 32bit) and give it a value of 2. If it does exist, and the value isn't 2, set it to 2.
Finally, restart the service by calling net stop http then net start http
src: WS/WCF: Remove Server Header
Set below registry flag to: 2
HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\DisableServerHeader
Setting this to 2 will ensure that self host WCF services no longer sends the SERVER header and thus ensure we are security compliant.
Please note that this disables ALL server headers.
The default value of 0 enables the header, and the value of 1 disables server header from DRIVER (http.sys), but app can still have headers.
For me I had to restart the server for the changes to take effect.
Hope this helps someone
I was working on our web app on a client's site and ran into an issue where the site root pages loaded, but the reports folder always returned a 404 for files that existed in the folder. The 404 page showed the .Net version of 2 when the application was set to 4, and a test of a non-existent page in the root returned a 404 page showing .Net 4.
I tried just http://localhost/reports and got back a Microsoft Reporting Services page. Not part of my application.
Be sure to check just the default document of the folder when a unexpected 404 comes up and the file exists.
This question and series of replies helped me get to the bottom of the related issue I was having. My issue centered around using just a subdomain to go to our server (e.g. typing "www/somepath" into the browser while on our corporate network), which had worked in the past on an older server, but no longer worked when the system was upgraded to a new server. I saw the unexpected Microsoft-HttpApi/2.0 string in the header when using the Chrome Devtools to inspect the Network traffic.
My HTTP.sys process was already logging, so I could verify that my traffic was going to that service and returning 404 NotFound status codes.
My resolution was to add a binding to the IIS site for the subdomain, making IIS respond instead of the HTTP.sys process, as described in this server fault article - https://serverfault.com/questions/479274/why-is-microsoft-httpapi-returning-404-to-my-network-switch
In my case, running Windows 10 Pro, it was the Windows MultiPoint Service.
By executing:
net stop wms
Port 80 was released.
I recently scanned my application for the vulnerability, got minor fixes but for one of them I tried hard still not able to fix. For some operation my site throws 500 error and when I check header of that error, it is having server header named IIS 7.5. I have already used URL rewrite rule,registry fix,URL scan thing, but seems to be nothing is working.How to fix that ?
If you mean the Server HTTP header, which will probably be set to something along the lines of Microsoft-IIS/7.5 then the easiest way is to overwrite it with a blank or custom value in IIS. You can remove it completely by creating your own HTTP module. The following link discusses the manifold methods you can try:
http://www.dionach.com/blog/easily-remove-unwanted-http-headers-in-iis-70-to-85
I have an ASP.NET (version 4) MVC 3 application running on IIS 7.5. Anytime there is a single quote in the URL, for example http://devserver.com/myapplication/Home?filter=id~eq~'123' - I get a 403 Forbidden error.
Specifically, this happens when I'm using a Kendo UI grid and am trying to filter one of the columns. But I found that anytime a single quote is in the URL, IIS immediately gives the 403 error.
I've looked in the IIS logs and the event viewer and there is no indication anywhere of a 403 response - I can't seem to find out specifically why the 403 was given.
It's not IIS, it's Siteminder! We have Siteminder in front of our web application, and Siteminder intercepts all incoming traffic for authentication. In this case, Siteminder will also disallow a URL with a single quote in it. Although the 403 error looks like it's coming from IIS, it's really coming from Siteminder.
This issue happened for my app as well and the culprit is Siteminder in my case.
They have a set of BadCSSChars lists which would be validated against our URL. If any bad character is found, the URL will be blocked and wont reach IIS.
Siteminder can remove the 'character needed' exception in the agent.log file (not an expert in this, but heard that this file which stores badcsschars list) in the app server.
Having a strange issue - we have a page that uses a query string to get some information, this query string happens to contain the word set. When this happens, the page returns a 406 error (Client browser does not accept the MIME type of the requested page.)
The URL looks like example.com/folder/file.asp?variable=sunset boulevard. If I change the space to %20 it still returns 406.
On my local machine running IIS 5.x this doesn't happen, on our test server running IIS 7.x this doesn't happen, only on our production server running IIS 7.x over SSL. Note however that a self signed certificate on my local machine over SSL still doesn't produce the error.
So my question is, what does the set keyword in the URL tell IIS to do and is there an easy way to avoid it happening? I would like to avoid changing the space to a different character if possible.
Does your server have additional filters installed? Smells like the work of an agressive filter designed to prevent certain types of attack.