Custom error pages iis

19 Feb 2017

If you are a .NET web developer you must have played around with exception handling in a website. I certainly have and most of the times it has not been a easy exercise. There just seem to be to many levels of exception handling. And too many ways to notify the user that something went wrong. New (ok, some not so new anymore) technologies like MVC.NET, IIS integrated mode and .NET CORE adding their own options. What I won’t be talking about is how to catch and handle exceptions in code here, I will focus on ways to display exception information to the user with customized error pages.

What is a good error page

A good error page should display all the necessary information about what went wrong and if possible what the user can do to fix the problem. With necessary information I mean just enough information to describe to the average user what the problem is, so don’t flood the user with technical details like SQL query xxx on database yyyy failed due to a primary key violation. No average user of any website does need that kind of information (except if your average user is the developer of the site, but in that case you have another problem). A better message would be something like Your account could not be created, please try again. If the problem persists contact us at xxx-yyy. Besides the fact that your users don’t need the technical details, it can also pose a big security problem when you expose those details to the public. So just don’t.

It is also good practice to supply the user with options to either fix the problem or help them find a workaround. An example of this is an Internal Server Error (code 500) caused by an timeout, in this case you could tell the user to try again in x minutes. Another example is a Page Not Found (code 404) error, here it is good practice to give the user alternative links to pages that he might be looking for (this can sometimes be done by taking a closer look at the URL requested). If it its not possible to determine what the user was looking for you could just supply a link to your search page or to the first valid parent page of the requested URL. If you really want to help your users as best as possible, supply options on your error pages to contact you, either by mail, phone, chat or what other options work best for you. Last but not least you could add an unique Id to your error pages and display it to the user. This Id should allow you to get all available technical details from your logs. If a user supplies this Id to you when he contacts you about an error on your site you can easily retrieve all details you need to identify (and hopefully fix) the exact problem.

How to display an error page

Now that we have determined what our error pages should contain we need to tell our application how and when to use them. In a .NET web application (I’m leaving out .NET Core for the time being) you roughly have the following options:

1. Using CustomErrors section via web.config
2. Using HttpErrors section via web.config
3. Routing to a custom error page from code

1. Using CustomErrors section via web.config

The CustomErrors section in the web.config has been around for some time. It is part of the system.web section.
It handles unhandled exceptions which are thrown in the .NET code of your application and routes the requests which caused the exception to custom pages based on the status code of the error. You can set different pages for each error status code (>= 400). Usually the CustomErrors section looks something like this:

<customErrors mode="RemoteOnly" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx">
      <error statusCode="500" redirect="~/500.aspx" />
      <error statusCode="400" redirect="~/400.aspx" />
      <error statusCode="404" redirect="~/404.aspx" />
</customErrors>

mode attribute

The mode attribute can have one of three values:

• Off
• On
• RemoteOnly

Off disables displaying the custom error pages, in this case the default ASP.NET detailed error pages are always shown.
On always displays your custom error pages. RemoteOnly only shows your custom pages if the request comes from a remote server and not from the server itself, this in the recommended setting, although for testing your custom pages in your development environment you will want to use the On setting.

redirectMode attribute

This attribute has only 2 values:

• Redirect
• ResponseRewrite

Redirect does as it says and redirects your request to the URL you set in the redirect attribute of your custom error page. I would not recommend using this setting. The redirect might confuse the user (changing the URL), and is not a good idea from a SEO perspective. The better option is the ResponseRewrite, this renders the result of your given custom error page without changing the URL. This option has a catch however. The final response returns a statuscode 200. Your error page should always return the appropriate statuscode to the client. To fix this the easiest solution is to use a .ASPX page as your error page (yes, also when using a MVC application) and set the response status code manually in the code(behind) of this .ASPX.

<% Response.StatusCode = 500; %>

defaultRedirect attribute

Sets a default page for all errors for which you have not explicitly set a custom page, if you would get an error with status code 401 and you have not set a specific error page for this, the default page is used. It is advisable to always set this value.

2. Using HttpErrors section via web.config

