Skip to content

Instantly share code, notes, and snippets.

@RJCuthbertson

RJCuthbertson/IIS Web Application Security Checklist.md

Created December 22, 2017 22:20
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save RJCuthbertson/1c95228543254c44d6f83173d38ea325 to your computer and use it in GitHub Desktop.
Save RJCuthbertson/1c95228543254c44d6f83173d38ea325 to your computer and use it in GitHub Desktop.
Download ZIP
A checklist to use as a reference tool covering some of the most common security concerns relevant to a web application hosted by IIS
Raw
IIS Web Application Security Checklist.md

IIS Web Application Security Checklist

I've been putting this checklist together as a reference tool to use prior to launching a web application that will be hosted on IIS, although the majority of these items apply to any web application where web security is a concern. This is certainly not a definitive list of every security concern a web application developer should resolve prior to going live with a site. Think of it more like a quick punch list to get you through validating that the most common security issues won't give you any problems.

General

  • Ensure application tracing is not accessible (“/trace.axd”)
  • Ensure ELMAH logs are not accessible (“/elmah.axd”)
  • If HTTP to HTTPS redirect is configured, ensure HSTS & secure cookies are configured properly (see: 95% of HTTPS servers vulnerable to trivial MITM attacks)
  • Ensure Custom Errors are On or RemoteOnly
  • Review Secure and HttpOnly cookies configuration
  • OPTIONS verb response is wrong by default in IIS (see: How does HTTP OPTIONS method determine * allowed methods in IIS 8.5?)
  • Request length limiting
    • In Web.config security/requestFiltering/requestLimits:
    • Query string length limiting (maxQueryString attribute)
    • Request body size limiting (maxAllowedContentLength attribute)
    • Header limits (headerLimits node)

Application Architecture Dependent

  • Review use of XSRF/CSRF tokens
  • Review use of sanitization of user provided data (potential XSS or SQL Injection vector)

Security Related Headers

CSP (Content-Security-Policy)

  • TODO

HSTS (Strict-Transport-Security)

  • max-age value should be > 18 days & < SSL Cert Expiration
  • includeSubDomains should be used when possible
  • Use HSTS Preloading when possible (see: HSTS Preload List Submission Form)

HTTP Public Key Pinning (Public-Key-Pins)

  • TODO

IFrame Clickjacking Prevention (X-Frame-Options)

  • Value should be DENY when possible
  • Value may be SAMEORIGIN if iframes are used on site
  • Value may be ALLOW-FROM {domain white-list} when necessary

XSS Protection (X-XSS-Protection)

  • Introduced by IE; Only supported by IE, Chrome, and Safari (last verified 09/2017)
  • Value should be “1; mode=block”
  • Not necessary in modern browsers if CSP disables “unsafe-inline” JavaScript from executing, but still good for users of older browsers that don’t fully implement CSP

Disable MIME Type Sniffing (X-Content-Type-Options)

  • Value should be “nosniff”

Referer [sic] Header Configuration (Referrer-Policy)

  • This behavior may be configured in CSP

  • If an explicit Referrer-Policy header is used, the set of safe values are:

    • no-referrer
    • no-referrer-when-downgrade (default)
    • same-origin
    • strict-origin
    • strict-origin-when-cross-origin

Application Information Leakage Headers

These headers should not be sent with any responses. They contain unnecessary information that only benefits a potential attacker.

  • The Web Server Name and / or Version (Server)
  • The Web Application Framework (X-Powered-By)
  • The ASP.NET Version (X-AspNet-Version)
  • The MVC Version (X-AspNetMvc-Version)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment