Share via

SharePoint 2016: resolving common site security scan findings

  • Article

Introduction

This posting consolidates notes on resolving various SharePoint 2016 site security scan findings.  This posting is dedicated to the SharePoint Farm Administrator who may not yet be entirely familiar with site security scans and is seeking: 1) convenient information on them, 2) guidance on how to determine whether they are true or false positives, and steps for resolving them if need be.  It focuses on using common user interfaces to implement any changes needed.  Methods presented here are based upon SharePoint 2016 hosted on virtualized Windows 2012 R2 servers.

Scan Report Findings

HTTP Strict Transport Security (HSTS) Warning

This findings involves the Strict-Transport-Security response header.  The scanner may have found some parameters missing, such as: max-age, includeSubDomains, and preload.  This finding can be easily resolved using IIS Manager to either: 1) add a new IIS site response header or 2) create a new site outbound rule using URL Rewrite. Here are the steps.  You'll need to perform these steps on each farm WFE.  See Notes below for additional useful information and guidance on this issue.

Procedure 1: Add new IIS response header

  1. Remote into a a farm WFE
  2. Launch IIS Manager
  3. In the left Connections pane, expand Sites > [target site]
  4. Select the site
  5. In the central pane, in the IIS group, double-click HTTP Response Headers.
  6. At right, in the Actions pane, click Add....
  7. Set Custom HTTP Response Header dialog properties like so
    1. Name: Strict-Transport-Security
    2. Value: max-age=31536000; includeSubDomains; preload
  8. Click OK.  The new response header configuration is written to the site's Web.Config file, automatically causing a reset of the site's application pool.
  9. Repeat for each of the other WFEs in the farm.