Since the introduction of IIS Integrated Mode in IIS 7, we have another option to display custom error pages. Through the httpErrors section (under system.webServer) you can configure the IIS integrated mode error handling. The main difference with ASP.NET CustomErrors is the fact that httpErrors can handle all errors that occur in the entire request pipeline, not just in the ASP.NET code. This means that when something goes wrong while requesting a static resource (like an image) your custom error page will also be shown for this request. The config section for httpErrors normally looks like this:

<httpErrors errorMode="Custom" existingResponse="Auto" defaultResponseMode="ExecuteURL" defaultPath="/error.aspx">
      <clear />
      <error statusCode="500" path="/500.aspx" />
      <error statusCode="404" path="/404.aspx" />
</httpErrors>

Within the httpErrors section you can add different paths to error pages for specific status codes, just like with CustomErrors. You should first clear all error pages before you add your own. On the root httpErrors element the most important attributes are the following:

errorMode attribute

This attributes works like the mode attribute of CustomErrors, it has 3 values Custom, Detailed and DetailedLocalOnly. You will usually use either Custom or DetailedLocalOnly, the first always displaying your own custom error pages, the second one only when the request is coming from a remote source.

existingResponse attribute

This attribute determines what should be done with the original response. If the response has an error status code (code >= 400) the httpErrors section could handle it. With this attribute you set whether httpErrors actually should handle it. There are 3 options here, Auto, Passthrough and Replace. Passthrough lets the response pass through untouched, not displaying any error page. Replace always displays a (custom or detailed) errorpage in case of een error statuscode. The Auto option is a little fussy, it chooses between Passthrough and Replace based on whether a flag called SetStatus is true or false. This flag seems to correspond with the TrySkipIisCustomErrors property of the HttpResponse object in ASP.NET. More on this later.

defaultResponseMode attribute

With this attribute you set how the request pipeline routes to a custom error page. Again 3 options, File, ExecuteUrl and Redirect. File simply displays the content of the file you supply. ExecuteUrl actually executes the code under the given local URL, with this option you can use .ASPX files or other executable code. Redirect does as it claims and redirects the client to the givens URL, best not to use this option.

defaultPath attribute

Sets the default path for errors with a status code which has not been explicitly assigned a path. Works just like the defaultRedirect attribute of CustomErrors.

error element

The error element has only 2 required attributes, statusCode and path. Both attributes need little explaining. Keep in mind though that path should be set to either a filepath or a URL path depending on the setting of the defaultResponseMode attribute of the httpErrors element. You can also set the response mode at the error element level instead of at the httpErrors element level. Use the responseMode attribute for this.

How httpErrors handles errors

One of the big catches with httpErrors seems to be that while CustomErrors handles actual (.NET) exceptions, httpErrors handles status codes. This last functionality has given me some problems when I was working on a site which switched from IIS classic to integrated mode. Switching to integrated mode enabled the httpErrors functionality. This had some unexpected side effects with some of the handlers we were using in the site. Many handlers where designed to return a 500 statuscode and some JSON data in the response body whenever something went wrong. The httpErrors functionality picked up on those 500 status codes and started to display Html error pages in stead of the JSON result. It took me some time to figure this out and some more time to find a good fix.

The default settings of httpErrors set the existingResponse attribute to Auto which means for all responses returning an error status code the original response will be substituted with either a custom error page or a detailed IIS error page. Only if you explicitly set the TrySkipIisCustomErrors property of the response in ASP.NET to true the original response will remain untouched. I our case we had to set this property to true in all handlers which set the statuscode for the response to 500. The alternative would have been to disable the httpErrors entirely by setting the existingResponse property to Passthrough, this was not desirable for our site however.

Bypassing CustomErrors

HttpErrors could be a good replacement for CustomErrors, it handles all possible errors, not just those raised in .NET code. However, if you just set the mode property of CustomErrors to Off your site will (whenever an exception is thrown) display detailed ASP.NET error pages, not your httpError pages. CustomErrors seems to bypass httpErrors by setting TrySkipIisCustomErrors to true. The easiest fix for this is setting the existingResponse attribute of httpErrors to Replace. This would mean however that all response which do not throw an exception but do return an error status code will display a httpErrors error page instead of the original response. As mentioned earlier this might not always be desirable. An alternative solution is tweaking your global.asax to just return a 500 status code whenever an exception is thrown and not pass the exception itself.

