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>
Related
I have this webservice URL: http://www.example.com/service.svc/whatever
Because that endpoint does not exist I get the a page with message:
Endpoint not found. Please see the service help page for constructing
valid requests to the service.
How can I disable that page? Or even better: redirect to an error page?
You can setup a custom error in your web.config you can make that page redirect them to anywhere you would like or an error page you prefer.
<system.web>
<customErrors mode="On" defaultRedirect="Home/Error" />
//Other web.config default settings
</system.web>
OR alternatively, if you want specific pages for specific errors:
<customErrors mode="On">
<error statusCode="404" redirect="~/404.html"/>
</customErrors>
and so on, for each code.
I have a .Net website with custom error pages configured using the web.config httpErrors section:
<httpErrors errorMode="Custom" existingResponse="Replace">
<clear/>
<error statusCode="400" path="/page-not-found/" responseMode="ExecuteURL" />
<error statusCode="404" path="/page-not-found/" responseMode="ExecuteURL" />
<error statusCode="500" path="/error/" responseMode="ExecuteURL" />
</httpErrors>
and
<httpRuntime requestValidationMode="2.0" targetFramework="4.5" />
When I visit http://www.example.com/< the site displays the correct "page not found" page, however if I visit http://www.example.com/<a it displays a YSOD with a 500 status code response header.
I have Elmah hooked up and both URLs predictably throw exactly the same error System.Web.HttpException: A potentially dangerous Request.Path value was detected from the client (<).
But why are the two URLs not handled the same? Why is one rewritten to my custom error page, and the other not? I would expect the same behaviour from any exception.
Edit:
I should have mentioned up front that this was an Umbraco project. I thought that this wasn't a contributing factor but I created a barebones .Net project with no dependencies and this worked as expected, i.e. both URLs obeyed the httpErrors configuration. So this must be something Umbraco specific, probably a module.
The validate helper method first calls validation for input and then paths.
The default values that are set in the default configuration for the validate helper method when validating input from the default web.config setting located at "syste.web/httRuntime" requestPathInvalidCharactersArray attribute are:
<,>,*,%,&,:,\,?
source: https://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.requestpathinvalidcharacters(v=vs.110).aspx
As you can see "<" is being treated as an invalid PATH whereas "<a" would be treated as invalid INPUT and that is why you get two behaviors.
If you're curious as to how I figured this out, I just looked at the source code for the validate helper method and followed it back to the source.
[EDIT]
The ValidateInputIfRequiredByConfig Method shows it throwing a 400
[EDIT 2]
public NameValueCollection QueryString
{
get
{
this.EnsureQueryString();
if (this._flags[1])
{
this._flags.Clear(1);
this.ValidateHttpValueCollection(this._queryString, RequestValidationSource.QueryString);
}
return this._queryString;
}
}
Calls to this property hit the ValidateHttpValueCollection can validate the querystring if the validation source is Querystring, which it is in this property.
In this method there is a method called ValidateString. In ValidateString it determines if it's a valid string or not and if not it throws a HttpRequestValidationException
After a fair amount of digging, I can see that this was actually caused by a 3rd party module called ClientDependency. Removal of this and the normal behaviour returned but obviously in this case the backoffice will not function properly.
A patch on the project is required and I've submitted this.
Update:
This bug in ClientDependency has been fixed as of v1.8.3
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?
I have below code in global application error event. If there is any invalid url, this event gets fired. Is it required to log http 404 errors.
void Application_Error(object sender, System.EventArgs e)
{
Exception lastException = HttpContext.Current.Server.GetLastError();
//log exception
}
The question is quite general, but logging 404 pages is quite good for several reasons.
By logging 404 pages you can find broken links on your web site and also to see how frequent it happens, that way you can create redirects if needed.
But it's your choice of course if you want to that or not.
Most servers are configured to write 404s along with all other requests and responses to its access log.
It's on your own if you want to log this error. Errors can also be handled automaticly using web.config inside system.web section, like this:
<customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
<error statusCode="403" redirect="NoAccess.htm" />
<error statusCode="404" redirect="FileNotFound.htm" />
</customErrors>
Basicly server will automaticly redirect to declared pages on specific error number.
The answer to your question is quite simply: "No, it's not required to log 404 errors."
It is best practice to have a process in place for handling 404 errors to maximize the search engine optimization of your site, though.
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.