Procedure 2: Create new site outbound rule using URL Rewrite

  1. Remote into a farm WFE
  2. Launch IIS Manager
  3. In the left Connections pane, expand Sites > [target site]
  4. Select the site
  5. In the central pane, in the IIS group, double-click URL Rewrite. (if you don't see it, it's not loaded and you'll need to download and load it first)
  6. In the Action pane at right, click Add Rule(s)...
  7. On the Add Rule(s) popup dialog, in the Outbound rules section, select Blank rule, and then click OK.
  8. Configure settings as so:
    1. Name: HTTPS Strict Transport Security Header
    2. Precondition: <none>
    3. Matching scope: Server Variable
    4. Variable name: RESPONSE_Strict_Transport_Security
    5. Variable value: Matches the Pattern
    6. Using: Regular Expressions
    7. Pattern: ".*" (that's "dot" followed by "asterisk")
    8. Ignore case: checked
  9. Now, expand the Conditions group.
  10. Ensure Logical grouping is set to Match All
  11. Click Add...
  12. Configure Add Condition dialog settings like so:
    1. Condition input: {HTTPS}
    2. Check if input string: Matches the Pattern
    3. Pattern: on
    4. Ignore case: checked
  13. Click OK.
  14. Track capture groups across conditions: checked
  15. Expand the Action group
  16. Configure settings like so:
    1. Action type: Rewrite
    2. Action Properties: max-age=31536000; includeSubDomains; preload
    3. Replace existing server variable value: checked
    4. Stop processing of subsequent rules: unchecked
  17. Back on the Actions panel, click Apply.  The changes are then written to the site's Web.Config file, which automatically causes that IIS site application pool to recycle.
  18. Repeat for the other WFEs in the farm.

References

Notes

  • URL Rewrite rules have priority over IIS response headers.  For example, if a Strict-Transport-Security response header for the IIS site is created, and then later a URL Rewrite rule for the same response header is also created for the site, the rule will overwrite the response header.
  • Check the load balancer if you create a new response header or rule, and then don't see the change through browser dev tools, make sure you implemented the change on ALL web front ends.

SharePoint Version Disclosure Header

This finding involves the MicrosoftSharePointTeamServices IIS response header.

Procedure: create new site outbound rule using URL Rewrite

  1. Remote into a farm WFE
  2. Launch IIS Manager
  3. In the left Connections pane, expand Sites > [target site]
  4. Select the site
  5. In the central pane, in the IIS group, double-click URL Rewrite. (if you don't see it, it's not loaded and you'll need to download and load it first)
  6. In the Action pane at right, click Add Rule(s)...
  7. On the Add Rule(s) popup dialog, in the Outbound rules section, select Blank rule, and then click OK.
  8. Configure Add Rule dialog property settings as so:
    1. Name: SharePoint Version Disclosure Header
    2. Precondition: <none>
    3. Matching scope: Server Variable
    4. Variable name: RESPONSE_MicrosoftSharePointTeamServices
    5. Variable value: Matches the Pattern
    6. Using: Regular Expressions
    7. Pattern: ".*" (that's a "dot" followed by an "asterisk")
    8. Ignore case: checked
  9. Now, expand the Conditions group.
  10. Ensure Logical grouping is set to Match All
  11. Click Add...
  12. Configure Add Condition dialog property settings like so:
    1. Condition input: {HTTPS}
    2. Check if input string: Matches the Pattern
    3. Pattern: on
    4. Ignore case: checked
  13. Click OK.
  14. Track capture groups across conditions: checked
  15. Expand the Action group
  16. Configure settings like so:
    1. Action type: Rewrite
    2. Action Properties: [leave blank]
    3. Replace existing server variable value: checked
    4. Stop processing of subsequent rules: unchecked
  17. Back on the Actions panel, click Apply.  The changes are then written to the site's Web.Config file, which automatically causes that IIS site application pool to recycle.
  18. Repeat for each of the other WFEs in the farm.

References

Notes

  • As noted by Wictor Wilen in his posting on this response header, the installation of SharePoint updates followed by configuration can modify this response header and likely also recreate it if it is missing (or deleted).  Therefore, it will be more productive to resolve the issue here by creating a new rule in URL Rewrite, since merely deleting the IIS response header or modifying its value may only persist until the next software update.

ASP.NET Version Disclosure Header

This security scan finding involves the X-AspNet-Version IIS response header.  This is an auto-injected header, and there's no configuration that can be tweaked to make it go away.  It's not even listed in the IIS Response Headers panel for the site.  There are some other more complex possibilities, but the solution presented here is the simplest and employs the URL Rewrite module.

Procedure: Create new site outbound rule using URL Rewrite

  1. Remote into a farm WFE
  2. Launch IIS Manager
  3. In the left Connections pane, expand Sites > [target site]
  4. Select the site
  5. In the central pane, in the IIS group, double-click URL Rewrite. (if you don't see it, it's not loaded and you'll need to download and load it first)
  6. In the Action pane at right, click Add Rule(s)...
  7. On the Add Rule(s) popup dialog, in the Outbound rules section, select Blank rule, and then click OK.
  8. Configure Add Rule dialog property settings as so:
    1. Name: SharePoint Version Disclosure Header
    2. Precondition: <none>
    3. Matching scope: Server Variable
    4. Variable name: RESPONSE_X_ASPNET_VERSION
    5. Variable value: Matches the Pattern
    6. Using: Regular Expressions
    7. Pattern: ".*" (that's a "dot" followed by an "asterisk")
    8. Ignore case: checked
  9. Now, expand the Conditions group.
  10. Ensure Logical grouping is set to Match All
  11. Click Add...
  12. Configure Add Condition dialog property settings like so:
    1. Condition input: {HTTPS}
    2. Check if input string: Matches the Pattern
    3. Pattern: on
    4. Ignore case: checked
  13. Click OK.
  14. Track capture groups across conditions: checked
  15. Expand the Action group
  16. Configure settings like so:
    1. Action type: Rewrite
    2. Action Properties: [leave blank]
    3. Replace existing server variable value: checked
    4. Stop processing of subsequent rules: unchecked
  17. Back on the Actions panel, click Apply.  The changes are then written to the site's Web.Config file, which automatically causes that IIS site application pool to recycle.
  18. Test by connecting to the site with a browser, launching browser developer tools, and then viewing headers.  The response header will appear but its value will now be blank.
  19. Repeat for each of the other WFEs in the farm.

References

Notes

  • tbd