void Application_Error(object sender, EventArgs e)
{
    Exception error = Server.GetLastError();

    // TODO : Log Exception

    Server.ClearError();

    var httpException = error as HttpException;
    Response.StatusCode = httpException != null ? httpException.GetHttpCode() : (int)HttpStatusCode.InternalServerError;
}

3. Routing to a custom error page from code

Apart from the 2 options to route to custom error pages through web.config settings, there are a few options to do the same from code. I won’t explain these option in depth here, but just do a quick summary.

Using MVC Error attributes

You can add the HandleError attribute to actions you want to have custom error pages in the event of an exception.

[HandleError()]
public ActionResult Index()
{
}

All exceptions within the action are routed to the default Error.cshtml view. You can add a different view by setting the View parameter of the HandleError method, like this HandeError(View="500.cshtml"). HandleError only works if CustomErrors is not set to Off in your web.config.

Overriding the OnException method on a MVC controller

For individual controllers or for a base controller (if you have one) you can override the OnException method.

protected override void OnException(ExceptionContext filterContext)
{
    filterContext.ExceptionHandled = true;
             
    filterContext.Result = new ViewResult
    {
        ViewName = "~/Views/Error/500.cshtml"
    };
}

Using the Application_Error event

This is an event you can add in your Global.asax, it handles all exceptions which have not been handled at an earlier stage.

protected void Application_Error(object sender, EventArgs e)
{
    var raisedException = Server.GetLastError();

    // TODO : Log Exception

    Server.ClearError();

    Server.Transfer("~/500.aspx");
}

Using a HttpModule

If you add a HttpModule to your request pipeline you can build your error handling into this module. Many 3rd party error handling extensions like Elmah use this technique.

public class ErrorModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.Error += OnError;
    }

    private void OnError(object sender, EventArgs e)
    {
        // Handle error here, log, redirect or alter response
    }

    public void Dispose()
    {
        // TODO : Dispose
    }
}

Conclusion

From the techniques discussed httpErrors seems to have the best papers. It works for all requests, even for static files. CustomErrors has little to no use cases which httpErrors can’t handle. MVC error pages are very easy to use but can only handle errors from within controllers, not in other parts of the code and not for static files. Error handling in Global.asax or in a HttpModule are good options, because they catch all exceptions anywhere in your code. But they still won’t handle errors with static files (although you could configure all files, including static files, to pass through a custom HttpModule and thus handle errors for static files that way). But if you want to easily handle all errors for all request and maintain your custom errorpages in a single place, httpErrors is in most cases your best option. You do have to tweak to get it working properly (bypassing customErrors, fixing possible issues with handlers which should not display a custom html error page, etc.). Keep in mind though that in many cases custom error pages can be avoided altogether. Many site sites still return a full blown custom error page in situations like invalid user input in a form. Such cases should be handled by showing the user which field is invalid within the form not by routing to a custom error page. If you do have to route to a custom error page, try to provide the user with just enough information to help him on his way (‘try again later’, ‘maybe the following links are helpfull…’, ‘if the problem persists contact us at …’). Getting the right texts can be a challenge. In the end better custom error pages make your customer happy and can reduces calls to your service desk. Errors are bad but if they do happen, make them as clear and helpful as possible…

• Instructions document for Hardening
  • Disable Directory Browsing in IIS
  • Disable OPTIONS and TRACE METHOD in IIS and Enable Get / Post / Head.
  • Enable X-Frame-Options in IIS.
  • Enable XSS-Protection in IIS.
  • Configure Custom Error pages in IIS.
  • Implement Secure Referrer Policy
  • Enable Content-Security-Policy in IIS.
  • Enable Stirct-Transport-Security in IIS. HSTS
  • Enable X-Content-Type-Options in IIS.
  • Suppress Web Server in IIS.
  • Remove ASP.NET Version, Server Verion and Other un wanted headers.
  • Remove ASP.NET 4.5
  • Disable ASP.NET debug feature (http-asp-dot-net-debug)
  • Modify the Web.config File
  • Modify the Machine.config File
  • Removing X-Powered-By Header.
  • Disable Default IIS document in IIS.
  • Cookies (Secure only / Http only)
  • Secure Cookies with root path
  • Check your headers.
  • Security Headers
  • Disable ViewState in Asp.NET Pages
  • Host Header Remediation
  • Content Security Policy
  • References:
  • CORS — Cross Origin Resource Sharing.
  • Microsoft IIS Tilde Vulnerability

