I have an IIS 10.0 server, and I'm seeing that some disallowed headers [Pragma, Expires] are still getting added, but they are only being added to API endpoints, not when static content is getting retrieved. These headers are not being set in the code. I've followed the recommended approach to remove the headers from IIS (adding the remove element to configuration\system.webServer\httpProtocol\customHeaders), and when debugging, I do not see these headers in the HTTP response before it gets sent back to the caller. I would like to remove these headers from the response, but have no idea how to figure out where they are being set. Any pointers?
To extend the comment above.
The key to troubleshoot such issues is to know the source of such headers, so enabling Failed Request Tracing is the quickest way.
If you find that the headers (such as ASP.NET and so on) are set by IIS default modules, you know that you should refer to IIS documentation to locate the settings and turn them off.
In your case, FRT reveals the headers come from a third party module, so you will need to check what settings the vendor provides in documentation.
Note that even if you cannot find vendor settings to turn them off, you might still be able to remove them in several ways such as removing such headers in URL Rewrite outbound rules.
Related
In my ASP.NET MVC application, I want to resolve the HTTP Request Smuggling Vulnerability issue.
I thought it would be sufficient if I blocked the requests which have a Transfer-Encoding: chunked header. In the IIS administration menu, I added a new Request Filtering rule for this. However that does not seem to fix it.
I wrote little .NET code to test if IIS generates a 404 error when chunked content is sent. When I add the transfer encoding header 1 time to my test client code as below, I do NOT receive 404—I receive 200.
httpRequest.Headers.Add("Transfer-Encoding", "chunked");
Interestingly, if I add the header 2 times (I mean duplicate it) like
httpRequest.Headers.Add("Transfer-Encoding", "chunked");
httpRequest.Headers.Add("Transfer-Encoding", "chunked");
The filtering rule applies, and I receive 404 as I expected.
How can I fix it?
A few months later, Microsoft added a patch wherein you can disable request smuggling with a registry key.
Click Start, click Run, type Regedit in the Open box, and then click OK.
Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
Set DWORD type value DisableRequestSmuggling to one of the following:
Set to 0 to disable the filter
Set to 1 to enable the filter
Exit Registry Editor.
Restart the computer.
I have very important query regarding cowboy_static
{"/api/assets/[...]",cowboy_static, {dir,"/home/upload_dir/"}},
{"/api/assets/[...]",cowboy_static, {dir,"/home/upload_dir/"}},
Everything is working fine but I failed to send a default image (for example not_available.jpg) for 404 .
Is it possible in cowboy_static to send a default image if request image/URL not found.
Thanks in advance.
I do not think there is a way of doing it with just cowboy_static handler. The documentation (static files) says
Cowboy comes with a ready to use handler for serving static files. It
is provided as a convenience for serving files during development.
For systems in production, consider using one of the many Content Distribution Network > (CDN) available on the market, as they are the best solution for serving files.
so some functionality may be missing there. If you really want to serve 404 custom page from Cowboy, I think the only option is a custom handler instead of cowboy_static.
I had a Rails application with config.force_ssl = true, but now I dont want SSL encryption, but my app is still redirecting to https. I read this is a HTTP Strict Transport Security problem on Apache. How can I disable it?
It's not a problem with Apache, but with the fact that Rails sends an HSTS header.
In Chrome, you can clear the HSTS state by going into about:net-internals, as described in ImperialViolet: HSTS UI in Chrome. You may also have to clear the cache, since config.force_ssl = true also uses a 301 (permanent) redirection.
In addition, according to this answer, you could also make your application send an STS header with max-age=0. In your controller:
response.headers["Strict-Transport-Security"] = 'max-age=0'
Just wanted to point out #Bruno's answer and #JoeVanDyk's suggestions are true and can be applied beyond the context of Rails/Apache. I'm using PHP and Nginx. PHP has nothing to do with it in my case, but here's the steps with Nginx:
//sorry here's the nginx.conf part first, can't figure out how to mix multi-line
//code with an ordered list
server {
#...
#change:
# add_header Strict-Transport-Security "max-age=315360000; includeSubdomains";
#to:
add_header Strict-Transport-Security "max-age=0;";
#...
}
clear your "browser history". To clarify on #JoeVanDyk's suggestion , I think you need to clear "browsing history" because clearing the cache didn't work for me (tested on Chrome/Firefox, please add comments if you know more).
nginx.conf file (see code above)
restart server
root#ip-xxx-xxx-xxx:~# /etc/init.d/nginx restart.
After this, you can revert the nginx add_header Strict.. command to what you previously had. Just make sure you repeat steps 1-3 again.
I found I couldn't delete an HSTS entry in Chrome as I was using an IP address for development. I couldn't seem to get chrome://net-internals/#hsts to delete the entry. I found that Chrome stores the entries in ../AppData/local/Google/Chrome/User Data/Default/TransportSecurity so I just deleted the file. It of course removes all HSTS requests, but I suspect they will be rebuilt over time.
Figured id offer a bit of thought on this. Setting cache time to 0 is a best bet and if you turn it off you need to leave it at 0 for weeks to clear out clients browsers. If you just need to clear HSTS in chrome (for your own browser) you can use chrome://net-internals/#hsts in the address bar to clear the cache for your site at your specific browser. Combined with the below "doorway" it becomes useful.
You can set temporary HSTS modes by setting/spoofing a custom header => key. Basically if a special request header exists, and it matches a key, set HSTS with a cache time of whatever you need. This would allow you to turn on or shut off HSTS for all traffic but you. Useful for trying HSTS out before you globally enable (to make sure all assets are loading). Also useful if you wanna temporarily clear out client cache while something is repaired (leaving you room for test).
If you are developing an application/site and for any reason you choose to use the domain .dev or .app for it and if you are using Chrome, Edge (Chromium based) as your browser you won't be able to get rid of this error because Google bought TLD .dev and .app and force the use of HTTPS for those domain.
The "so called" workaround here is that you should change .dev or .app for something else, let say .local.
Hope this helps, somehow.
I am trying to create a chrome extension that calls my rails app's api. currently the api returns json and it works fine, however when I try to build it into a chrome extension, it says :
Refused to load script from 'http://mysite.com/demo?q=hello?callback=jQuery16409466155741829425_1342489669670&_=1342489677171' because of Content-Security-Policy.
I looked up the document http://code.google.com/chrome/extensions/contentSecurityPolicy.html and it sounds like I can't do this unless I implement my site into a https version. (under "Relaxing the default policy" section) I am not sure if I understood correctly and it feels ridiculous to make such a big change just because of this. Am I misunderstood? Or is there a workaround to this? Thank you.
In a Chrome extension, cross-site XMLHttpRequests are allowed, provided that you define the source in the manifest file - see http://code.google.com/chrome/extensions/xhr.html.
A JSONP implementation loads an external script using the <script> tag, and inserts it in the document. Unless the source is whitelisted through the "content_security_policy" entry, JSONP cannot be used when manifest version 2 is active (do not use manifest v1 to overcome this, because it's deprecated, and a suitable alternative already exist).
When you're unable to receive a JSON response instead of JSONP, use an ordinary request to fetch the data, cut off the callback, then parse it. Eg:
// response is the response from the server
// Received through `XMLHttpRequest`, jQuery.ajax, or whatever you used
// cuts of jQuery....( and the trailing )
response = response.replace(/^[^(]*\(/, '').replace(/\);?$/, '');
By default browsers do not allow this because of the same origin policy.
However you can get around this by making a jsonp request.
As you using jquery this super easy with getJSON method
Quite not sure why I see this error.
I navigate to my Login View like so http://test.staging.com/mywebsite/Login
My Login view was just redone using MVC but I have seen this same error message going to an aspx page as well...
If I use http I get the error message The specified request cannot be executed from current Application Pool.
If I use https://test.staging.com/mywebsite/Login, I'm good.
If I don't specify a protocol, test.staging.com/mywebsite/Login, I get the error as well
Is there an error happening under the covers and my custom error page can't be shown like discussed here?
What are some other causes of this error?
That usually means your custom errors are configured to run as a different AppPool.
You can read more at MSDN. (See section "Using Custom Errors from Another Application Pool").
There are two ways to correct this behavior. The first is possibly not one that you are interested in because it would require you to change your current architecture and run both sites in the same application pool (such as share the same worker process memory space). To do this, simply move the /errors virtual directory to run in the same application pool as the site for which it serves the custom error.
The second way is to make use of a registry key provided by IIS 6.0. This registry key makes sure IIS 6.0 does not check the metadata during the execution of the custom error and therefore allowing this to work.
See the article for information on the registry key fix.
It may also mean that you are using something along the lines of Server.Transfer to a page that is in a different AppPool.
It could be because you're using different versions of ASP.NET for one or many apps in the pool.
Make sure all apps in the pool use the same version of ASP (e.g. ASP 2.0.50727)
If you just added a new app, try changing the app momentarily to a different version of ASP, then back to same version. I experienced an issue where the displayed version was correct, but under the hood, a different version was used!
Check your event log, under Application, to get more details about the error.
The message would be caused by your page server-side redirecting to a page served by another application pool. Such as for example, in your link, the error page.
I know this is an old thread, but I stumbled upon it and found a different solution. Here's what worked for me: Make sure your application handles .asmx files correctly
From IIS:
Right Click on your project > Properties > Configuration
If necessary, add the .asmx file extension that maps to the aspnet_isapi.dll
Limit to: "GET,HEAD,POST,DEBUG" and restart.
Because I can't comment on vcsjones's answer, I'll add it down here. The DWORD value IgnoreAppPoolForCustomErrors needs to be set under HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\ Parameters vs HKLM\SYSTEM\CurrentControlSet\Services\W3SVC referenced in that technet article. Set it to 1 and do an iisreset and you're good to go.
Source Blog Post
In my particular case, I received this error while trying to serve a content (non ASP.NET) website while it was an Application. Right-Clicking the virtual folder and removing the application fixed it for me.
In my case the application used the application pool that didn't exist. I have no idea how it's happened.