I can't seem to receive HTTP OPTIONS requests in my IIS6 hosted ASP.NET application. I'm testing it using a debug breakpoint (and file-log) in my Global.asax's Application_BeginRequest method. The breakpoint is never hit and the client gets a HTTP 403 Forbidden, I'm assuming from IIS6 directly (GETs and POSTs work fine btw).
I've tried several things in the web.config, including adding the following line to either and both the <system.webServer><handlers> and <system.web><httpHandlers> sections.
<add name="OptionsHandler" verb="OPTIONS" path="*" type="System.Web.DefaultHttpHandler"/>
I've also played with the <system.webServer><security><requestFiltering><verbs> settings and allowUnlisted="true" and <add verb="OPTIONS" allowed="true"/>.
Also, I'm not using URLScan or any other tools that might intercept the calls. In case you're interested in IISLogs:
2011-07-11 20:26:05 W3SVC1215124377 127.0.0.1 OPTIONS /test.aspx - 80 - 127.0.0.1 Mozilla/5.0+(Windows+NT+5.2;+rv:5.0)+Gecko/20100101+Firefox/5.0 403 1 0
Is there a way to receive OPTIONS request in an ASP.NET Application?
For IIS6, you will have to enable the OPTIONS verb explicitly in the management console, and you will also need to map it to be handlded by ASP .NET. Only then, you will be able to register your handler in <system.web> and get the request processed by ASP .NET.
(Note, <system.webServer> settings only applies to IIS7).
Related
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.
I have an ASP.NET Web API running locally which I'm debugging with Fiddler. The API is running under an application pool account and makes a number of calls out to an external API.
When I run an acceptance test against my local API and capture requests in Fiddler I don't see those external requests, just the HTTP calls made directly within the test's app domain. Having done some reading I see that I need to configure IIS to use a default proxy to route all traffic through Fiddler.
So, I tried adding this to my web.config's system.net:
<defaultProxy>
<proxy autoDetect="false" bypassonlocal="false" proxyaddress="http://127.0.0.1:8888" usesystemdefault="false" />
</defaultProxy>
This works well. Fiddler now shows me all the internal HTTP requests being made by the API. However, I don't want to affect other developers by committing this web.config change, so I tried moving this section to my machine.config.
Having done this, even though I can see the configuration being pulled through to my IIS application (screenshot below), I don't see the same requests in Fiddler which suggests to me the proxy is not being used. Even after an iisreset.
Can anyone shed any light on this?
Update 1
#lex-li pointed out that usesystemdefault in my screenshot is true whereas I'd set it to false in machine.config. It seems this particular value is not pulled through to the application configuration from machine.config for some reason. However, if I override just that value in web.config as below, the application still doesn't use the proxy.
<system.net>
<defaultProxy>
<proxy usesystemdefault="false" />
</defaultProxy>
</system.net>
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.
Is there any MVC specific way to require an SSL Client Certificate for a specific Action or Controller, i.e very much the way RequireHttps or Authorize works, but for ClientCerts?
I know about the trick where you create an empty folder in the site, a Controller with the same name as the folder and then set up a rule in web.config, but I don't want to do it this way, I am looking for an MVC solution if there is one.
(Example of the web.config trick:)
<location path="/ClientCert">
<system.webServer>
<security>
<access sslFlags="Ssl,SslRequireCert" />
</security>
</system.webServer>
</location>
I'm curious if there is a solution that can be encapsulated in an ActionFilter and/or HttpModule?
I don't believe so. Client Certificates are handled and mapped in IIS or HTTP.sys during connection negotiation, which is way lower down than MVC. If that client certificate is being used for mutual authentication with SSL/TLS, then the client certificate is needed just to establish a HTTPS session and connection.
This all happens well before MVC, or any code for that matter, is given a chance to run. This happens down in the kernel in HTTP.sys.
I've created an ASP.NET WebService that is to be consumed using ASP.NET Ajax. The WebService is located on the same box and same web application that it is to be used by, so I do not want to allow remote access to this webservice, but have it only respond to requests from localhost.
The Web.Config DOES NOT have a configuration section and therfore does not have httpPost and httpGet turned on. This is fine. However, if I navigate directly to the WebService URL from a remote machine, it still loads and shows me a list of methods. Clicking on the method does give me a message stating that the testing form is not available to remote machines (as intended), but it does list information on how to issue a Soap Request and handle a Soap Response.
Additionally, I believe I'm being scraped by a bot of some sort of just a curious user, because I'm now getting error message in my log such as this...
System.InvalidOperationException: Request format is unrecognized for URL
unexpectedly ending in '/ValidateUsername'.
This happens if you try to issue a GET request (by manipulating the query string) against the service remotely. I'm glad that it's not handling the request as I don't want remote users access to this service, but I would prefer it not throw an error.
How can I lock down the webservice so that it is not available to remote machine, but still available to the local machine as a ScriptService consumably by ASP.NET Ajax?
UPDATE:
Okay, here is workable example of what is happening.
WebSite: http://so.weirdwes.dyndns.org/default.aspx
WebService: http://so.weirdwes.dyndns.org/services/services.asmx
Web.Config:
<webServices>
<protocols>
<remove name="HttpGet"/>
<remove name="HttpPost"/>
</protocols>
</webServices>
The website is consuming the WebService using a ScriptManager tag and ScriptReference. You'll note if you click the button, the web service is called and everything works, even though Post and Get have been removed. This is fine as this is how we want it to work. The issue is this....
http://so.weirdwes.dyndns.org/services/services.asmx/GetRemoteAddr
Server Error in '/' Application.
--------------------------------------------------------------------------------
Request format is unrecognized for URL unexpectedly ending in '/GetRemoteAddr'.
A bot or something is scraping this URL and it's generating errors that we're get notified of. I want to supress this error or block it entirely. If I alter the Web.Config and add the Get and Post protocols back in, this error goes away - but then it allows access to the web service remotely using Get which we don't want.
I am kinda confused here.
Is this going to be called by the browser? if it will be, then you should allow remote access.
Test against the ip address
Request.ServerVariables ["REMOTE_ADDR"]
IIS lets you white/black list IP groups in its configuration. Use that to lock it down to localhost. You can also configure your firewall to prevent anyone from hitting that port from outside.