Table of contents generated with markdown-toc

Table of contents generated with markdown-toc

Instructions document for Hardening

Disable Directory Browsing in IIS

1. Open IIS manager and navigate to the level you to manage
2. In features view ,double click Directory browsing
3. In the Actions pane, click Disable if the Directory Browsing feature is enabled.

Disable OPTIONS and TRACE METHOD in IIS and Enable Get / Post / Head.

1. Open IIS manager and navigate to the level you to manage
2. In features view ,double click Request Filtering
3. Click the HTTP VERBS. Remove all the VERBS one by one.
4. Under ALLOW VERB, add «GET», «POST», «HEAD»
5. Under DENY VERB, add «OPTIONS», «TRACE», «PATCH», «PUT», «DELETE»
6. Run Command line from Administrator and then issue «IISRESET» to restart the IIS

Enable X-Frame-Options in IIS.

1. Open Internet Information Services (IIS) Manager. START > RUN > inetmgr
2. In the Connections pane on the left side, expand the Sites folder and select the site that you want to protect.
3. Double-click the HTTP Response Headers icon in the feature list in the middle.
4. In the Actions pane on the right side, click Add.
5. In the dialog box that appears, type X-Frame-Options in the Name field and type SAMEORIGIN or DENY in the Value field.
6. Click OK to save your changes.
7. Run Command line from Administrator and then issue «IISRESET» to restart the IIS

Enable XSS-Protection in IIS.

1. Open Internet Information Services (IIS) Manager. START > RUN > inetmgr
2. In the Connections pane on the left side, expand the Sites folder and select the site that you want to protect.
3. Double-click the HTTP Response Headers icon in the feature list in the middle.
4. In the Actions pane on the right side, click Add.
5. In the dialog box that appears, type X-XSS-Protection in the Name field and type 1; mode=block in the Value field.
6. Click OK to save your changes.
7. Run Command line from Administrator and then issue «IISRESET» to restart the IIS

Configure Custom Error pages in IIS.

Follow the Steps listed in this link.
https://docs.microsoft.com/en-us/iis/configuration/system.webserver/httperrors/

1. In the Connections pane, expand the server name, expand Sites, and then navigate to the Web site or application that you want to configure custom error pages for.
2. In the Home pane, double-click Error Pages.
3. In the Actions pane, click Add…
4. In the Add Custom Error Page dialog box, under Status code, type the number of the HTTP status code for which you want to create a custom error message.
5. In the Response Action section, do one of the following:
   a. Select Insert content from static file into the error response to serve static content, for example, an .html file, for the custom error.
   b. Select Execute a URL on this site to serve dynamic content, for example, an .asp file for the custom error.
   c. Select Respond with a 302 redirect to redirect client browsers to a different URL that contains the custom error file.
6. In the File path text box, type the path of the custom error page if you chose Insert content from static file into the error response or the URL of the custom error page if you use either the Execute a URL on this site or Respond with a 302 redirect, and then click OK.

One command line for this work to be performed is

appcmd.exe set config -section:system.webServer/httpErrors /+"[statusCode='404',subStatusCode='5',prefixLanguageFilePath='%SystemDrive%inetpubcusterr',path='404.5.htm']" 
/commit:apphost

Implement Secure Referrer Policy

The documentation for Referrer policy is @ https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy. It should be implemented using HTTP Headers.

