I need one help here. We have our site is running on windows server 2008\IIS7.5. we did PCI scan for our site today and we getting below vulnerability message.
Vulnerability : - ASP.NET Detailed Error Messages Enabled
The web server running on this host is configured to display verbose
error messages for ASP.NET applications. This could give an attacker
information about the ASP.NET applications on the server, as well
as information about the host itself. However, if you view
the source of the page, hidden at the bottom of the document is quite a
bit of debugging information that includes the path of the web server.
Service: Microsoft-IIS/7.5
Remediate Action : - It is recommended that any sort of debugging information be disabled
for production systems. Displaying custom error messages prevents
the debugging information from being provided to users. In web.config,
set the customErrors mode to "On" or "RemoteOnly" (displays
debugging information to browsers accessing the site from the local
host).
I checked our web.config and we can see below settings there
<customErrors mode="On" defaultRedirect="/ProcessError.aspx" redirectMode="ResponseRewrite">
<error statusCode="404" redirect="/PageNotFound.aspx" />
<error statusCode="500" redirect="/ProcessError.aspx"/>
</customErrors>
According to the remediation action, we have set CustomErrors mode to "On" or "RemoteOnly" . As you can see from the above web.config file it is already set to on. Not sure what other changes has to be done.
Do you have any advice?
Related
Lets start with a little background information. I am running a very simple ASP.net MVC Azure cloud service (a web role, Windows Server 2012 R2 with IIS 8.5). This service receives statistics from a flash client, which posts data roughly every 10 seconds (for potentially very large number of clients) and JavaScript. All the service contains is a single controller with two simple actions with a bunch of parameters (representing the individual statistics which are send in various combinations). All the service does is set the CORS and cookie responses (the clients/JavaScript can be embedded on random domains), verify the integrity of the received data and then store it into an Azure table storage account.
In order to ensure our service operates optimally we use New Relic to track service performance, and in order to ensure that our data is accurate (i.e. we successfully record all received messages) we implemented a custom error handling solution so we can fix any problems/bugs that might arise.
We have load tested our service using jmeter and encountered no problems, but now that we have deployed to a live environment and our service is being used we are starting to encounter occasional 500 internal server errors (approx 5% of requests). The big problem being that our own error handling code is not detecting these errors, however New Relic does report certain requests generating a 500 internal server error (with no further information like a stack trace, sometimes with, sometimes without reported parameters).
Our custom error handling consists of an HTTP module which registers to both the AppDomain.CurrentDomain.UnhandledException and the context.Error events. In theory this should be catching (and then logging) any exceptions which are not already being caught (and logged) inside our own code. Relevant web.config sections are configured in the following manner:
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/500.aspx">
<error statusCode="404" redirect="~/404.aspx" />
<error statusCode="500" redirect="~/500.aspx" />
</customErrors>
and
<httpErrors existingResponse="Replace">
<clear />
<error statusCode="404" path="404.html" responseMode="File" />
<error statusCode="500" path="500.html" responseMode="File" />
</httpErrors>
<modules>
<add type="namespace.UnhandledExceptionModule" name="UnhandledExceptionModule" preCondition="managedHandler" />
</modules>
However, this is not the case. I have tried turning on all kinds of logging but the IIS logs are useless (they only show that a 500 response was returned, but no other useful information). The only useful information I have been able to gather is from the failed request traces, but I have not been able to determine what the actual problem is from that information (googling the error code or exception leads to nothing concrete). A screenshot of the relevant section of a failed trace can be found here:
http://i57.tinypic.com/20acrip.jpg
I also uploaded the complete trace here:
http://pastebin.com/fDt3thvr
Each failed request generates exactly the same log, so the errors we are seeing are consistently being caused by the same problem. However, I am not able to determine what this problem is, let alone find a way of fixing it. Even though I have an error code and message, googling them only returns very old topics on issues that have been fixed 6 years ago.
It is pretty important for our business that these messages can be recorded with a high degree of accuracy, but as it stands now I have no further ideas on how to gain better information on what is happening on these servers. We are also not able to replicate this behavior in a controlled environment.
Also, our error logging itself does work properly. 'Normal' errors are logged as expected and we have also verified the HTTP module actually works.
Edit:
The controller pseudo code is as follows:
[HttpPost]
public ActionResult Method(...)
{
// Set cookie and CORS reponse, check for early out.
if(earlyOut)
return 404;
// Store received values.
azuretable.ExecuteAsync(TableOperation.InsertOrMerge(...));
return 200;
}
Edit2:
I have spend some time analyzing failed request traces and they mostly seem to be generated by users with IE9. I actually managed to reproduce the error 2 times by quickly leaving the page while it is loading, as the problem seems to be caused by aborted Ajax calls (which we make the most of during page load). Why would an aborted call cause a 500 error though instead of being handled neatly?
Do the cookies exceed 4k ? The same thing happened to us on IIS, and the requests sometimes ended up with 500 Internal Server error. The errors were virtually untraceable.
I reproduced the issue by simply inflating a cookie over the 4093 bytes limit.
I think that it is because you are not awaiting your async method call, or your are not returning an awaitable response. I had exactly this issue when I forgot to do that.
await azuretable.ExecuteAsync(TableOperation.InsertOrMerge(...))
Then you should be good. I think you'll find that the async call is finishing after your call has completed back to the caller.
Here is my problem.
I have one server on the other side of the world with IP 1.2.3.4
If I put in web.config this
<compilation defaultLanguage="c#" debug="true" />
everyone sees a debug, I want to set something like
<compilation defaultLanguage="c#" debug="true" IP="4.3.2.1" />
So only IP 4.3.2.1 can see debug for that site all other IPs should see like
<compilation defaultLanguage="c#" debug="false" />
is set.
The setting says how the whole page is compiled. Then in this form it is served to all clients. If you want this, you can have two sites - one normal and one debug - and if there is one particular IP requesting your site you can redirect it to the debug version.
What do you intend to do? You are fiddling with the compilation element, that is, you try to modify the compilation of your code. Code is not compiled per-request or per-user.
If you want to reveal/hide stack traces you may want to use this instead:
<customErrors mode="RemoteOnly" />
However, this does not allow to filter by IP except the loop-back. IP addresses are generally not a very secure way to identify a person or to prevent an authorized person from retrieving the stacktrace.
If you have remote access to the web server, you can log in and use http://localhost to access your web site. If you have RemoteOnly active, you will find the stacktrace of your error then.
If you still want to go for an IP-based approach, you might find something at Rich Custom Error Handling with ASP.NET. The section "Rich Custom Error Pages" mentions "Logic to display detailed information only to certain IP addresses may be included here."
(I found the article by googling for "asp.net reveal stacktrace to certain ip only")
I have three systems running on IIS7 with static IP address 192.168.66.5. I have configured the system to run on the same IP address with different ports and subdmain like;
192.168.66.5:81 hostname ams.tpf.go.tz
192.168.66.5:82 hostname gmis.tpf.go.tz
192.168.66.5:83 hostname records.tpf.go.tz
192.168.66.5:84 hostname cmis.tpf.go.tz
I configure all these on IIS7 and defined them in the router.
When the client opens ams.tpf.go.tz without specifying the port number, the error 404 is returned: the requested resource is not found.
This recently occurred to me also - make sure your IIS Website is started - mine had been stopped. This is the error I was receiving in Visual Studio:
Unable to start debugging on the web server. The web server could not find the requested resource.
Right Click on your Website (i.e. Default Website) in IIS Manager and click Manage Web Site --> Start.
Navigating to any applications in the IIS Website was showing this error:
HTTP Error 404. The requested resource is not found.
The easiest way to achieve this is to set the port 80 for the site you want to be the "default" one, since this is the default HTTP port.
Some times IIS Manager -> Manage Web Site -> Start, will not work if the below 2 services are not running
1. Windows Activation Technologies Service
2. World Wide Web Publishing Service
Start these services manually under windows services then start IIS again.
Another cause that happens to me with some frequency is to set the permissions correctly to the physical directory. It can be achieved going to IIS -> clicking on the website and then in the actions panel click over Edit Permissions. Be sure that the user you are going to assign the permissions, are the same as defined on Authentication -> Anonymous Authentication or ASP.NET Impersonation, if any of those authentication methods are enabled.
To know the user assigned on those authentication methods, go to the Authentication icon, select any of the authentication methods mentioned before, right click on it and select edit. After that, you have the option to select the user you want.
Hoping this helps.
My issue for anyone else that comes here from google. I am hosting a django website so in my webconfig file it is set to process requests using the python virtual environment. In the web.config file it is this portion:
<configuration>
<system.webServer>
<handlers>
<add name="Python FastCGI"
path="*"
verb="*"
modules="FastCgiModule"
scriptProcessor="C:\inetpub\wwwroot\receipts\venv\Scripts\python.exe|C:\inetpub\wwwroot\receipts\venv\Lib\site-packages\wfastcgi.py"
resourceType="Unspecified"
requireAccess="Script" />
</handlers>
...
</configuration>
When there was requests to the media folder IIS would say great I know what to do send it through the scriptProcessor (python processor). Requests to the media folder should not do that they only need to serve static files (no extra processing). I placed this web.config in the media directory and it solved my problem!
<configuration>
<system.webServer>
<handlers>
<!-- this configuration overrides the FastCGI handler to let IIS serve these static files -->
<clear />
<add name="StaticFile"
path="*"
verb="*"
modules="StaticFileModule"
resourceType="File"
requireAccess="Read" />
</handlers>
</system.webServer>
</configuration>
In my case IIS server and resolved with the below steps.
Check the security groups - whether we have opened the required ports from ALB SG to EC2 SG.
Login to server and check does IIS server's default site has 443 port opened if your health-check is on 443. (whatever port you are using for health checks).
Use the curl command to troubleshoot the issue.
If you would like to check on HTTPS use the below command to check the response. Use -k or --insecure to ignore the SSL issue.
curl https://[serverIP] -k
For HTTP test use the below command.
curl http://[serverIP]
I have a file upload control on my webpage. The maximum request length is set to 8 MB (maxRequestLength = 8192). I also have server validation that throws an error if the file is more than 4MB. The reason that its 8MB in the config is the leverage that's given to the user and also so that the application can be tested.
If I upload a file that's 9MB, I get thrown an exception Maximum request length exceeded., which is fine and working as expected. But when I try to upload a file that's 1GB, it shows me a HTTP 404 - File not found. Can someone please explain why this is happening and how can I get it to throw me a maxRequestLength exception?
I'm using IIS6.
I experienced this condition today (HTTP 404 on large file upload with IIS 7) but I thought I had made all the correct configuration settings. I wanted to upload files up to 300MB so I made the following web.config settings in a sub-folder of the application:
<configuration>
<system.web>
<httpRuntime maxRequestLength="307200" />
</system.web>
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="314572800" />
</requestFiltering>
</security>
</system.webServer>
</configuration>
This configuration worked in test but when I copied the updated files including the web.config to the production server, I received the HTTP 404 error on uploading a 90MB file. Smaller files under the application-wide limit of 30MB were working fine, so I knew it was a request size problem of some sort.
I figured there was a chance IIS had cached some application settings and just hadn't updated them, so I recycled the Application Pool, after which everything worked as expected.
I feel none of the answers here explain why you get a 404, they just tell you the usual stuff of how to fix the problem.
The 404 is not due to misconfiguration, it is intentional and documented behaviour:
When request filtering blocks an HTTP request because an HTTP request exceeds the request limits, IIS 7 will return an HTTP 404 error to the client and log one of the following HTTP statuses with a unique substatus that identifies the reason that the request was denied:
HTTP Substatus Description
404.13 Content Length Too Large
404.14 URL Too Long
404.15 Query String Too Long
These substatuses allow Web administrators to analyze their IIS logs and identify potential threats.
In addition, when an HTTP request exceeds the header limits that are defined in the in the <headerLimits> element, IIS 7 will return an HTTP 404 error to the client with the following substatus:
HTTP Substatus Description
404.10 Request Header Too Long
This is a bit of an old thread, but I thought I should add my experiences with this.
I faced the same problem with large file uploads and the web api. A 404.13 is thrown before it gets to a controller at all, so I had to find out where to jump in and handle this case.
My solution was the following web.config entries:
I handle the 404.13 by redirecting it to a mvc controller (it could be a webforms page just the same), and regular 404 errors hit my 404 route. it's critical that the responseMode="redirect" for the 404.13
<httpErrors errorMode="Custom">
<remove statusCode="404" subStatusCode="-1" />
<error statusCode="404" subStatusCode="13" path="/errors/filesize" responseMode="Redirect" />
<error statusCode="404" path="/errors/notfound" responseMode="ExecuteURL" />
</httpErrors>
Then, in my Errors controller, I have the following:
public ActionResult FileSize()
{
Response.StatusCode = 500;
Response.StatusDescription = "Maximum file size exceeded.";
Response.End();
return null;
}
Again, this could be a regular webforms page.
To my knowledge, there is no way to gracefully handle exceeding IIS's "maxRequestLength" setting. It can't even display a custom error page (since there is no corresponding HTTP code to respond to). The only way around this is to set maxRequestLength to some absurdly high number of kbytes, for example 51200 (50MB), and then check the ContentLength after the file has been uploaded (assuming the request didn't time out before 90 seconds). At that point, I can validate if the file <=5MB and display a friendly error.
You can also try this link.
You could also try something like this:
private void application_EndRequest(object sender, EventArgs e)
{
HttpRequest request = HttpContext.Current.Request;
HttpResponse response = HttpContext.Current.Response;
if ((request.HttpMethod == "POST") &&
(response.StatusCode == 404 && response.SubStatusCode == 13))
{
// Clear the response header but do not clear errors and transfer back to requesting page to handle error
response.ClearHeaders();
HttpContext.Current.Server.Transfer(request.AppRelativeCurrentExecutionFilePath);
}
}
I have found that this problem can also be caused on IIS7 (and presumably IIS6) when the URLScan tool is installed and running on the site.
When uploading the file to a website i was receiving the message "File or directory not found. The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable."
If the problem is being caused by URLScan then if you try to upload the large file to the site whilst browsing the site on the hosting server itself, you will be served a full asp.net error message instead of a 404 that mentions URLScan.
You can also check if URLScan is running on you site in IIS7 by viewing the ISAPI Filters for the website in IIS, URLScan will be listed if it is used.
This can be fixed by altering the ini file for URLScan is located at "%WINDIR%\System32\Inetsrv\URLscan" and changing the MaxAllowedContentLength.
The MaxAllowedContentLength is in bytes.
This may require a IIS restart to take effect, though it did not when i tried it myself with IIS7.
http://www.iis.net/learn/extensions/working-with-urlscan/urlscan-overview
http://www.iis.net/learn/extensions/working-with-urlscan/common-urlscan-scenarios
You could configure the default error page in IIS itself.
The request limit is a setting is IIS. Open the Request Filtering section of your site in IIS and select Edit Request Settings. For me it was that simple.
A more detailed How To from Microsoft.
https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/#how-to-edit-the-request-filtering-feature-settings-and-request-limits
I just met the same problem, i made the similar operation like pseudocoder's answer but have different( i think maybe is not the cache) :
edit your Web.config --> maxRequestLength
<system.web>
<httpRuntime maxRequestLength="1073741824" executionTimeout="3600" />
</system.web>
edit this:
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
</security>
just like this,and try it.
The problem with the 1GB uploads is more browser related. I have had heaps of trouble with it and tried a lot of solutions but really the question to ask here is what are the chances of this happening in the real world for your business needs and maybe it should be recorded as a known issue in the business rules or non functional requirements document.
First of all, I'm not so close and familiar with IIS7 and using it just for redirection to a weblogic application.
The backend weblogic application which I use has a login page as a starter page. When I call the page through IIS7, it redirects my requests to weblogic and I see login page. When I try to login with correct pass&user name pair everthing goes fine I can use the system without any problem. However when I try to login with wrong credentials, IIS shows me defaul 403 permission denied page instead of my weblogic applications login error page.
When I dig the problem a litte bit, I found out that weblogic replys my wrong login attempt with a 403 message which already includes weblogic applications login failed page and when IIS see 403 message, it discards the page in it and just sends me pure 403 response (I've deleted IIS's fancy 403 error message, as well)
Is there any way that iis7 to redirect all requests and responeses without processing it? Changing the reply message code of weblogic application is out of question, unfortunately.
We had an issue where IIS 7 was catching errors responses sent back by weblogic through the ISAPI filter. For example if you put the wrong log in credentials to the log in page. IIS was returning a custom 403 error page and not sending back our apps log in page in weblogic.
This is due to IIS 7 handling custom error codes and sending back its own error pages. See more info at http://www.iis.net/ConfigReference/system.webServer/httpErrors
In order to correct this behavior, we had to set the
existingResponse='PassThrough' in the httpErrors section of the web.config for the website.
I'm not sure because I do not use the IIS. It might be enough if you are modifying the paths in the web.config file as follows:
<httpErrors>
<remove statusCode="404" subStatusCode="-1" />
<error statusCode="404" prefixLanguageFilePath="" path="/index.php" responseMode="ExecuteURL" />
<remove statusCode="403" subStatusCode="-1" />
<error statusCode="403" prefixLanguageFilePath="" path="/weblogic/login.php" responseMode="ExecuteURL" />
</httpErrors>