HowTo: Add non-inheriting headers to IIS

Follow
    Applies to:
  • SecureAuth Identity Platform
  • Legacy SecureAuth IdP
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • Version Affected:  All

    Description:  

    The SecureAuth IdP does not enable Host Headers on the default website, which in turn, makes the appliances fail security audits when they are scanned by corporations.

     

    Cause:  

    No security/host headers are applied to the Default Website within IIS on an IdP Appliance.

     

    Resolution:  

    This document will explain how to set host headers on the default website in a manner that they will not get inherited by all SecureAuth realms/applications that get created on a system. To get started, one must know that the following web.config setting is what will be used when editing the Default Website's web.config file:

    <location inheritInChildApplications="false">
    </location>

    The above is going to surround anything put in the Default Website's web.config to ensure that it is not inherited by Applications running below the Default Website.

    To add custom headers edit your web.config and look for, or create, the <customHeaders> section:

    <configuration>
    <system.webServer>
    <httpProtocol>
    <customHeaders>
    ...
    </customHeaders>
    </httpProtocol>
    </system.webServer>
    </configuration>

    Once found and/or created, add the extra headers that are required:

    <configuration>
    <system.webServer>
    <httpProtocol>
    <customHeaders>
    <add name="X-Content-Type-Options" value="nosniff" />
    <add name="X-Frame-Options" value="SAMEORIGIN" />
    <add name="X-XSS-Protection" value="1; mode=block" />
    <add name="Content-Security-Policy" value="script-src 'self';"/>
    </customHeaders>
    </httpProtocol>
    </system.webServer>
    </configuration>

    Once all custom headers are added, a decision needs to be made if we want all to be inherited by all applications below the default website and then we can use our <location ...> tag to limit what gets pushed to child applications:

    <configuration>
    <system.webServer>
    <httpProtocol>
     <customHeaders>
    <location inheritInChildApplications="false">
    <add name="X-Content-Type-Options" value="nosniff" />
    <add name="X-Frame-Options" value="SAMEORIGIN" />
    <add name="X-XSS-Protection" value="1; mode=block" />
    <add name="Content-Security-Policy" value="script-src 'self';"/>
    </location>
    </customHeaders>
    </httpProtocol>
    </system.webServer>
    </configuration>

    In the above, none of the custom headers will be pushed to child sites listed below the Default Website in IIS.

    An example of excluding just a couple of custom headers would look like this:

    <configuration>
    <system.webServer>
    <httpProtocol>
    <customHeaders>
    <location inheritInChildApplications="false">
    <add name="X-Content-Type-Options" value="nosniff" />
    <add name="X-Frame-Options" value="SAMEORIGIN" />
    </location>
    <add name="X-XSS-Protection" value="1; mode=block" />
    <add name="Content-Security-Policy" value="script-src 'self';"/>
    </customHeaders>
    </httpProtocol>
    </system.webServer>
    </configuration>

    In the above, only the Content-Type-Options and the Frame-Options will not be pushed to the child sites on the IIS webserver.

     

    Special Considerations:  

    If during testing, errors are received about multiple headers, then something was added that was already part of the SecureAuth security header fixes on the IdP appliance and the web.config will need to be updated properly.

    mceclip0.png

     

    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.