How HTTP security headers can defend enterprise systems
By Judith Myerson
Strong HTTP security headers are countermeasures used to protect websites from attackers. The countermeasures are part of an accreditation lifecycle and should be included in an accreditation report on an information system.
Countermeasures with lowest costs and greatest benefits are determined after assets are valuated, vulnerabilities are identified and risks are assessed as high, medium or low. After successful countermeasure implementation, economics value analysis is used to determine cost-effectiveness of the implementation over a period of time.
Here are some examples of assets valuations, vulnerabilities and risk assessments:
Asset valuations are determined by a valuation method for authorized assets. Server hardware costs are based on the value of replacement servers that send HTTP security responses. Server software costs are based on time to restore software. Personnel costs are based on the expenses of training personnel to perform administrative tasks of editing configuration files if all personnel became permanently unavailable, which is very unlikely.
Vulnerabilities are identified with a simple security control test that reports a grade on implementation of HTTP security headers for a website. The report can be obtained by scanning a website on securityheaders.io, which was founded and managed by Scott Helme. A grade of A+ indicates successful implementation of all HTTP security headers. A low grade identifies vulnerabilities due to the security headers not implemented properly or at all. Exposing sensitive information about the server to the public internet is considered a vulnerability but does not affect the overall grade because it is not connected to a security response header.
Risks are assessed for medium and high potential loss of data due to vulnerabilities of non-implementation of some or all HTTP security response headers. When no security headers are implemented, the risk is high; when all security headers are implemented the risk is low.
Countermeasures mitigate risks by preventing intentional exploitation or accidental triggering of the vulnerabilities due to improper or incomplete implementation of HTTP security response headers. Before adding or updating security headers, an administrator must remove sensitive information about which software the server is running.
Security threats that can be stopped
There are many different factors that make websites vulnerable to security threats. Some of those threats and vulnerabilities can be mitigated with proper HTTP security headers, including:
Clickjacking attacks. A user is tricked into clicking on a link on a malicious page. The solution is to implement the X-Frame-Options header to prevent a browser from embedding content into other sites via <iframe>. The value is "SAMEORIGIN".
Cross-site scripting (XSS) attacks. An attacker uses a browser to inject a malicious script into a trusted website. To block the response from the script, the X-XSS-Protection header is used. The value for this header should be set to
1; mode=block
to prevent cross-site scripts from running.
Compromised website resources. A website is vulnerable to parsing inline styles from compromised website resources. The Content-Security-Policy header can be used to restrict a browser to approved resources -- like Javascript and CSS -- from a whitelist. The X-Content-Security-Policy header is required in Internet Explorer 10 and later. A recommended value for this header is
This value enforces a basic policy that requires all accesses to use TLS, and prevents mixed content warnings.
Drive-by downloads. A website is vulnerable to drive-by downloads. To stop sniffing undeclared content type, the X-Content-Type-Options header can be used with the only valid value set to "nosniff".
Passive eavesdropping. A website is vulnerable to passive eavesdropping that can result in cookie hijacking. The solution is to use the Strict-Transport-Security header to block access to pages running over HTTP. Domain(s) are included in the preload list. When a user types in an address over the HTTP, the address is forced to use HTTPS for all subdomains. The security header can remain in effect for a year (in seconds). A recommended value is
Max-age=31536000; includeSubDomains; preload
This tells the browser to use HTTPS for all included subdomains for the next year (31536000 seconds).
Compromised certificates. A website is vulnerable to an attacker impersonating legitimate certificates using fraudulent cryptographic certificates.As a countermeasureHTTP public key pinning provides a whitelist of cryptographic identities that the browser should trust for a certain period of time. The suggested value is
In this case, whitelisted identities are to be trusted for 2592000 seconds, or 30 days.
Information disclosure. The Referrer-Policy header in a browser is turned on when a user clicks a link on a website. The linked website shows sensitive information in the URL. Use the value
no-referrer
to remove the referrer and to stop forwarding of sensitive information to other domains.
Economics value analysis. In a simple scenario, it should be used to compute frequency of potential loss of the designated assets over a period of time. Server risks would be fire, water damage, accidental cutting of communication cables, and inadequate maintenance contracts. Software risks would be improper configurations and lack of software library controls. If new assets, vulnerabilities, risks and countermeasures are identified, the accreditation process starts over. This will impact on the computation of the frequency of potential loss.
Adding strong HTTP security headers to the accreditation process should help to determine cost-effectiveness of implementing the headers as countermeasures. New HTTP security response headers can be added to mitigate new vulnerabilities.