1. Open Internet Information Services (IIS) Manager. START > RUN > inetmgr
2. In the Connections pane on the left side, expand the Sites folder and select the site that you want to protect.
3. Double-click the HTTP Response Headers icon in the feature list in the middle.
4. In the Actions pane on the right side, click Add.
5. In the dialog box that appears, type Referrer-Policy in the Name field and type strict-origin-when-cross-origin in the Value field. One could also choose required values from the documentation provided above.
6. Click OK to save your changes.
7. Run Command line from Administrator and then issue «IISRESET» to restart the IIS

Alternatively, one could choose to edit the relevant Web.Config file add these header.

Enable Content-Security-Policy in IIS.

1. Open Internet Information Services (IIS) Manager. START > RUN > inetmgr
2. In the Connections pane on the left side, expand the Sites folder and select the site that you want to protect.
3. Double-click the HTTP Response Headers icon in the feature list in the middle.
4. In the Actions pane on the right side, click Add.
5. In the dialog box that appears, type Content-Security-Policy in the Name field and type default-src ‘none’; script-src ‘self’; connect-src ‘self’; img-src ‘self’; style-src ‘self’; in the Value field.
   NOTE: The Content Security Policy is the Starter Policy for any application. It is generally recommended to add a custom Content Security Policy as per needs.
6. Click OK to save your changes.
7. Run Command line from Administrator and then issue «IISRESET» to restart the IIS

Links to Read
https://content-security-policy.com/
https://rehansaeed.com/content-security-policy-for-asp-net-mvc/
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

Enable Stirct-Transport-Security in IIS. HSTS

1. Open Internet Information Services (IIS) Manager. START > RUN > inetmgr
2. In the Connections pane on the left side, expand the Sites folder and select the site that you want to protect.
3. Double-click the HTTP Response Headers icon in the feature list in the middle.
4. In the Actions pane on the right side, click Add.
5. In the dialog box that appears, type Strict-Transport-Security in the Name field and type max-age=31536000; includeSubDomains in the Value field.
6. Click OK to save your changes.
7. Run Command line from Administrator and then issue «IISRESET» to restart the IIS

Also, the following XML could be added in for Re-Direction from HTTP to HTTPS.

<httpProtocol>
    <customHeaders>
      <!-- SECURITY HEADERS - https://securityheaders.io/? -->
      <!-- Protects against Clickjacking attacks. ref.: http://stackoverflow.com/a/22105445/1233379 -->
      <!-- Protects against MIME-type confusion attack. ref.: https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers/ -->
      <add name="Referrer-Policy" value="strict-origin" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

<system.webServer>
        <httpRedirect enabled="true" destination="https://MachineName.DomainName.com/URI" httpResponseStatus="Permanent" />
</system.webServer>

HSTS Header could also be added in Web.Config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpProtocol>
            <customHeaders>
                <add name="Strict-Transport-Security" value="max-age=31536000" />
            </customHeaders>
        </httpProtocol>
    </system.webServer>
</configuration>

Read this link for more information.

https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts#:~:text=HTTP%20Strict%20Transport%20Security%20(HSTS)%2C%20specified%20in%20RFC%206797,contacted%20only%20through%20HTTPS%20connections.

Enable X-Content-Type-Options in IIS.

1. Open Internet Information Services (IIS) Manager. START > RUN > inetmgr
2. In the Connections pane on the left side, expand the Sites folder and select the site that you want to protect.
3. Double-click the HTTP Response Headers icon in the feature list in the middle.
4. In the Actions pane on the right side, click Add.
5. In the dialog box that appears, type X-Content-Type-Options in the Name field and type nosniff in the Value field.
6. Click OK to save your changes.
7. Run Command line from Administrator and then issue «IISRESET» to restart the IIS

Suppress Web Server in IIS.

1. Open Internet Information Services (IIS) Manager. START > RUN > inetmgr
2. In the Connections pane on the left side, expand the Sites folder and select the site that you want to protect.
3. Double-click the HTTP Response Headers icon in the feature list in the middle.
4. Confirm if there is a Header by the name of SERVER.
5. Remove it by clicking REMOVE from the actions pane
6. Run Command line from Administrator and then issue «IISRESET» to restart the IIS

Remove ASP.NET Version, Server Verion and Other un wanted headers.

Detailed instructions provided here.
https://blog.insiderattack.net/configuring-secure-iis-response-headers-in-asp-net-mvc-b38369030728

Remove ASP.NET 4.5

1. Open the Web.Config file,
2. find the node under <system.web>
3. add the enableVersionHeader attribute to httpRuntime node and set it to false.

Disable ASP.NET debug feature (http-asp-dot-net-debug)

Detailed instructions are @ https://support.microsoft.com/en-us/help/815157/how-to-disable-debugging-for-asp-net-applications

To disable debugging, modify either the Web.config file or the Machine.config file, as detailed in the following steps.

Modify the Web.config File

To enable debugging, add the compilation element to the Web.config file of the application. The Web.config file is located in the application directory. To do this, follow these steps:

1. Open the Web.config file in a text editor such as Notepad.exe. Web.config file is typically located in the application directory.

2. In the Web.config file, locate the compilation element. Debugging is enabled when the debug attribute in the compilation element is set to true.

3. Modify the debug attribute to false, and then save the Web.config file to disable debugging for that application.

   The following code sample shows the compilation element with debug set to false:

   <compilation 
       debug="false"
   />
   

4. Save the Web.config file. The ASP.NET application automatically restarts.

Modify the Machine.config File

You can also enable debugging for all applications on a system by modifying the Machine.config file. To confirm that debugging has not been enabled in the Machine.config file, follow these steps.

1. Open the Machine.config file in a text editor such as Notepad.exe. The Machine.config file is typically located in the following folder:
   %SystemRoot%Microsoft.NETFramework%VersionNumber%CONFIG
2. In the Machine.config file, locate the compilation element. Debugging is enabled when the debug attribute in the compilation element is set to true.
   If the debug attribute is true, change the debug attribute to false.
3. The following code sample shows the compilation element with debug set to false:

<compilation 
  debug="false"
/>

1. Save the Machine.config file.

Removing X-Powered-By Header.

1. Open the Web.Config file,
2. find the node under the <system.webServer> node.
3. Check whether these is a child node under called . By default in MVC, you will not see this customHeaders child node. If it does not exist, create a node and add following include following to remove X-Powered-By header.

<httpProtocol> 
 <customHeaders> 
  <remove name="X-Powered-By"/>
 </customHeaders> 
</httpProtocol>

Disable Default IIS document in IIS.

1. In Run, type “inetmgr”. This will open IIS.
2. Go to Sites | Default Web Site and select Default Document property.
3. Double click on Default Document property. This will open Default document pages.
4. Right click on Default.htm page and click on disable.

From https://www.greytrix.com/blogs/sagecrm/2013/03/29/how-to-restrict-users-from-accessing-default-iis-page-and-virtual-directory/
and
https://docs.microsoft.com/en-us/iis/web-hosting/web-server-for-shared-hosting/default-documents

Cookies (Secure only / Http only)

The application cookies needs to be set as SECURE and HttpOnly Flag. The following line is to be added in Web.Config to make the Cookies Secure.
The line below is quite relaxed, but will make the cookies Secure and HTTPOnly.
Add this line within Web.config within <system.web>:

<httpCookies httpOnlyCookies="true" requireSSL="true" />

Secure Cookies with root path

Root path is generally added in cookies to make cookies for that particular path / domain. Best approach is to use the path directive and domain directive.

<httpCookies httpOnlyCookies="true" requireSSL="true" path="/" domain="xyz.*.com" />

Read the following links for further understanding

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie
https://wiki.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)
https://headmelted.com/securing-asp-net-cookies-a1e1b1648ed

Check your headers.

Lastly check your headers from https://securityheaders.io/.

Read more about it here.

https://www.troyhunt.com/shhh-dont-let-your-response-headers/
https://blogs.msdn.microsoft.com/varunm/2013/04/23/remove-unwanted-http-response-headers/

Also, search for the httpRuntime string in Web.Config and set the attribute enableVersionHeader it to FALSE.

<system.web>
  <httpRuntime enableVersionHeader="false" />
</system.web>

One could also follow along this link to remove un wanted Server header.
https://blogs.msdn.microsoft.com/varunm/2013/04/23/remove-unwanted-http-response-headers/

Security Headers

Security Headers provide a very powerful way to further harden your Web application. The following Security Headers should be added in your applications Web.Config file.

<! — Start Security Headers →
 <httpProtocol>
 <customHeaders>
 <add name=”X-XSS-Protection” value=”1; mode=block”/>
 <add name=”Content-Security-Policy” value=”default-src ‘self’”/>
 <add name=”X-frame-options” value=”SAMEORIGIN”/>
 <add name=”X-Content-Type-Options” value=”nosniff”/>
 <add name=”Referrer-Policy” value=”strict-origin-when-cross-origin”/>
 <add name=”Cache-Control" value="no-store, no-cache, must-revalidate"/>
 <remove name=”X-Powered-By”/>
 </customHeaders>
 </httpProtocol>
 <! — End Security Headers →

Disable ViewState in Asp.NET Pages

1. Open desired Web.Config file and go to <system.web> tag.
2. Add the following tag in <system.web>

<system.web>
 <page enableViewStateMac="true" viewStateEncryptionMode="Always">
 </pages> 
</system.web>

or

<system.web>
<pages enableViewState="false" />
</system.web>

1. ReStart the Webserver by issuing «cmd» from command line and issues «IISRESET» from Administrator command prompt.

Host Header Remediation

Host Header detailed description about what is it and how it is exploited can be seen at the URL.
https://www.acunetix.com/blog/articles/automated-detection-of-host-header-attacks/

For remediation on IIS, follow the below steps.

1. In IIS, click the Website you need to change.
2. In the ACTIONS Tab, click BINDINGS
3. Click ADD or Choose the list item and click EDIT.
4. Make sure, you specify the HostName to Website or Domain name being called.
5. Choose SSL Certificate as per need. Normally you would choose the Certificate binded with your Website.
6. Click OK to close this dialog box
7. Repeat Steps 3 to 6 if you want another HOST Header. Normally, you would choose this if you have a one Website, and you would like to call it by different URLs.
8. Click Close to finish off the settings and
9. Got to Command line by «Windows + R» followed by type «CMD».
10. Type «IISRESET» to restart the IIS with the new settings.

PS: Command line for the same is
appcmd set site /site.name:»digicert.com» /+bindings.[protocol=’https’,bindingInformation=’*:443:digicert.com’]

Image URL
https://cdn-images-1.medium.com/max/800/1*3AgIok349W9tvYMrnSdPww.png

Content Security Policy

Content Security Policy is the header which is applied in applications. With this policy in place, application developers could enable / disable many areas of their Web site to be executed in browser environment. Things like Links, Cross Links, Images, JavaScripts, resources lying in their server and / or in partner’s Servers. In other words, it allows to define a policy to run on major browsers, which will be a defense mechanism for Websites.

More details here. https://content-security-policy.com/

For remediation on IIS, follow the below steps.

1. Open Internet Information Services (IIS) Manager. START > RUN > inetmgr

2. In the Connections pane on the left side, expand the Sites folder and select the site that you want to protect.

3. Double-click the HTTP Response Headers icon in the feature list in the middle.

4. In the Actions pane on the right side, click Add.

5. Add the following key value pairs one by one repeating 4 and 5.

   Content-Security-Policy
   default-src ‘self’; connect-src ‘self’; font-src ‘self’; img-src ‘self’; script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’; style-src ‘self’ ‘unsafe-inline’; object-src ‘none’

   X-Content-Security-Policy
   default-src ‘self’; connect-src ‘self’; font-src ‘self’; img-src ‘self’; script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’; style-src ‘self’ ‘unsafe-inline’; object-src ‘none’

   X-WebKit-CSP
   default-src ‘self’; connect-src ‘self’; font-src ‘self’; img-src ‘self’; script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’; style-src ‘self’ ‘unsafe-inline’; object-src ‘none’

6. Click OK to save your changes.

7. Run Command line from Administrator and then issue «IISRESET» to restart the IIS

PS: Command line for the same is
appcmd set site /site.name:»digicert.com» /+bindings.[protocol=’https’,bindingInformation=’*:443:digicert.com’]

This is how Security headers are added in Code.

app.UseHsts(hsts => hsts.MaxAge(365).IncludeSubdomains());
app.UseXContentTypeOptions();
app.UseReferrerPolicy(opts => opts.NoReferrer());
app.UseXXssProtection(options => options.EnabledWithBlockMode());
app.UseXfo(options => options.Deny());

app.UseCsp(opts => opts
.BlockAllMixedContent()
.StyleSources(s => s.Self())
.StyleSources(s => s.UnsafeInline())
.FontSources(s => s.Self())
.FormActions(s => s.Self())
.FrameAncestors(s => s.Self())
.ImageSources(s => s.Self())
.ScriptSources(s => s.Self())
);
//End Security Headers

References:

https://medium.com/@shehackspurple/security-headers-1c770105940b
https://damienbod.com/2018/02/08/adding-http-headers-to-improve-security-in-an-asp-net-mvc-core-application/

CORS — Cross Origin Resource Sharing.

Cross-origin resource sharing (CORS) is a browser mechanism which enables controlled access to resources located outside of a given domain. It extends and adds flexibility to the same-origin policy (SOP). However, it also provides potential for cross-domain based attacks, if a website’s CORS policy is poorly configured and implemented. CORS is not a protection against cross-origin attacks such as cross-site request forgery (CSRF).

One could the following CORS headers in IIS and / or webserver of their choice. The following are the types of CORS Headers, which should be used.

Access-Control-Allow-Origin: http://foo.example

Access-Control-Allow-Methods: POST, GET, OPTIONS

Access-Control-Allow-Headers: X-PINGOTHER, Content-Type

Access-Control-Max-Age: 86400

Access-Control-Allow-Credentials: true

Access-Control-Expose-Headers: None

Access-Control-Request-Method: POST, GET, OPTIONS

Access-Control-Request-Headers: X-PINGOTHER, Content-Type

The other options are self explanatory, but Access-Control-Max-Age gives the value in seconds for how long the response to the preflight request can be cached for without sending another preflight request. In this case, 86400 seconds is 24 hours.

Do the following to add your required CORS Headers in IIS.

1. Open Internet Information Service (IIS) Manager
2. Right click the site you want to enable CORS for and go to Properties
3. Change to the HTTP Headers tab
4. In the Custom HTTP headers section, click Add
5. Enter Access-Control-Allow-Origin as the header name
6. Enter * as the header value
7. Click Ok twice

Alternatively, the following snippet of WebConfig can be dropped in related WebConfig of IIS.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <cors enabled="true" failUnlistedOrigins="true">
            <add origin="https://daraz.com" />
            <add origin="https://microsoft.com"
                 allowCredentials="true"
                 maxAge="120"> 
                <allowHeaders allowAllRequestedHeaders="true">
                    <add header="header1" />
                    <add header="header2" />
                </allowHeaders>
                <allowMethods>
                     <add method="POST" />
                     <add method="GET" />
                     <add method="OPTIONS" />
                </allowMethods>
                <exposeHeaders>
                    <add header="header1" />
                    <add header="header2" />
                </exposeHeaders>
            </add>
            <add origin="http://*" allowed="false" />
        </cors>
    </system.webServer>
</configuration>
                                                  

References, Reading Material is here.

https://portswigger.net/web-security/cors
https://portswigger.net/web-security/cors/access-control-allow-origin
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
https://www.w3.org/wiki/CORS_Enabled#For_IIS7
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
https://docs.microsoft.com/en-us/iis/extensions/cors-module/cors-module-configuration-reference

Microsoft IIS Tilde Vulnerability

This is a very old vulenrability and detailed write up is documented at https://support.detectify.com/support/solutions/articles/48001048944-microsoft-iis-tilde-vulnerability
The remidiation is as follows

1. Discard all web requests using the tilde character
2. Open Registry editor by doing START > Run, followed by «RegEdit».
3. add a registry key named NtfsDisable8dot3NameCreation to HKLMSYSTEMCurrentControlSetControlFileSystem.
4. Set the value of the key to 1 to mitigate all 8.3 name conventions on the server.