OWASP - User contributions [en]

User talk:Riramar

2016-04-14T18:48:16Z

ADHTB:

'''Welcome to ''OWASP''!'''
We hope you will contribute much and well.
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].
Again, welcome and have fun! [[User:KateHartmann|KateHartmann]] ([[User talk:KateHartmann|talk]]) 07:53, 30 November 2015 (CST)

Hi Riramar, this is [[User:ADHTB|ADHTB]].
You're right about X-Frame-Options header directive ALLOWALL, it is defined almost nowhere.
It was initially set up on some servers to make the directive invalid and thus allow the websites to be framed from any other origin. As a consequence Mozilla (and apparently Microsoft too) decided to make it "valid" (to remove warnings from console): https://bugs.webkit.org/show_bug.cgi?id=110857
My goal here was to mention that somehow, and in my own opinion, it is better to have an explicit value than an implicit default value. However as it is my own opinion, I won't blame you if you revert my change because you disagree (as it is right it is defined in no RFC or other "official" document) :).

OWASP Secure Headers Project

2016-04-14T17:46:27Z

ADHTB: /* Values */

=Main=

[[File:Incubator_banner.jpg| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Secure Headers Project==

OWASP Secure Headers Project involves setting headers from the server is easy and often doesn't require any code changes. Once set, they can restrict modern browsers from running into easily preventable vulnerabilities. OWASP Secure Headers Project intends to raise awareness and use of these headers.

==Introduction==

HTTP headers are well known and also despised. Seeking the balance between usability and security developers implement functionality through the headers that can make your more versatile or secure application. But in practice how the headers are being implemented? What sites follow the best implementation practices? Big companies, small, all or none?

==Description==

We aim to publish reports on header usage stats, developments and changes. Code libraries that make these headers easily accessible to developers on a range of platforms. Data sets concerning the general usage of these headers.

==Licensing==
OWASP Secure Headers is free to use. It is licensed under the Apache 2.0 license.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP Secure Headers Project? ==

OWASP Secure Headers Project provides:

* Security best practices for HTTP headers
* Security tools for HTTP headers

== Project Leader ==

[[User:Riramar | Ricardo Iramar]]

== Project Contributors ==

[[User:Jmanico | Jim Manico]] 
[[User:Amenezes | Alexandre Menezes]]

== Related Projects ==

* [[List of useful HTTP headers]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Links ==

* [https://github.com/riramar/hsecscan hsecscan]

== Email List ==

[https://lists.owasp.org/mailman/listinfo/owasp_secure_headers_project Project Email List]

== News and Events ==
* [14 Dec 2015] Reborning from the ashes

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

=Headers=

A list of headers related to security and how to implement them properly.

* [[#HTTP Strict Transport Security (HSTS) | HTTP Strict Transport Security (HSTS)]]
* [[#Public Key Pinning Extension for HTTP (HPKP) | Public Key Pinning Extension for HTTP (HPKP)]]
* [[#X-Frame-Options | X-Frame-Options]]
* [[#X-XSS-Protection | X-XSS-Protection]]
* [[#X-Content-Type-Options | X-Content-Type-Options]]
* [[#Content-Security-Policy | Content-Security-Policy]]

==HTTP Strict Transport Security (HSTS)==

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797. A server implements an HSTS policy by supplying a header (Strict-Transport-Security) over an HTTPS connection (HSTS headers over HTTP are ignored).

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| max-age=SECONDS
| The time, in seconds, that the browser should remember that this site is only to be accessed using HTTPS.
|-
| includeSubDomains
| If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
|}

===Example===

<code>Strict-Transport-Security: max-age=31536000 ; includeSubDomains</code>

===Best Practices===

* Apache
:Edit your apache configuration file and add the following to your VirtualHost. 
::<code>Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"</code>

* nginx
:Edit your nginx configuration file and add the following snippet. 
::<code>add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";</code>

* lighttpd
:Edit your lighttpd configuration file and add the following snippet. 
::<code>setenv.add-response-header = ("Strict-Transport-Security" => "max-age=63072000; includeSubdomains",)</code>

* IIS

===References===

* https://tools.ietf.org/html/rfc6797
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
* https://www.chromium.org/hsts
* https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
* https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html

==Public Key Pinning Extension for HTTP (HPKP)==

HTTP Public Key Pinning (HPKP) is a security mechanism which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates. (For example, sometimes attackers can compromise certificate authorities, and then can mis-issue certificates for a web origin.) The HTTPS web server serves a list of public key hashes, and on subsequent connections clients expect that server to use 1 or more of those public keys in its certificate chain.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| pin-sha256="<sha256>"
| The quoted string is the Base64 encoded Subject Public Key Information (SPKI) fingerprint. It is possible to specify multiple pins for different public keys. Some browsers might allow other hashing algorithms than SHA-256 in the future.
|-
| max-age=SECONDS
| The time, in seconds, that the browser should remember that this site is only to be accessed using one of the pinned keys.
|-
| includeSubDomains
| If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
|-
| report-uri="<URL>"
| If this optional parameter is specified, pin validation failures are reported to the given URL.
|}

===Example===

Public-Key-Pins: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="http://example.com/pkp-report"; max-age=10000; includeSubDomains

===Best Practices===

* Apache
:Edit your apache configuration file and add the following to your VirtualHost. 
::<code>Header set Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains"</code>

* nginx
:Edit your nginx configuration file and add the following snippet. 
::<code>add_header Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains";</code>

* lighttpd
:Edit your lighttpd configuration file and add the following snippet. 
::<code>setenv.add-response-header = ("Public-Key-Pins" => "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains",)</code>

* IIS

===References===

* https://tools.ietf.org/html/rfc7469
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
* https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
* https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html

==X-Frame-Options==

X-Frame-Options response header improve the protection of web applications against Clickjacking. It declares a policy communicated from a host to the client browser on whether the browser must not display the transmitted content in frames of other web pages.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| deny
| No rendering within a frame.
|-
| sameorigin
| No rendering if origin mismatch.
|-
| allow-from: DOMAIN
| Allows rendering if framed by frame loaded from DOMAIN.
|-
| allowall
| Allows rendering.
|}

===Example===

<code>X-Frame-Options: deny</code>

===Best Practices===

* Apache
:Add this line below into your site's configuration to configure Apache to send X-Frame-Options header for all pages. 
::<code>Header set X-Frame-Options DENY</code>

* nginx
:Add snippet below into configuration file to send X-Frame-Options header. 
::<code>add_header X-Frame-Options "DENY";</code>

* lighttpd
:Add snippet below into configuration file to send X-Frame-Options header. 
::<code>setenv.add-response-header = ("X-Frame-Options" => "DENY",)</code>

* IIS

===References===

* https://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01
* https://tools.ietf.org/html/draft-ietf-websec-frame-options-00
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers

==X-XSS-Protection==

This header enables the Cross-site scripting (XSS) filter.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| 0
| Filter disabled.
|-
| 1
| Filter enabled. If a cross-site scripting attack is detected, in order to stop the attack, the browser will sanitize the page.
|-
| 1; mode=block
| Filter enabled. Rather than sanitize the page, when a XSS attack is detected, the browser will prevent rendering of the page.
|-
| 1; report=http://[YOURDOMAIN]/your_report_URI
| Filter enabled. The browser will sanitize the page and report the violation. This is a Chromium function utilizing CSP violation reports to send details to a URI of your choice.
|}

===Example===

<code>X-XSS-Protection: 1; mode=block</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set X-XSS-Protection: 1; mode=block</code>

* nginx
:<code>add_header X-XSS-Protection "1;mode=block";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-XSS-Protection" => "1; mode=block",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://www.virtuesecurity.com/blog/understanding-xss-auditor/
* https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers
* http://zinoui.com/blog/security-http-headers#x-xss-protection

==X-Content-Type-Options==

Setting this header will prevent MSIE and Chrome from interpreting files as something else than declared by the content type in the HTTP headers.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| nosniff
| will prevent Internet Explorer and Chrome from MIME-sniffing a response away from the declared content-type.
|}

===Example===

<code>X-Content-Type-Options: nosniff</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set X-Content-Type-Options: nosniff</code>

* nginx
:<code>add_header X-Content-Type-Options "nosniff";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-Content-Type-Options" => "nosniff",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/

==Content-Security-Policy==

Content Security Policy requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including Cross-site scripting and other cross-site injections.

===Values===

{| class="wikitable"
|-
! Directive
! Description
|-
| base-uri
| Define the base uri for relative uri.
|-
| default-src
| Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback).
|-
| script-src
| Define which scripts the protected resource can execute.
|-
| object-src
| Define from where the protected resource can load plugins.
|-
| style-src
| Define which styles (CSS) the user applies to the protected resource.
|-
| img-src
| Define from where the protected resource can load images.
|-
| media-src
| Define from where the protected resource can load video and audio.
|-
| frame-src
| Deprecated and replaced by child-src. Define from where the protected resource can embed frames.
|-
| child-src
| Define from where the protected resource can embed frames.
|-
| frame-ancestors
| Define from where the protected resource can be embedded in frames.
|-
| font-src
| Define from where the protected resource can load fonts.
|-
| connect-src
| Define which URIs the protected resource can load using script interfaces.
|-
| manifest-src
| Define from where the protected resource can load manifest.
|-
| form-action
| Define which URIs can be used as the action of HTML form elements.
|-
| sandbox
| Specifies an HTML sandbox policy that the user agent applies to the protected resource.
|-
| script-nonce
| Define script execution by requiring the presence of the specified nonce on script elements.
|-
| plugin-types
| Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded.
|-
| reflected-xss
| Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header.
|-
| block-all-mixed-content
| Prevent user agent from loading mixed content.
|-
| upgrade-insecure-requests
| Instructs user agent to download insecure resources using HTTPS.
|-
| referrer
| Define information user agent must send in Referer header.
|-
| report-uri
| Specifies a URI to which the user agent sends reports about policy violation.
|-
| report-to
| Specifies a group (defined in Report-To header) to which the user agent sends reports about policy violation.
|}

===Example===

<code>Content-Security-Policy: script-src 'self'</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set Content-Security-Policy: script-src 'self'</code>

* nginx
:<code>add_header Content-Security-Policy "script-src 'self'";</code>

* lighttpd
:<code>setenv.add-response-header = ("Content-Security-Policy" => "script-src 'self'",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* http://www.cspplayground.com/home
* https://scotthelme.co.uk/content-security-policy-an-introduction/

=Tools and Libraries=
A list of tools that can help you to achieve the on of the goals of this project.

==High-Tech Bridge Web Security Scanner==

An online service that will retrieve and analyse headers syntax and proper configuration in a comprehensive way.
It will be able for instance to highlight Public-Key-Pins that matches one certificate of the chain or if Content-Security-Policy contains values that could be unsafe or too permissive.

Site: [https://www.htbridge.com/websec/ https://www.htbridge.com/websec/]

==hsecscan==

A security scanner for HTTP response headers.

Github: [https://github.com/riramar/hsecscan https://github.com/riramar/hsecscan]

==securityheaders.io==

There are services out there that will analyse the HTTP response headers of other sites but I also wanted to add a rating system to the results. The HTTP response headers that this site analyses provide huge levels of protection and it's important that sites deploy them. Hopefully, by providing an easy mechanism to assess them, and further information on how to deploy missing headers, we can drive up the usage of security based headers across the web.

Site: [https://securityheaders.io https://securityheaders.io]

==report-uri.io==

When a site deploys a Content Security Policy or HTTP Public Key Pinning, the browser will enforce the security policies declared by the site. This is great as it offers visitors more protection but the only problem is, the host doesn't know that there's a problem. The browser will block malicious content, such as an XSS attack, but the host wouldn't know anything about it and as such, can't resolve the problem. This is the problem that report-uri.io fixes. With your own unique reporting endpoint the browser can send a violation report to us and you can monitor exactly what is happening on your site. You can see what security policies are being triggered, where and why.

Site: [https://report-uri.io https://report-uri.io]

==secureheaders==

secure_headers is a library for ruby with a global config, per request overrides, and rack milddleware that enables you customize your application settings.

Github: [https://github.com/twitter/secureheaders https://github.com/twitter/secureheaders]

==Security Header Injection Module (SHIM)==

SHIM is a HTTP module that provides protection for many vulnerabilities by injecting security-specific HTTP headers into ASP.NET web applications.

Site: [https://shim.codeplex.com https://shim.codeplex.com]

==http_hardening==

Puppet module to enable, configure and manage secure http headers in web servers.

Github: [https://github.com/amenezes/http_hardening http_hardening] 
Forge: [https://forge.puppet.com/amenezes/http_hardening http_hardening at forge | puppetlabs]

=FAQs=

; What is HTTP header?
: HTTP header fields are components of the header section of request and response messages in the Hypertext Transfer Protocol (HTTP). They define the operating parameters of an HTTP transaction.

; Is there a standard for HTTP headers?
: A core set of fields is standardized by the Internet Engineering Task Force (IETF) in RFCs 7230, 7231, 7232, 7233, 7234, and 7235. The permanent registry of header fields and repository of provisional registrations are maintained by the IANA. Additional field names and permissible values may be defined by each application. Non-standard header fields were conventionally marked by prefixing the field name with X- but this convention was deprecated in June 2012 because of the inconveniences it caused when non-standard fields became standard. An earlier restriction on use of Downgraded- was lifted in March 2013.

= Acknowledgements =
==Contributors==
OWASP Secure Headers Project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* [https://www.owasp.org/index.php/User:Riramar Ricardo Iramar]
* [https://www.owasp.org/index.php/User:Jmanico Jim Manico]
* [https://www.owasp.org/index.php/Special:Contributions/Amenezes Alexandre Menezes]

= Road Map and Getting Involved =

'''2016 Priorities'''

== To Do ==

OWASP Secure Headers Project intends to raise awareness and usage of headers sent by the server that can increase security. We'll aim to bring this about by:

* Producing open source, easily implemented, well documented code libraries that enable these headers for a variety of platforms. We'll prioritize creating and publicizing Node.JS, PHP, Ruby, and Java, but will eventually reach out towards edge cases like Go, Python and others. The key is to make this accessible as possible to developers.

* Improve constantly hsecscan tool to detect bad practices and provide link to the best practices above.

* Perform public to scan websites using hsecscan and view stats regarding these headers. Automated scanning of the top 1m sites on the web; filtering of said sites to view stats across industries and countries; published database dumps for public consumption/tools; scanning of individual sites; comparing multiple scanned sites.

* Consistent reports regarding this secure headers, their usage, any changes to existing headers.

Involvement in the development and promotion of OWASP Secure Headers Project is actively encouraged!
You do not have to be a security expert in order to contribute.
If you want to help send an email to [mailto:ricardo.iramar@owasp.org ricardo.iramar@owasp.org].

== Doing ==

* Including how to set properly secure headers on IIS.

== Done ==

* Creating secure best practices implementations including how to set properly secure headers on the most common platforms (eg. Apache, NGINX and Lighttpd).

__NOTOC__ <headertabs />

[[Category:OWASP Project]]

OWASP Secure Headers Project

2016-04-14T17:39:00Z

ADHTB: /* Content-Security-Policy */

=Main=

[[File:Incubator_banner.jpg| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Secure Headers Project==

OWASP Secure Headers Project involves setting headers from the server is easy and often doesn't require any code changes. Once set, they can restrict modern browsers from running into easily preventable vulnerabilities. OWASP Secure Headers Project intends to raise awareness and use of these headers.

==Introduction==

HTTP headers are well known and also despised. Seeking the balance between usability and security developers implement functionality through the headers that can make your more versatile or secure application. But in practice how the headers are being implemented? What sites follow the best implementation practices? Big companies, small, all or none?

==Description==

We aim to publish reports on header usage stats, developments and changes. Code libraries that make these headers easily accessible to developers on a range of platforms. Data sets concerning the general usage of these headers.

==Licensing==
OWASP Secure Headers is free to use. It is licensed under the Apache 2.0 license.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP Secure Headers Project? ==

OWASP Secure Headers Project provides:

* Security best practices for HTTP headers
* Security tools for HTTP headers

== Project Leader ==

[[User:Riramar | Ricardo Iramar]]

== Project Contributors ==

[[User:Jmanico | Jim Manico]] 
[[User:Amenezes | Alexandre Menezes]]

== Related Projects ==

* [[List of useful HTTP headers]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Links ==

* [https://github.com/riramar/hsecscan hsecscan]

== Email List ==

[https://lists.owasp.org/mailman/listinfo/owasp_secure_headers_project Project Email List]

== News and Events ==
* [14 Dec 2015] Reborning from the ashes

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

=Headers=

A list of headers related to security and how to implement them properly.

* [[#HTTP Strict Transport Security (HSTS) | HTTP Strict Transport Security (HSTS)]]
* [[#Public Key Pinning Extension for HTTP (HPKP) | Public Key Pinning Extension for HTTP (HPKP)]]
* [[#X-Frame-Options | X-Frame-Options]]
* [[#X-XSS-Protection | X-XSS-Protection]]
* [[#X-Content-Type-Options | X-Content-Type-Options]]
* [[#Content-Security-Policy | Content-Security-Policy]]

==HTTP Strict Transport Security (HSTS)==

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797. A server implements an HSTS policy by supplying a header (Strict-Transport-Security) over an HTTPS connection (HSTS headers over HTTP are ignored).

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| max-age=SECONDS
| The time, in seconds, that the browser should remember that this site is only to be accessed using HTTPS.
|-
| includeSubDomains
| If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
|}

===Example===

<code>Strict-Transport-Security: max-age=31536000 ; includeSubDomains</code>

===Best Practices===

* Apache
:Edit your apache configuration file and add the following to your VirtualHost. 
::<code>Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"</code>

* nginx
:Edit your nginx configuration file and add the following snippet. 
::<code>add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";</code>

* lighttpd
:Edit your lighttpd configuration file and add the following snippet. 
::<code>setenv.add-response-header = ("Strict-Transport-Security" => "max-age=63072000; includeSubdomains",)</code>

* IIS

===References===

* https://tools.ietf.org/html/rfc6797
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
* https://www.chromium.org/hsts
* https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
* https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html

==Public Key Pinning Extension for HTTP (HPKP)==

HTTP Public Key Pinning (HPKP) is a security mechanism which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates. (For example, sometimes attackers can compromise certificate authorities, and then can mis-issue certificates for a web origin.) The HTTPS web server serves a list of public key hashes, and on subsequent connections clients expect that server to use 1 or more of those public keys in its certificate chain.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| pin-sha256="<sha256>"
| The quoted string is the Base64 encoded Subject Public Key Information (SPKI) fingerprint. It is possible to specify multiple pins for different public keys. Some browsers might allow other hashing algorithms than SHA-256 in the future.
|-
| max-age=SECONDS
| The time, in seconds, that the browser should remember that this site is only to be accessed using one of the pinned keys.
|-
| includeSubDomains
| If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
|-
| report-uri="<URL>"
| If this optional parameter is specified, pin validation failures are reported to the given URL.
|}

===Example===

Public-Key-Pins: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="http://example.com/pkp-report"; max-age=10000; includeSubDomains

===Best Practices===

* Apache
:Edit your apache configuration file and add the following to your VirtualHost. 
::<code>Header set Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains"</code>

* nginx
:Edit your nginx configuration file and add the following snippet. 
::<code>add_header Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains";</code>

* lighttpd
:Edit your lighttpd configuration file and add the following snippet. 
::<code>setenv.add-response-header = ("Public-Key-Pins" => "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains",)</code>

* IIS

===References===

* https://tools.ietf.org/html/rfc7469
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
* https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
* https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html

==X-Frame-Options==

X-Frame-Options response header improve the protection of web applications against Clickjacking. It declares a policy communicated from a host to the client browser on whether the browser must not display the transmitted content in frames of other web pages.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| deny
| No rendering within a frame.
|-
| sameorigin
| No rendering if origin mismatch.
|-
| allow-from: DOMAIN
| Allows rendering if framed by frame loaded from DOMAIN.
|-
| allowall
| Allows rendering.
|}

===Example===

<code>X-Frame-Options: deny</code>

===Best Practices===

* Apache
:Add this line below into your site's configuration to configure Apache to send X-Frame-Options header for all pages. 
::<code>Header set X-Frame-Options DENY</code>

* nginx
:Add snippet below into configuration file to send X-Frame-Options header. 
::<code>add_header X-Frame-Options "DENY";</code>

* lighttpd
:Add snippet below into configuration file to send X-Frame-Options header. 
::<code>setenv.add-response-header = ("X-Frame-Options" => "DENY",)</code>

* IIS

===References===

* https://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01
* https://tools.ietf.org/html/draft-ietf-websec-frame-options-00
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers

==X-XSS-Protection==

This header enables the Cross-site scripting (XSS) filter.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| 0
| Filter disabled.
|-
| 1
| Filter enabled. If a cross-site scripting attack is detected, in order to stop the attack, the browser will sanitize the page.
|-
| 1; mode=block
| Filter enabled. Rather than sanitize the page, when a XSS attack is detected, the browser will prevent rendering of the page.
|-
| 1; report=http://[YOURDOMAIN]/your_report_URI
| Filter enabled. The browser will sanitize the page and report the violation. This is a Chromium function utilizing CSP violation reports to send details to a URI of your choice.
|}

===Example===

<code>X-XSS-Protection: 1; mode=block</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set X-XSS-Protection: 1; mode=block</code>

* nginx
:<code>add_header X-XSS-Protection "1;mode=block";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-XSS-Protection" => "1; mode=block",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://www.virtuesecurity.com/blog/understanding-xss-auditor/
* https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers
* http://zinoui.com/blog/security-http-headers#x-xss-protection

==X-Content-Type-Options==

Setting this header will prevent MSIE and Chrome from interpreting files as something else than declared by the content type in the HTTP headers.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| nosniff
| will prevent Internet Explorer and Chrome from MIME-sniffing a response away from the declared content-type.
|}

===Example===

<code>X-Content-Type-Options: nosniff</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set X-Content-Type-Options: nosniff</code>

* nginx
:<code>add_header X-Content-Type-Options "nosniff";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-Content-Type-Options" => "nosniff",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/

==Content-Security-Policy==

Content Security Policy requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including Cross-site scripting and other cross-site injections.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| base-uri
| Define the base uri for relative uri.
|-
| default-src
| Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback).
|-
| script-src
| Define which scripts the protected resource can execute.
|-
| object-src
| Define from where the protected resource can load plugins.
|-
| style-src
| Define which styles (CSS) the user applies to the protected resource.
|-
| img-src
| Define from where the protected resource can load images.
|-
| media-src
| Define from where the protected resource can load video and audio.
|-
| frame-src
| Deprecated and replaced by child-src. Define from where the protected resource can embed frames.
|-
| child-src
| Define from where the protected resource can embed frames.
|-
| frame-ancestors
| Define from where the protected resource can be embedded in frames.
|-
| font-src
| Define from where the protected resource can load fonts.
|-
| connect-src
| Define which URIs the protected resource can load using script interfaces.
|-
| manifest-src
| Define from where the protected resource can load manifest.
|-
| form-action
| Define which URIs can be used as the action of HTML form elements.
|-
| sandbox
| Specifies an HTML sandbox policy that the user agent applies to the protected resource.
|-
| script-nonce
| Define script execution by requiring the presence of the specified nonce on script elements.
|-
| plugin-types
| Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded.
|-
| reflected-xss
| Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header.
|-
| block-all-mixed-content
| Prevent user agent from loading mixed content.
|-
| upgrade-insecure-requests
| Instructs user agent to download insecure resources using HTTPS.
|-
| referrer
| Define information user agent must send in Referer header.
|-
| report-uri
| Specifies a URI to which the user agent sends reports about policy violation.
|-
| report-to
| Specifies a group (defined in Report-To header) to which the user agent sends reports about policy violation.
|}

===Example===

<code>Content-Security-Policy: script-src 'self'</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set Content-Security-Policy: script-src 'self'</code>

* nginx
:<code>add_header Content-Security-Policy "script-src 'self'";</code>

* lighttpd
:<code>setenv.add-response-header = ("Content-Security-Policy" => "script-src 'self'",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* http://www.cspplayground.com/home
* https://scotthelme.co.uk/content-security-policy-an-introduction/

=Tools and Libraries=
A list of tools that can help you to achieve the on of the goals of this project.

==High-Tech Bridge Web Security Scanner==

An online service that will retrieve and analyse headers syntax and proper configuration in a comprehensive way.
It will be able for instance to highlight Public-Key-Pins that matches one certificate of the chain or if Content-Security-Policy contains values that could be unsafe or too permissive.

Site: [https://www.htbridge.com/websec/ https://www.htbridge.com/websec/]

==hsecscan==

A security scanner for HTTP response headers.

Github: [https://github.com/riramar/hsecscan https://github.com/riramar/hsecscan]

==securityheaders.io==

There are services out there that will analyse the HTTP response headers of other sites but I also wanted to add a rating system to the results. The HTTP response headers that this site analyses provide huge levels of protection and it's important that sites deploy them. Hopefully, by providing an easy mechanism to assess them, and further information on how to deploy missing headers, we can drive up the usage of security based headers across the web.

Site: [https://securityheaders.io https://securityheaders.io]

==report-uri.io==

When a site deploys a Content Security Policy or HTTP Public Key Pinning, the browser will enforce the security policies declared by the site. This is great as it offers visitors more protection but the only problem is, the host doesn't know that there's a problem. The browser will block malicious content, such as an XSS attack, but the host wouldn't know anything about it and as such, can't resolve the problem. This is the problem that report-uri.io fixes. With your own unique reporting endpoint the browser can send a violation report to us and you can monitor exactly what is happening on your site. You can see what security policies are being triggered, where and why.

Site: [https://report-uri.io https://report-uri.io]

==secureheaders==

secure_headers is a library for ruby with a global config, per request overrides, and rack milddleware that enables you customize your application settings.

Github: [https://github.com/twitter/secureheaders https://github.com/twitter/secureheaders]

==Security Header Injection Module (SHIM)==

SHIM is a HTTP module that provides protection for many vulnerabilities by injecting security-specific HTTP headers into ASP.NET web applications.

Site: [https://shim.codeplex.com https://shim.codeplex.com]

==http_hardening==

Puppet module to enable, configure and manage secure http headers in web servers.

Github: [https://github.com/amenezes/http_hardening http_hardening] 
Forge: [https://forge.puppet.com/amenezes/http_hardening http_hardening at forge | puppetlabs]

=FAQs=

; What is HTTP header?
: HTTP header fields are components of the header section of request and response messages in the Hypertext Transfer Protocol (HTTP). They define the operating parameters of an HTTP transaction.

; Is there a standard for HTTP headers?
: A core set of fields is standardized by the Internet Engineering Task Force (IETF) in RFCs 7230, 7231, 7232, 7233, 7234, and 7235. The permanent registry of header fields and repository of provisional registrations are maintained by the IANA. Additional field names and permissible values may be defined by each application. Non-standard header fields were conventionally marked by prefixing the field name with X- but this convention was deprecated in June 2012 because of the inconveniences it caused when non-standard fields became standard. An earlier restriction on use of Downgraded- was lifted in March 2013.

= Acknowledgements =
==Contributors==
OWASP Secure Headers Project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* [https://www.owasp.org/index.php/User:Riramar Ricardo Iramar]
* [https://www.owasp.org/index.php/User:Jmanico Jim Manico]
* [https://www.owasp.org/index.php/Special:Contributions/Amenezes Alexandre Menezes]

= Road Map and Getting Involved =

'''2016 Priorities'''

== To Do ==

OWASP Secure Headers Project intends to raise awareness and usage of headers sent by the server that can increase security. We'll aim to bring this about by:

* Producing open source, easily implemented, well documented code libraries that enable these headers for a variety of platforms. We'll prioritize creating and publicizing Node.JS, PHP, Ruby, and Java, but will eventually reach out towards edge cases like Go, Python and others. The key is to make this accessible as possible to developers.

* Improve constantly hsecscan tool to detect bad practices and provide link to the best practices above.

* Perform public to scan websites using hsecscan and view stats regarding these headers. Automated scanning of the top 1m sites on the web; filtering of said sites to view stats across industries and countries; published database dumps for public consumption/tools; scanning of individual sites; comparing multiple scanned sites.

* Consistent reports regarding this secure headers, their usage, any changes to existing headers.

Involvement in the development and promotion of OWASP Secure Headers Project is actively encouraged!
You do not have to be a security expert in order to contribute.
If you want to help send an email to [mailto:ricardo.iramar@owasp.org ricardo.iramar@owasp.org].

== Doing ==

* Including how to set properly secure headers on IIS.

== Done ==

* Creating secure best practices implementations including how to set properly secure headers on the most common platforms (eg. Apache, NGINX and Lighttpd).

__NOTOC__ <headertabs />

[[Category:OWASP Project]]

OWASP Secure Headers Project

2016-04-14T17:23:31Z

ADHTB: /* X-Content-Type-Options */

=Main=

[[File:Incubator_banner.jpg| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Secure Headers Project==

OWASP Secure Headers Project involves setting headers from the server is easy and often doesn't require any code changes. Once set, they can restrict modern browsers from running into easily preventable vulnerabilities. OWASP Secure Headers Project intends to raise awareness and use of these headers.

==Introduction==

HTTP headers are well known and also despised. Seeking the balance between usability and security developers implement functionality through the headers that can make your more versatile or secure application. But in practice how the headers are being implemented? What sites follow the best implementation practices? Big companies, small, all or none?

==Description==

We aim to publish reports on header usage stats, developments and changes. Code libraries that make these headers easily accessible to developers on a range of platforms. Data sets concerning the general usage of these headers.

==Licensing==
OWASP Secure Headers is free to use. It is licensed under the Apache 2.0 license.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP Secure Headers Project? ==

OWASP Secure Headers Project provides:

* Security best practices for HTTP headers
* Security tools for HTTP headers

== Project Leader ==

[[User:Riramar | Ricardo Iramar]]

== Project Contributors ==

[[User:Jmanico | Jim Manico]] 
[[User:Amenezes | Alexandre Menezes]]

== Related Projects ==

* [[List of useful HTTP headers]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Links ==

* [https://github.com/riramar/hsecscan hsecscan]

== Email List ==

[https://lists.owasp.org/mailman/listinfo/owasp_secure_headers_project Project Email List]

== News and Events ==
* [14 Dec 2015] Reborning from the ashes

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

=Headers=

A list of headers related to security and how to implement them properly.

* [[#HTTP Strict Transport Security (HSTS) | HTTP Strict Transport Security (HSTS)]]
* [[#Public Key Pinning Extension for HTTP (HPKP) | Public Key Pinning Extension for HTTP (HPKP)]]
* [[#X-Frame-Options | X-Frame-Options]]
* [[#X-XSS-Protection | X-XSS-Protection]]
* [[#X-Content-Type-Options | X-Content-Type-Options]]
* [[#Content-Security-Policy | Content-Security-Policy]]

==HTTP Strict Transport Security (HSTS)==

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797. A server implements an HSTS policy by supplying a header (Strict-Transport-Security) over an HTTPS connection (HSTS headers over HTTP are ignored).

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| max-age=SECONDS
| The time, in seconds, that the browser should remember that this site is only to be accessed using HTTPS.
|-
| includeSubDomains
| If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
|}

===Example===

<code>Strict-Transport-Security: max-age=31536000 ; includeSubDomains</code>

===Best Practices===

* Apache
:Edit your apache configuration file and add the following to your VirtualHost. 
::<code>Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"</code>

* nginx
:Edit your nginx configuration file and add the following snippet. 
::<code>add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";</code>

* lighttpd
:Edit your lighttpd configuration file and add the following snippet. 
::<code>setenv.add-response-header = ("Strict-Transport-Security" => "max-age=63072000; includeSubdomains",)</code>

* IIS

===References===

* https://tools.ietf.org/html/rfc6797
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
* https://www.chromium.org/hsts
* https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
* https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html

==Public Key Pinning Extension for HTTP (HPKP)==

HTTP Public Key Pinning (HPKP) is a security mechanism which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates. (For example, sometimes attackers can compromise certificate authorities, and then can mis-issue certificates for a web origin.) The HTTPS web server serves a list of public key hashes, and on subsequent connections clients expect that server to use 1 or more of those public keys in its certificate chain.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| pin-sha256="<sha256>"
| The quoted string is the Base64 encoded Subject Public Key Information (SPKI) fingerprint. It is possible to specify multiple pins for different public keys. Some browsers might allow other hashing algorithms than SHA-256 in the future.
|-
| max-age=SECONDS
| The time, in seconds, that the browser should remember that this site is only to be accessed using one of the pinned keys.
|-
| includeSubDomains
| If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
|-
| report-uri="<URL>"
| If this optional parameter is specified, pin validation failures are reported to the given URL.
|}

===Example===

Public-Key-Pins: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="http://example.com/pkp-report"; max-age=10000; includeSubDomains

===Best Practices===

* Apache
:Edit your apache configuration file and add the following to your VirtualHost. 
::<code>Header set Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains"</code>

* nginx
:Edit your nginx configuration file and add the following snippet. 
::<code>add_header Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains";</code>

* lighttpd
:Edit your lighttpd configuration file and add the following snippet. 
::<code>setenv.add-response-header = ("Public-Key-Pins" => "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains",)</code>

* IIS

===References===

* https://tools.ietf.org/html/rfc7469
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
* https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
* https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html

==X-Frame-Options==

X-Frame-Options response header improve the protection of web applications against Clickjacking. It declares a policy communicated from a host to the client browser on whether the browser must not display the transmitted content in frames of other web pages.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| deny
| No rendering within a frame.
|-
| sameorigin
| No rendering if origin mismatch.
|-
| allow-from: DOMAIN
| Allows rendering if framed by frame loaded from DOMAIN.
|-
| allowall
| Allows rendering.
|}

===Example===

<code>X-Frame-Options: deny</code>

===Best Practices===

* Apache
:Add this line below into your site's configuration to configure Apache to send X-Frame-Options header for all pages. 
::<code>Header set X-Frame-Options DENY</code>

* nginx
:Add snippet below into configuration file to send X-Frame-Options header. 
::<code>add_header X-Frame-Options "DENY";</code>

* lighttpd
:Add snippet below into configuration file to send X-Frame-Options header. 
::<code>setenv.add-response-header = ("X-Frame-Options" => "DENY",)</code>

* IIS

===References===

* https://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01
* https://tools.ietf.org/html/draft-ietf-websec-frame-options-00
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers

==X-XSS-Protection==

This header enables the Cross-site scripting (XSS) filter.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| 0
| Filter disabled.
|-
| 1
| Filter enabled. If a cross-site scripting attack is detected, in order to stop the attack, the browser will sanitize the page.
|-
| 1; mode=block
| Filter enabled. Rather than sanitize the page, when a XSS attack is detected, the browser will prevent rendering of the page.
|-
| 1; report=http://[YOURDOMAIN]/your_report_URI
| Filter enabled. The browser will sanitize the page and report the violation. This is a Chromium function utilizing CSP violation reports to send details to a URI of your choice.
|}

===Example===

<code>X-XSS-Protection: 1; mode=block</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set X-XSS-Protection: 1; mode=block</code>

* nginx
:<code>add_header X-XSS-Protection "1;mode=block";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-XSS-Protection" => "1; mode=block",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://www.virtuesecurity.com/blog/understanding-xss-auditor/
* https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers
* http://zinoui.com/blog/security-http-headers#x-xss-protection

==X-Content-Type-Options==

Setting this header will prevent MSIE and Chrome from interpreting files as something else than declared by the content type in the HTTP headers.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| nosniff
| will prevent Internet Explorer and Chrome from MIME-sniffing a response away from the declared content-type.
|}

===Example===

<code>X-Content-Type-Options: nosniff</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set X-Content-Type-Options: nosniff</code>

* nginx
:<code>add_header X-Content-Type-Options "nosniff";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-Content-Type-Options" => "nosniff",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/

==Content-Security-Policy==

Content Security Policy requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including Cross-site scripting and other cross-site injections.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| default-src
| Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback).
|-
| script-src
| Define which scripts the protected resource can execute.
|-
| object-src
| Define from where the protected resource can load plugins.
|-
| style-src
| Define which styles (CSS) the user applies to the protected resource.
|-
| img-src
| Define from where the protected resource can load images.
|-
| media-src
| Define from where the protected resource can load video and audio.
|-
| frame-src
| Define from where the protected resource can embed frames.
|-
| font-src
| Define from where the protected resource can load fonts.
|-
| connect-src
| Define which URIs the protected resource can load using script interfaces.
|-
| form-action
| Define which URIs can be used as the action of HTML form elements.
|-
| sandbox
| Specifies an HTML sandbox policy that the user agent applies to the protected resource.
|-
| script-nonce
| Define script execution by requiring the presence of the specified nonce on script elements.
|-
| plugin-types
| Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded.
|-
| reflected-xss
| Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header.
|-
| report-uri
| Specifies a URI to which the user agent sends reports about policy violation.
|}

===Example===

<code>Content-Security-Policy: script-src 'self'</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set Content-Security-Policy: script-src 'self'</code>

* nginx
:<code>add_header Content-Security-Policy "script-src 'self'";</code>

* lighttpd
:<code>setenv.add-response-header = ("Content-Security-Policy" => "script-src 'self'",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* http://www.cspplayground.com/home
* https://scotthelme.co.uk/content-security-policy-an-introduction/

=Tools and Libraries=
A list of tools that can help you to achieve the on of the goals of this project.

==High-Tech Bridge Web Security Scanner==

An online service that will retrieve and analyse headers syntax and proper configuration in a comprehensive way.
It will be able for instance to highlight Public-Key-Pins that matches one certificate of the chain or if Content-Security-Policy contains values that could be unsafe or too permissive.

Site: [https://www.htbridge.com/websec/ https://www.htbridge.com/websec/]

==hsecscan==

A security scanner for HTTP response headers.

Github: [https://github.com/riramar/hsecscan https://github.com/riramar/hsecscan]

==securityheaders.io==

There are services out there that will analyse the HTTP response headers of other sites but I also wanted to add a rating system to the results. The HTTP response headers that this site analyses provide huge levels of protection and it's important that sites deploy them. Hopefully, by providing an easy mechanism to assess them, and further information on how to deploy missing headers, we can drive up the usage of security based headers across the web.

Site: [https://securityheaders.io https://securityheaders.io]

==report-uri.io==

When a site deploys a Content Security Policy or HTTP Public Key Pinning, the browser will enforce the security policies declared by the site. This is great as it offers visitors more protection but the only problem is, the host doesn't know that there's a problem. The browser will block malicious content, such as an XSS attack, but the host wouldn't know anything about it and as such, can't resolve the problem. This is the problem that report-uri.io fixes. With your own unique reporting endpoint the browser can send a violation report to us and you can monitor exactly what is happening on your site. You can see what security policies are being triggered, where and why.

Site: [https://report-uri.io https://report-uri.io]

==secureheaders==

secure_headers is a library for ruby with a global config, per request overrides, and rack milddleware that enables you customize your application settings.

Github: [https://github.com/twitter/secureheaders https://github.com/twitter/secureheaders]

==Security Header Injection Module (SHIM)==

SHIM is a HTTP module that provides protection for many vulnerabilities by injecting security-specific HTTP headers into ASP.NET web applications.

Site: [https://shim.codeplex.com https://shim.codeplex.com]

==http_hardening==

Puppet module to enable, configure and manage secure http headers in web servers.

Github: [https://github.com/amenezes/http_hardening http_hardening] 
Forge: [https://forge.puppet.com/amenezes/http_hardening http_hardening at forge | puppetlabs]

=FAQs=

; What is HTTP header?
: HTTP header fields are components of the header section of request and response messages in the Hypertext Transfer Protocol (HTTP). They define the operating parameters of an HTTP transaction.

; Is there a standard for HTTP headers?
: A core set of fields is standardized by the Internet Engineering Task Force (IETF) in RFCs 7230, 7231, 7232, 7233, 7234, and 7235. The permanent registry of header fields and repository of provisional registrations are maintained by the IANA. Additional field names and permissible values may be defined by each application. Non-standard header fields were conventionally marked by prefixing the field name with X- but this convention was deprecated in June 2012 because of the inconveniences it caused when non-standard fields became standard. An earlier restriction on use of Downgraded- was lifted in March 2013.

= Acknowledgements =
==Contributors==
OWASP Secure Headers Project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* [https://www.owasp.org/index.php/User:Riramar Ricardo Iramar]
* [https://www.owasp.org/index.php/User:Jmanico Jim Manico]
* [https://www.owasp.org/index.php/Special:Contributions/Amenezes Alexandre Menezes]

= Road Map and Getting Involved =

'''2016 Priorities'''

== To Do ==

OWASP Secure Headers Project intends to raise awareness and usage of headers sent by the server that can increase security. We'll aim to bring this about by:

* Producing open source, easily implemented, well documented code libraries that enable these headers for a variety of platforms. We'll prioritize creating and publicizing Node.JS, PHP, Ruby, and Java, but will eventually reach out towards edge cases like Go, Python and others. The key is to make this accessible as possible to developers.

* Improve constantly hsecscan tool to detect bad practices and provide link to the best practices above.

* Perform public to scan websites using hsecscan and view stats regarding these headers. Automated scanning of the top 1m sites on the web; filtering of said sites to view stats across industries and countries; published database dumps for public consumption/tools; scanning of individual sites; comparing multiple scanned sites.

* Consistent reports regarding this secure headers, their usage, any changes to existing headers.

Involvement in the development and promotion of OWASP Secure Headers Project is actively encouraged!
You do not have to be a security expert in order to contribute.
If you want to help send an email to [mailto:ricardo.iramar@owasp.org ricardo.iramar@owasp.org].

== Doing ==

* Including how to set properly secure headers on IIS.

== Done ==

* Creating secure best practices implementations including how to set properly secure headers on the most common platforms (eg. Apache, NGINX and Lighttpd).

__NOTOC__ <headertabs />

[[Category:OWASP Project]]

OWASP Secure Headers Project

2016-04-14T17:22:28Z

ADHTB: /* Values */

=Main=

[[File:Incubator_banner.jpg| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Secure Headers Project==

OWASP Secure Headers Project involves setting headers from the server is easy and often doesn't require any code changes. Once set, they can restrict modern browsers from running into easily preventable vulnerabilities. OWASP Secure Headers Project intends to raise awareness and use of these headers.

==Introduction==

HTTP headers are well known and also despised. Seeking the balance between usability and security developers implement functionality through the headers that can make your more versatile or secure application. But in practice how the headers are being implemented? What sites follow the best implementation practices? Big companies, small, all or none?

==Description==

We aim to publish reports on header usage stats, developments and changes. Code libraries that make these headers easily accessible to developers on a range of platforms. Data sets concerning the general usage of these headers.

==Licensing==
OWASP Secure Headers is free to use. It is licensed under the Apache 2.0 license.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP Secure Headers Project? ==

OWASP Secure Headers Project provides:

* Security best practices for HTTP headers
* Security tools for HTTP headers

== Project Leader ==

[[User:Riramar | Ricardo Iramar]]

== Project Contributors ==

[[User:Jmanico | Jim Manico]] 
[[User:Amenezes | Alexandre Menezes]]

== Related Projects ==

* [[List of useful HTTP headers]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Links ==

* [https://github.com/riramar/hsecscan hsecscan]

== Email List ==

[https://lists.owasp.org/mailman/listinfo/owasp_secure_headers_project Project Email List]

== News and Events ==
* [14 Dec 2015] Reborning from the ashes

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

=Headers=

A list of headers related to security and how to implement them properly.

* [[#HTTP Strict Transport Security (HSTS) | HTTP Strict Transport Security (HSTS)]]
* [[#Public Key Pinning Extension for HTTP (HPKP) | Public Key Pinning Extension for HTTP (HPKP)]]
* [[#X-Frame-Options | X-Frame-Options]]
* [[#X-XSS-Protection | X-XSS-Protection]]
* [[#X-Content-Type-Options | X-Content-Type-Options]]
* [[#Content-Security-Policy | Content-Security-Policy]]

==HTTP Strict Transport Security (HSTS)==

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797. A server implements an HSTS policy by supplying a header (Strict-Transport-Security) over an HTTPS connection (HSTS headers over HTTP are ignored).

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| max-age=SECONDS
| The time, in seconds, that the browser should remember that this site is only to be accessed using HTTPS.
|-
| includeSubDomains
| If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
|}

===Example===

<code>Strict-Transport-Security: max-age=31536000 ; includeSubDomains</code>

===Best Practices===

* Apache
:Edit your apache configuration file and add the following to your VirtualHost. 
::<code>Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"</code>

* nginx
:Edit your nginx configuration file and add the following snippet. 
::<code>add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";</code>

* lighttpd
:Edit your lighttpd configuration file and add the following snippet. 
::<code>setenv.add-response-header = ("Strict-Transport-Security" => "max-age=63072000; includeSubdomains",)</code>

* IIS

===References===

* https://tools.ietf.org/html/rfc6797
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
* https://www.chromium.org/hsts
* https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
* https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html

==Public Key Pinning Extension for HTTP (HPKP)==

HTTP Public Key Pinning (HPKP) is a security mechanism which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates. (For example, sometimes attackers can compromise certificate authorities, and then can mis-issue certificates for a web origin.) The HTTPS web server serves a list of public key hashes, and on subsequent connections clients expect that server to use 1 or more of those public keys in its certificate chain.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| pin-sha256="<sha256>"
| The quoted string is the Base64 encoded Subject Public Key Information (SPKI) fingerprint. It is possible to specify multiple pins for different public keys. Some browsers might allow other hashing algorithms than SHA-256 in the future.
|-
| max-age=SECONDS
| The time, in seconds, that the browser should remember that this site is only to be accessed using one of the pinned keys.
|-
| includeSubDomains
| If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
|-
| report-uri="<URL>"
| If this optional parameter is specified, pin validation failures are reported to the given URL.
|}

===Example===

Public-Key-Pins: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="http://example.com/pkp-report"; max-age=10000; includeSubDomains

===Best Practices===

* Apache
:Edit your apache configuration file and add the following to your VirtualHost. 
::<code>Header set Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains"</code>

* nginx
:Edit your nginx configuration file and add the following snippet. 
::<code>add_header Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains";</code>

* lighttpd
:Edit your lighttpd configuration file and add the following snippet. 
::<code>setenv.add-response-header = ("Public-Key-Pins" => "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains",)</code>

* IIS

===References===

* https://tools.ietf.org/html/rfc7469
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
* https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
* https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html

==X-Frame-Options==

X-Frame-Options response header improve the protection of web applications against Clickjacking. It declares a policy communicated from a host to the client browser on whether the browser must not display the transmitted content in frames of other web pages.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| deny
| No rendering within a frame.
|-
| sameorigin
| No rendering if origin mismatch.
|-
| allow-from: DOMAIN
| Allows rendering if framed by frame loaded from DOMAIN.
|-
| allowall
| Allows rendering.
|}

===Example===

<code>X-Frame-Options: deny</code>

===Best Practices===

* Apache
:Add this line below into your site's configuration to configure Apache to send X-Frame-Options header for all pages. 
::<code>Header set X-Frame-Options DENY</code>

* nginx
:Add snippet below into configuration file to send X-Frame-Options header. 
::<code>add_header X-Frame-Options "DENY";</code>

* lighttpd
:Add snippet below into configuration file to send X-Frame-Options header. 
::<code>setenv.add-response-header = ("X-Frame-Options" => "DENY",)</code>

* IIS

===References===

* https://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01
* https://tools.ietf.org/html/draft-ietf-websec-frame-options-00
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers

==X-XSS-Protection==

This header enables the Cross-site scripting (XSS) filter.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| 0
| Filter disabled.
|-
| 1
| Filter enabled. If a cross-site scripting attack is detected, in order to stop the attack, the browser will sanitize the page.
|-
| 1; mode=block
| Filter enabled. Rather than sanitize the page, when a XSS attack is detected, the browser will prevent rendering of the page.
|-
| 1; report=http://[YOURDOMAIN]/your_report_URI
| Filter enabled. The browser will sanitize the page and report the violation. This is a Chromium function utilizing CSP violation reports to send details to a URI of your choice.
|}

===Example===

<code>X-XSS-Protection: 1; mode=block</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set X-XSS-Protection: 1; mode=block</code>

* nginx
:<code>add_header X-XSS-Protection "1;mode=block";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-XSS-Protection" => "1; mode=block",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://www.virtuesecurity.com/blog/understanding-xss-auditor/
* https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers
* http://zinoui.com/blog/security-http-headers#x-xss-protection

==X-Content-Type-Options==

Setting this header will prevent MSIE from interpreting files as something else than declared by the content type in the HTTP headers.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| nosniff
| will prevent Internet Explorer from MIME-sniffing a response away from the declared content-type.
|}

===Example===

<code>X-Content-Type-Options: nosniff</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set X-Content-Type-Options: nosniff</code>

* nginx
:<code>add_header X-Content-Type-Options "nosniff";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-Content-Type-Options" => "nosniff",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/

==Content-Security-Policy==

Content Security Policy requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including Cross-site scripting and other cross-site injections.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| default-src
| Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback).
|-
| script-src
| Define which scripts the protected resource can execute.
|-
| object-src
| Define from where the protected resource can load plugins.
|-
| style-src
| Define which styles (CSS) the user applies to the protected resource.
|-
| img-src
| Define from where the protected resource can load images.
|-
| media-src
| Define from where the protected resource can load video and audio.
|-
| frame-src
| Define from where the protected resource can embed frames.
|-
| font-src
| Define from where the protected resource can load fonts.
|-
| connect-src
| Define which URIs the protected resource can load using script interfaces.
|-
| form-action
| Define which URIs can be used as the action of HTML form elements.
|-
| sandbox
| Specifies an HTML sandbox policy that the user agent applies to the protected resource.
|-
| script-nonce
| Define script execution by requiring the presence of the specified nonce on script elements.
|-
| plugin-types
| Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded.
|-
| reflected-xss
| Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header.
|-
| report-uri
| Specifies a URI to which the user agent sends reports about policy violation.
|}

===Example===

<code>Content-Security-Policy: script-src 'self'</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set Content-Security-Policy: script-src 'self'</code>

* nginx
:<code>add_header Content-Security-Policy "script-src 'self'";</code>

* lighttpd
:<code>setenv.add-response-header = ("Content-Security-Policy" => "script-src 'self'",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* http://www.cspplayground.com/home
* https://scotthelme.co.uk/content-security-policy-an-introduction/

=Tools and Libraries=
A list of tools that can help you to achieve the on of the goals of this project.

==High-Tech Bridge Web Security Scanner==

An online service that will retrieve and analyse headers syntax and proper configuration in a comprehensive way.
It will be able for instance to highlight Public-Key-Pins that matches one certificate of the chain or if Content-Security-Policy contains values that could be unsafe or too permissive.

Site: [https://www.htbridge.com/websec/ https://www.htbridge.com/websec/]

==hsecscan==

A security scanner for HTTP response headers.

Github: [https://github.com/riramar/hsecscan https://github.com/riramar/hsecscan]

==securityheaders.io==

There are services out there that will analyse the HTTP response headers of other sites but I also wanted to add a rating system to the results. The HTTP response headers that this site analyses provide huge levels of protection and it's important that sites deploy them. Hopefully, by providing an easy mechanism to assess them, and further information on how to deploy missing headers, we can drive up the usage of security based headers across the web.

Site: [https://securityheaders.io https://securityheaders.io]

==report-uri.io==

When a site deploys a Content Security Policy or HTTP Public Key Pinning, the browser will enforce the security policies declared by the site. This is great as it offers visitors more protection but the only problem is, the host doesn't know that there's a problem. The browser will block malicious content, such as an XSS attack, but the host wouldn't know anything about it and as such, can't resolve the problem. This is the problem that report-uri.io fixes. With your own unique reporting endpoint the browser can send a violation report to us and you can monitor exactly what is happening on your site. You can see what security policies are being triggered, where and why.

Site: [https://report-uri.io https://report-uri.io]

==secureheaders==

secure_headers is a library for ruby with a global config, per request overrides, and rack milddleware that enables you customize your application settings.

Github: [https://github.com/twitter/secureheaders https://github.com/twitter/secureheaders]

==Security Header Injection Module (SHIM)==

SHIM is a HTTP module that provides protection for many vulnerabilities by injecting security-specific HTTP headers into ASP.NET web applications.

Site: [https://shim.codeplex.com https://shim.codeplex.com]

==http_hardening==

Puppet module to enable, configure and manage secure http headers in web servers.

Github: [https://github.com/amenezes/http_hardening http_hardening] 
Forge: [https://forge.puppet.com/amenezes/http_hardening http_hardening at forge | puppetlabs]

=FAQs=

; What is HTTP header?
: HTTP header fields are components of the header section of request and response messages in the Hypertext Transfer Protocol (HTTP). They define the operating parameters of an HTTP transaction.

; Is there a standard for HTTP headers?
: A core set of fields is standardized by the Internet Engineering Task Force (IETF) in RFCs 7230, 7231, 7232, 7233, 7234, and 7235. The permanent registry of header fields and repository of provisional registrations are maintained by the IANA. Additional field names and permissible values may be defined by each application. Non-standard header fields were conventionally marked by prefixing the field name with X- but this convention was deprecated in June 2012 because of the inconveniences it caused when non-standard fields became standard. An earlier restriction on use of Downgraded- was lifted in March 2013.

= Acknowledgements =
==Contributors==
OWASP Secure Headers Project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* [https://www.owasp.org/index.php/User:Riramar Ricardo Iramar]
* [https://www.owasp.org/index.php/User:Jmanico Jim Manico]
* [https://www.owasp.org/index.php/Special:Contributions/Amenezes Alexandre Menezes]

= Road Map and Getting Involved =

'''2016 Priorities'''

== To Do ==

OWASP Secure Headers Project intends to raise awareness and usage of headers sent by the server that can increase security. We'll aim to bring this about by:

* Producing open source, easily implemented, well documented code libraries that enable these headers for a variety of platforms. We'll prioritize creating and publicizing Node.JS, PHP, Ruby, and Java, but will eventually reach out towards edge cases like Go, Python and others. The key is to make this accessible as possible to developers.

* Improve constantly hsecscan tool to detect bad practices and provide link to the best practices above.

* Perform public to scan websites using hsecscan and view stats regarding these headers. Automated scanning of the top 1m sites on the web; filtering of said sites to view stats across industries and countries; published database dumps for public consumption/tools; scanning of individual sites; comparing multiple scanned sites.

* Consistent reports regarding this secure headers, their usage, any changes to existing headers.

Involvement in the development and promotion of OWASP Secure Headers Project is actively encouraged!
You do not have to be a security expert in order to contribute.
If you want to help send an email to [mailto:ricardo.iramar@owasp.org ricardo.iramar@owasp.org].

== Doing ==

* Including how to set properly secure headers on IIS.

== Done ==

* Creating secure best practices implementations including how to set properly secure headers on the most common platforms (eg. Apache, NGINX and Lighttpd).

__NOTOC__ <headertabs />

[[Category:OWASP Project]]

OWASP Secure Headers Project

2016-04-14T17:18:52Z

ADHTB: /* Tools and Libraries */

=Main=

[[File:Incubator_banner.jpg| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Secure Headers Project==

OWASP Secure Headers Project involves setting headers from the server is easy and often doesn't require any code changes. Once set, they can restrict modern browsers from running into easily preventable vulnerabilities. OWASP Secure Headers Project intends to raise awareness and use of these headers.

==Introduction==

HTTP headers are well known and also despised. Seeking the balance between usability and security developers implement functionality through the headers that can make your more versatile or secure application. But in practice how the headers are being implemented? What sites follow the best implementation practices? Big companies, small, all or none?

==Description==

We aim to publish reports on header usage stats, developments and changes. Code libraries that make these headers easily accessible to developers on a range of platforms. Data sets concerning the general usage of these headers.

==Licensing==
OWASP Secure Headers is free to use. It is licensed under the Apache 2.0 license.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP Secure Headers Project? ==

OWASP Secure Headers Project provides:

* Security best practices for HTTP headers
* Security tools for HTTP headers

== Project Leader ==

[[User:Riramar | Ricardo Iramar]]

== Project Contributors ==

[[User:Jmanico | Jim Manico]] 
[[User:Amenezes | Alexandre Menezes]]

== Related Projects ==

* [[List of useful HTTP headers]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Links ==

* [https://github.com/riramar/hsecscan hsecscan]

== Email List ==

[https://lists.owasp.org/mailman/listinfo/owasp_secure_headers_project Project Email List]

== News and Events ==
* [14 Dec 2015] Reborning from the ashes

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

=Headers=

A list of headers related to security and how to implement them properly.

* [[#HTTP Strict Transport Security (HSTS) | HTTP Strict Transport Security (HSTS)]]
* [[#Public Key Pinning Extension for HTTP (HPKP) | Public Key Pinning Extension for HTTP (HPKP)]]
* [[#X-Frame-Options | X-Frame-Options]]
* [[#X-XSS-Protection | X-XSS-Protection]]
* [[#X-Content-Type-Options | X-Content-Type-Options]]
* [[#Content-Security-Policy | Content-Security-Policy]]

==HTTP Strict Transport Security (HSTS)==

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797. A server implements an HSTS policy by supplying a header (Strict-Transport-Security) over an HTTPS connection (HSTS headers over HTTP are ignored).

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| max-age=SECONDS
| The time, in seconds, that the browser should remember that this site is only to be accessed using HTTPS.
|-
| includeSubDomains
| If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
|}

===Example===

<code>Strict-Transport-Security: max-age=31536000 ; includeSubDomains</code>

===Best Practices===

* Apache
:Edit your apache configuration file and add the following to your VirtualHost. 
::<code>Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"</code>

* nginx
:Edit your nginx configuration file and add the following snippet. 
::<code>add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";</code>

* lighttpd
:Edit your lighttpd configuration file and add the following snippet. 
::<code>setenv.add-response-header = ("Strict-Transport-Security" => "max-age=63072000; includeSubdomains",)</code>

* IIS

===References===

* https://tools.ietf.org/html/rfc6797
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
* https://www.chromium.org/hsts
* https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
* https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html

==Public Key Pinning Extension for HTTP (HPKP)==

HTTP Public Key Pinning (HPKP) is a security mechanism which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates. (For example, sometimes attackers can compromise certificate authorities, and then can mis-issue certificates for a web origin.) The HTTPS web server serves a list of public key hashes, and on subsequent connections clients expect that server to use 1 or more of those public keys in its certificate chain.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| pin-sha256="<sha256>"
| The quoted string is the Base64 encoded Subject Public Key Information (SPKI) fingerprint. It is possible to specify multiple pins for different public keys. Some browsers might allow other hashing algorithms than SHA-256 in the future.
|-
| max-age=SECONDS
| The time, in seconds, that the browser should remember that this site is only to be accessed using one of the pinned keys.
|-
| includeSubDomains
| If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
|-
| report-uri="<URL>"
| If this optional parameter is specified, pin validation failures are reported to the given URL.
|}

===Example===

Public-Key-Pins: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="http://example.com/pkp-report"; max-age=10000; includeSubDomains

===Best Practices===

* Apache
:Edit your apache configuration file and add the following to your VirtualHost. 
::<code>Header set Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains"</code>

* nginx
:Edit your nginx configuration file and add the following snippet. 
::<code>add_header Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains";</code>

* lighttpd
:Edit your lighttpd configuration file and add the following snippet. 
::<code>setenv.add-response-header = ("Public-Key-Pins" => "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains",)</code>

* IIS

===References===

* https://tools.ietf.org/html/rfc7469
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
* https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
* https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html

==X-Frame-Options==

X-Frame-Options response header improve the protection of web applications against Clickjacking. It declares a policy communicated from a host to the client browser on whether the browser must not display the transmitted content in frames of other web pages.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| deny
| No rendering within a frame.
|-
| sameorigin
| No rendering if origin mismatch.
|-
| allow-from: DOMAIN
| Allow rendering if framed by frame loaded from DOMAIN.
|}

===Example===

<code>X-Frame-Options: deny</code>

===Best Practices===

* Apache
:Add this line below into your site's configuration to configure Apache to send X-Frame-Options header for all pages. 
::<code>Header set X-Frame-Options DENY</code>

* nginx
:Add snippet below into configuration file to send X-Frame-Options header. 
::<code>add_header X-Frame-Options "DENY";</code>

* lighttpd
:Add snippet below into configuration file to send X-Frame-Options header. 
::<code>setenv.add-response-header = ("X-Frame-Options" => "DENY",)</code>

* IIS

===References===

* https://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01
* https://tools.ietf.org/html/draft-ietf-websec-frame-options-00
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers

==X-XSS-Protection==

This header enables the Cross-site scripting (XSS) filter.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| 0
| Filter disabled.
|-
| 1
| Filter enabled. If a cross-site scripting attack is detected, in order to stop the attack, the browser will sanitize the page.
|-
| 1; mode=block
| Filter enabled. Rather than sanitize the page, when a XSS attack is detected, the browser will prevent rendering of the page.
|-
| 1; report=http://[YOURDOMAIN]/your_report_URI
| Filter enabled. The browser will sanitize the page and report the violation. This is a Chromium function utilizing CSP violation reports to send details to a URI of your choice.
|}

===Example===

<code>X-XSS-Protection: 1; mode=block</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set X-XSS-Protection: 1; mode=block</code>

* nginx
:<code>add_header X-XSS-Protection "1;mode=block";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-XSS-Protection" => "1; mode=block",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://www.virtuesecurity.com/blog/understanding-xss-auditor/
* https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers
* http://zinoui.com/blog/security-http-headers#x-xss-protection

==X-Content-Type-Options==

Setting this header will prevent MSIE from interpreting files as something else than declared by the content type in the HTTP headers.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| nosniff
| will prevent Internet Explorer from MIME-sniffing a response away from the declared content-type.
|}

===Example===

<code>X-Content-Type-Options: nosniff</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set X-Content-Type-Options: nosniff</code>

* nginx
:<code>add_header X-Content-Type-Options "nosniff";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-Content-Type-Options" => "nosniff",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/

==Content-Security-Policy==

Content Security Policy requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including Cross-site scripting and other cross-site injections.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| default-src
| Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback).
|-
| script-src
| Define which scripts the protected resource can execute.
|-
| object-src
| Define from where the protected resource can load plugins.
|-
| style-src
| Define which styles (CSS) the user applies to the protected resource.
|-
| img-src
| Define from where the protected resource can load images.
|-
| media-src
| Define from where the protected resource can load video and audio.
|-
| frame-src
| Define from where the protected resource can embed frames.
|-
| font-src
| Define from where the protected resource can load fonts.
|-
| connect-src
| Define which URIs the protected resource can load using script interfaces.
|-
| form-action
| Define which URIs can be used as the action of HTML form elements.
|-
| sandbox
| Specifies an HTML sandbox policy that the user agent applies to the protected resource.
|-
| script-nonce
| Define script execution by requiring the presence of the specified nonce on script elements.
|-
| plugin-types
| Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded.
|-
| reflected-xss
| Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header.
|-
| report-uri
| Specifies a URI to which the user agent sends reports about policy violation.
|}

===Example===

<code>Content-Security-Policy: script-src 'self'</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set Content-Security-Policy: script-src 'self'</code>

* nginx
:<code>add_header Content-Security-Policy "script-src 'self'";</code>

* lighttpd
:<code>setenv.add-response-header = ("Content-Security-Policy" => "script-src 'self'",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* http://www.cspplayground.com/home
* https://scotthelme.co.uk/content-security-policy-an-introduction/

=Tools and Libraries=
A list of tools that can help you to achieve the on of the goals of this project.

==High-Tech Bridge Web Security Scanner==

An online service that will retrieve and analyse headers syntax and proper configuration in a comprehensive way.
It will be able for instance to highlight Public-Key-Pins that matches one certificate of the chain or if Content-Security-Policy contains values that could be unsafe or too permissive.

Site: [https://www.htbridge.com/websec/ https://www.htbridge.com/websec/]

==hsecscan==

A security scanner for HTTP response headers.

Github: [https://github.com/riramar/hsecscan https://github.com/riramar/hsecscan]

==securityheaders.io==

There are services out there that will analyse the HTTP response headers of other sites but I also wanted to add a rating system to the results. The HTTP response headers that this site analyses provide huge levels of protection and it's important that sites deploy them. Hopefully, by providing an easy mechanism to assess them, and further information on how to deploy missing headers, we can drive up the usage of security based headers across the web.

Site: [https://securityheaders.io https://securityheaders.io]

==report-uri.io==

When a site deploys a Content Security Policy or HTTP Public Key Pinning, the browser will enforce the security policies declared by the site. This is great as it offers visitors more protection but the only problem is, the host doesn't know that there's a problem. The browser will block malicious content, such as an XSS attack, but the host wouldn't know anything about it and as such, can't resolve the problem. This is the problem that report-uri.io fixes. With your own unique reporting endpoint the browser can send a violation report to us and you can monitor exactly what is happening on your site. You can see what security policies are being triggered, where and why.

Site: [https://report-uri.io https://report-uri.io]

==secureheaders==

secure_headers is a library for ruby with a global config, per request overrides, and rack milddleware that enables you customize your application settings.

Github: [https://github.com/twitter/secureheaders https://github.com/twitter/secureheaders]

==Security Header Injection Module (SHIM)==

SHIM is a HTTP module that provides protection for many vulnerabilities by injecting security-specific HTTP headers into ASP.NET web applications.

Site: [https://shim.codeplex.com https://shim.codeplex.com]

==http_hardening==

Puppet module to enable, configure and manage secure http headers in web servers.

Github: [https://github.com/amenezes/http_hardening http_hardening] 
Forge: [https://forge.puppet.com/amenezes/http_hardening http_hardening at forge | puppetlabs]

=FAQs=

; What is HTTP header?
: HTTP header fields are components of the header section of request and response messages in the Hypertext Transfer Protocol (HTTP). They define the operating parameters of an HTTP transaction.

; Is there a standard for HTTP headers?
: A core set of fields is standardized by the Internet Engineering Task Force (IETF) in RFCs 7230, 7231, 7232, 7233, 7234, and 7235. The permanent registry of header fields and repository of provisional registrations are maintained by the IANA. Additional field names and permissible values may be defined by each application. Non-standard header fields were conventionally marked by prefixing the field name with X- but this convention was deprecated in June 2012 because of the inconveniences it caused when non-standard fields became standard. An earlier restriction on use of Downgraded- was lifted in March 2013.

= Acknowledgements =
==Contributors==
OWASP Secure Headers Project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* [https://www.owasp.org/index.php/User:Riramar Ricardo Iramar]
* [https://www.owasp.org/index.php/User:Jmanico Jim Manico]
* [https://www.owasp.org/index.php/Special:Contributions/Amenezes Alexandre Menezes]

= Road Map and Getting Involved =

'''2016 Priorities'''

== To Do ==

OWASP Secure Headers Project intends to raise awareness and usage of headers sent by the server that can increase security. We'll aim to bring this about by:

* Producing open source, easily implemented, well documented code libraries that enable these headers for a variety of platforms. We'll prioritize creating and publicizing Node.JS, PHP, Ruby, and Java, but will eventually reach out towards edge cases like Go, Python and others. The key is to make this accessible as possible to developers.

* Improve constantly hsecscan tool to detect bad practices and provide link to the best practices above.

* Perform public to scan websites using hsecscan and view stats regarding these headers. Automated scanning of the top 1m sites on the web; filtering of said sites to view stats across industries and countries; published database dumps for public consumption/tools; scanning of individual sites; comparing multiple scanned sites.

* Consistent reports regarding this secure headers, their usage, any changes to existing headers.

Involvement in the development and promotion of OWASP Secure Headers Project is actively encouraged!
You do not have to be a security expert in order to contribute.
If you want to help send an email to [mailto:ricardo.iramar@owasp.org ricardo.iramar@owasp.org].

== Doing ==

* Including how to set properly secure headers on IIS.

== Done ==

* Creating secure best practices implementations including how to set properly secure headers on the most common platforms (eg. Apache, NGINX and Lighttpd).

__NOTOC__ <headertabs />

[[Category:OWASP Project]]

OWASP Secure Headers Project

2016-04-14T17:12:16Z

ADHTB: /* Tools and Libraries */

=Main=

[[File:Incubator_banner.jpg| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Secure Headers Project==

OWASP Secure Headers Project involves setting headers from the server is easy and often doesn't require any code changes. Once set, they can restrict modern browsers from running into easily preventable vulnerabilities. OWASP Secure Headers Project intends to raise awareness and use of these headers.

==Introduction==

HTTP headers are well known and also despised. Seeking the balance between usability and security developers implement functionality through the headers that can make your more versatile or secure application. But in practice how the headers are being implemented? What sites follow the best implementation practices? Big companies, small, all or none?

==Description==

We aim to publish reports on header usage stats, developments and changes. Code libraries that make these headers easily accessible to developers on a range of platforms. Data sets concerning the general usage of these headers.

==Licensing==
OWASP Secure Headers is free to use. It is licensed under the Apache 2.0 license.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP Secure Headers Project? ==

OWASP Secure Headers Project provides:

* Security best practices for HTTP headers
* Security tools for HTTP headers

== Project Leader ==

[[User:Riramar | Ricardo Iramar]]

== Project Contributors ==

[[User:Jmanico | Jim Manico]] 
[[User:Amenezes | Alexandre Menezes]]

== Related Projects ==

* [[List of useful HTTP headers]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Links ==

* [https://github.com/riramar/hsecscan hsecscan]

== Email List ==

[https://lists.owasp.org/mailman/listinfo/owasp_secure_headers_project Project Email List]

== News and Events ==
* [14 Dec 2015] Reborning from the ashes

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

=Headers=

A list of headers related to security and how to implement them properly.

* [[#HTTP Strict Transport Security (HSTS) | HTTP Strict Transport Security (HSTS)]]
* [[#Public Key Pinning Extension for HTTP (HPKP) | Public Key Pinning Extension for HTTP (HPKP)]]
* [[#X-Frame-Options | X-Frame-Options]]
* [[#X-XSS-Protection | X-XSS-Protection]]
* [[#X-Content-Type-Options | X-Content-Type-Options]]
* [[#Content-Security-Policy | Content-Security-Policy]]

==HTTP Strict Transport Security (HSTS)==

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797. A server implements an HSTS policy by supplying a header (Strict-Transport-Security) over an HTTPS connection (HSTS headers over HTTP are ignored).

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| max-age=SECONDS
| The time, in seconds, that the browser should remember that this site is only to be accessed using HTTPS.
|-
| includeSubDomains
| If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
|}

===Example===

<code>Strict-Transport-Security: max-age=31536000 ; includeSubDomains</code>

===Best Practices===

* Apache
:Edit your apache configuration file and add the following to your VirtualHost. 
::<code>Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"</code>

* nginx
:Edit your nginx configuration file and add the following snippet. 
::<code>add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";</code>

* lighttpd
:Edit your lighttpd configuration file and add the following snippet. 
::<code>setenv.add-response-header = ("Strict-Transport-Security" => "max-age=63072000; includeSubdomains",)</code>

* IIS

===References===

* https://tools.ietf.org/html/rfc6797
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
* https://www.chromium.org/hsts
* https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
* https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html

==Public Key Pinning Extension for HTTP (HPKP)==

HTTP Public Key Pinning (HPKP) is a security mechanism which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates. (For example, sometimes attackers can compromise certificate authorities, and then can mis-issue certificates for a web origin.) The HTTPS web server serves a list of public key hashes, and on subsequent connections clients expect that server to use 1 or more of those public keys in its certificate chain.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| pin-sha256="<sha256>"
| The quoted string is the Base64 encoded Subject Public Key Information (SPKI) fingerprint. It is possible to specify multiple pins for different public keys. Some browsers might allow other hashing algorithms than SHA-256 in the future.
|-
| max-age=SECONDS
| The time, in seconds, that the browser should remember that this site is only to be accessed using one of the pinned keys.
|-
| includeSubDomains
| If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
|-
| report-uri="<URL>"
| If this optional parameter is specified, pin validation failures are reported to the given URL.
|}

===Example===

Public-Key-Pins: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="http://example.com/pkp-report"; max-age=10000; includeSubDomains

===Best Practices===

* Apache
:Edit your apache configuration file and add the following to your VirtualHost. 
::<code>Header set Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains"</code>

* nginx
:Edit your nginx configuration file and add the following snippet. 
::<code>add_header Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains";</code>

* lighttpd
:Edit your lighttpd configuration file and add the following snippet. 
::<code>setenv.add-response-header = ("Public-Key-Pins" => "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains",)</code>

* IIS

===References===

* https://tools.ietf.org/html/rfc7469
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
* https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
* https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html

==X-Frame-Options==

X-Frame-Options response header improve the protection of web applications against Clickjacking. It declares a policy communicated from a host to the client browser on whether the browser must not display the transmitted content in frames of other web pages.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| deny
| No rendering within a frame.
|-
| sameorigin
| No rendering if origin mismatch.
|-
| allow-from: DOMAIN
| Allow rendering if framed by frame loaded from DOMAIN.
|}

===Example===

<code>X-Frame-Options: deny</code>

===Best Practices===

* Apache
:Add this line below into your site's configuration to configure Apache to send X-Frame-Options header for all pages. 
::<code>Header set X-Frame-Options DENY</code>

* nginx
:Add snippet below into configuration file to send X-Frame-Options header. 
::<code>add_header X-Frame-Options "DENY";</code>

* lighttpd
:Add snippet below into configuration file to send X-Frame-Options header. 
::<code>setenv.add-response-header = ("X-Frame-Options" => "DENY",)</code>

* IIS

===References===

* https://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01
* https://tools.ietf.org/html/draft-ietf-websec-frame-options-00
* https://www.owasp.org/index.php/List_of_useful_HTTP_headers

==X-XSS-Protection==

This header enables the Cross-site scripting (XSS) filter.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| 0
| Filter disabled.
|-
| 1
| Filter enabled. If a cross-site scripting attack is detected, in order to stop the attack, the browser will sanitize the page.
|-
| 1; mode=block
| Filter enabled. Rather than sanitize the page, when a XSS attack is detected, the browser will prevent rendering of the page.
|-
| 1; report=http://[YOURDOMAIN]/your_report_URI
| Filter enabled. The browser will sanitize the page and report the violation. This is a Chromium function utilizing CSP violation reports to send details to a URI of your choice.
|}

===Example===

<code>X-XSS-Protection: 1; mode=block</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set X-XSS-Protection: 1; mode=block</code>

* nginx
:<code>add_header X-XSS-Protection "1;mode=block";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-XSS-Protection" => "1; mode=block",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://www.virtuesecurity.com/blog/understanding-xss-auditor/
* https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers
* http://zinoui.com/blog/security-http-headers#x-xss-protection

==X-Content-Type-Options==

Setting this header will prevent MSIE from interpreting files as something else than declared by the content type in the HTTP headers.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| nosniff
| will prevent Internet Explorer from MIME-sniffing a response away from the declared content-type.
|}

===Example===

<code>X-Content-Type-Options: nosniff</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set X-Content-Type-Options: nosniff</code>

* nginx
:<code>add_header X-Content-Type-Options "nosniff";</code>

* lighttpd
:<code>setenv.add-response-header = ("X-Content-Type-Options" => "nosniff",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/

==Content-Security-Policy==

Content Security Policy requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including Cross-site scripting and other cross-site injections.

===Values===

{| class="wikitable"
|-
! Value
! Description
|-
| default-src
| Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback).
|-
| script-src
| Define which scripts the protected resource can execute.
|-
| object-src
| Define from where the protected resource can load plugins.
|-
| style-src
| Define which styles (CSS) the user applies to the protected resource.
|-
| img-src
| Define from where the protected resource can load images.
|-
| media-src
| Define from where the protected resource can load video and audio.
|-
| frame-src
| Define from where the protected resource can embed frames.
|-
| font-src
| Define from where the protected resource can load fonts.
|-
| connect-src
| Define which URIs the protected resource can load using script interfaces.
|-
| form-action
| Define which URIs can be used as the action of HTML form elements.
|-
| sandbox
| Specifies an HTML sandbox policy that the user agent applies to the protected resource.
|-
| script-nonce
| Define script execution by requiring the presence of the specified nonce on script elements.
|-
| plugin-types
| Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded.
|-
| reflected-xss
| Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header.
|-
| report-uri
| Specifies a URI to which the user agent sends reports about policy violation.
|}

===Example===

<code>Content-Security-Policy: script-src 'self'</code>

===Best Practices===

Add appropriate snippet into configuration file. 

* Apache
:<code>Header set Content-Security-Policy: script-src 'self'</code>

* nginx
:<code>add_header Content-Security-Policy "script-src 'self'";</code>

* lighttpd
:<code>setenv.add-response-header = ("Content-Security-Policy" => "script-src 'self'",)</code>

* IIS

===References===

* https://www.owasp.org/index.php/List_of_useful_HTTP_headers
* http://www.cspplayground.com/home
* https://scotthelme.co.uk/content-security-policy-an-introduction/

=Tools and Libraries=
A list of tools that can help you to achieve the on of the goals of this project.

==High-Tech Bridge Web Security Scanner==

An online service that will retrieve and analyze headers syntax and proper configuration.
It will be able for instance to highlight Public-Key-Pins that matches one certificate of the chain or if Content-Security-Policy contains values that could be unsafe or too permissive.

Site: [https://www.htbridge.com/websec/ https://www.htbridge.com/websec/]

==hsecscan==

A security scanner for HTTP response headers.

Github: [https://github.com/riramar/hsecscan https://github.com/riramar/hsecscan]

==securityheaders.io==

There are services out there that will analyse the HTTP response headers of other sites but I also wanted to add a rating system to the results. The HTTP response headers that this site analayses provide huge levels of protection and it's important that sites deploy them. Hopefully, by providing an easy mechanism to assess them, and further information on how to deploy missing headers, we can drive up the usage of security based headers across the web.

Site: [https://securityheaders.io https://securityheaders.io]

==report-uri.io==

When a site deploys a Content Security Policy or HTTP Public Key Pinning, the browser will enforce the security policies declared by the site. This is great as it offers visitors more protection but the only problem is, the host doesn't know that there's a problem. The browser will block malicious content, such as an XSS attack, but the host wouldn't know anything about it and as such, can't resolve the problem. This is the problem that report-uri.io fixes. With your own unique reporting endpoint the browser can send a violation report to us and you can monitor exactly what is happening on your site. You can see what security policies are being triggered, where and why.

Site: [https://report-uri.io https://report-uri.io]

==secureheaders==

secure_headers is a library for ruby with a global config, per request overrides, and rack milddleware that enables you customize your application settings.

Github: [https://github.com/twitter/secureheaders https://github.com/twitter/secureheaders]

==Security Header Injection Module (SHIM)==

SHIM is a HTTP module that provides protection for many vulnerabilities by injecting security-specific HTTP headers into ASP.NET web applications.

Site: [https://shim.codeplex.com https://shim.codeplex.com]

==http_hardening==

Puppet module to enable, configure and manage secure http headers in web servers.

Github: [https://github.com/amenezes/http_hardening http_hardening] 
Forge: [https://forge.puppet.com/amenezes/http_hardening http_hardening at forge | puppetlabs]

=FAQs=

; What is HTTP header?
: HTTP header fields are components of the header section of request and response messages in the Hypertext Transfer Protocol (HTTP). They define the operating parameters of an HTTP transaction.

; Is there a standard for HTTP headers?
: A core set of fields is standardized by the Internet Engineering Task Force (IETF) in RFCs 7230, 7231, 7232, 7233, 7234, and 7235. The permanent registry of header fields and repository of provisional registrations are maintained by the IANA. Additional field names and permissible values may be defined by each application. Non-standard header fields were conventionally marked by prefixing the field name with X- but this convention was deprecated in June 2012 because of the inconveniences it caused when non-standard fields became standard. An earlier restriction on use of Downgraded- was lifted in March 2013.

= Acknowledgements =
==Contributors==
OWASP Secure Headers Project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* [https://www.owasp.org/index.php/User:Riramar Ricardo Iramar]
* [https://www.owasp.org/index.php/User:Jmanico Jim Manico]
* [https://www.owasp.org/index.php/Special:Contributions/Amenezes Alexandre Menezes]

= Road Map and Getting Involved =

'''2016 Priorities'''

== To Do ==

OWASP Secure Headers Project intends to raise awareness and usage of headers sent by the server that can increase security. We'll aim to bring this about by:

* Producing open source, easily implemented, well documented code libraries that enable these headers for a variety of platforms. We'll prioritize creating and publicizing Node.JS, PHP, Ruby, and Java, but will eventually reach out towards edge cases like Go, Python and others. The key is to make this accessible as possible to developers.

* Improve constantly hsecscan tool to detect bad practices and provide link to the best practices above.

* Perform public to scan websites using hsecscan and view stats regarding these headers. Automated scanning of the top 1m sites on the web; filtering of said sites to view stats across industries and countries; published database dumps for public consumption/tools; scanning of individual sites; comparing multiple scanned sites.

* Consistent reports regarding this secure headers, their usage, any changes to existing headers.

Involvement in the development and promotion of OWASP Secure Headers Project is actively encouraged!
You do not have to be a security expert in order to contribute.
If you want to help send an email to [mailto:ricardo.iramar@owasp.org ricardo.iramar@owasp.org].

== Doing ==

* Including how to set properly secure headers on IIS.

== Done ==

* Creating secure best practices implementations including how to set properly secure headers on the most common platforms (eg. Apache, NGINX and Lighttpd).

__NOTOC__ <headertabs />

[[Category:OWASP Project]]

Transport Layer Protection Cheat Sheet

2015-11-19T11:00:49Z

ADHTB: /* Online */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

This cheat sheet provides a simple model to follow when implementing transport layer protection for an application. Although the concept of SSL is known to many, the actual details and security specific decisions of implementation are often poorly understood and frequently result in insecure deployments. This article establishes clear rules which provide guidance on securely designing and configuring transport layer security for an application. This article is focused on the use of SSL/TLS between a web application and a web browser, but we also encourage the use of SSL/TLS or other network encryption technologies, such as VPN, on back end and other non-browser based connections. 

== Architectural Decision ==

An architectural decision must be made to determine the appropriate method to protect data when it is being transmitted. The most common options available to corporations are Virtual Private Networks (VPN) or a SSL/TLS model commonly used by web applications. The selected model is determined by the business needs of the particular organization. For example, a VPN connection may be the best design for a partnership between two companies that includes mutual access to a shared server over a variety of protocols. Conversely, an Internet facing enterprise web application would likely be best served by a SSL/TLS model.

This cheat sheet will focus on security considerations when the SSL/TLS model is selected. This is a frequently used model for publicly accessible web applications.

= Providing Transport Layer Protection with SSL/TLS =

== Benefits ==

The primary benefit of transport layer security is the protection of web application data from unauthorized disclosure and modification when it is transmitted between clients (web browsers) and the web application server, and between the web application server and back end and other non-browser based enterprise components.

The server validation component of TLS provides authentication of the server to the client. If configured to require client side certificates, TLS can also play a role in client authentication to the server. However, in practice client side certificates are not often used in lieu of username and password based authentication models for clients.

TLS also provides two additional benefits that are commonly overlooked; integrity guarantees and replay prevention. A TLS stream of communication contains built-in controls to prevent tampering with any portion of the encrypted data. In addition, controls are also built-in to prevent a captured stream of TLS data from being replayed at a later time.

It should be noted that TLS provides the above guarantees to data during transmission. TLS does not offer any of these security benefits to data that is at rest. Therefore appropriate security controls must be added to protect data while at rest within the application or within data stores.

== Basic Requirements ==

The basic requirements for using TLS are: access to a Public Key Infrastructure (PKI) in order to obtain certificates, access to a directory or an Online Certificate Status Protocol (OCSP) responder in order to check certificate revocation status, and agreement/ability to support a minimum configuration of protocol versions and protocol options for each version.

== SSL vs. TLS ==

The terms, Secure Socket Layer (SSL) and Transport Layer Security (TLS) are often used interchangeably. In fact, SSL v3.1 is equivalent to TLS v1.0. However, different versions of SSL and TLS are supported by modern web browsers and by most modern web frameworks and platforms. For the purposes of this cheat sheet we will refer to the technology generically as TLS. Recommendations regarding the use of SSL and TLS protocols, as well as browser support for TLS, can be found in the rule below titled [[Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Protocols| "Only Support Strong Protocols"]].

[[Image:Asvs_cryptomodule.gif|thumb|350px|right|Cryptomodule Parts and Operation]]

== When to Use a FIPS 140-2 Validated Cryptomodule ==

If the web application may be the target of determined attackers (a common threat model for Internet accessible applications handling sensitive data), it is strongly advised to use TLS services that are provided by [http://csrc.nist.gov/groups/STM/cmvp/validation.html FIPS 140-2 validated cryptomodules].

A cryptomodule, whether it is a software library or a hardware device, basically consists of three parts:

* Components that implement cryptographic algorithms (symmetric and asymmetric algorithms, hash algorithms, random number generator algorithms, and message authentication code algorithms)
* Components that call and manage cryptographic functions (inputs and outputs include cryptographic keys and so-called critical security parameters)
* A physical container around the components that implement cryptographic algorithms and the components that call and manage cryptographic functions

The security of a cryptomodule and its services (and the web applications that call the cryptomodule) depend on the correct implementation and integration of each of these three parts. In addition, the cryptomodule must be used and accessed securely. The includes consideration for:

* Calling and managing cryptographic functions
* Securely Handling inputs and output
* Ensuring the secure construction of the physical container around the components

In order to leverage the benefits of TLS it is important to use a TLS service (e.g. library, web framework, web application server) which has been FIPS 140-2 validated. In addition, the cryptomodule must be installed, configured and operated in either an approved or an allowed mode to provide a high degree of certainty that the FIPS 140-2 validated cryptomodule is providing the expected security services in the expected manner.

If the system is legally required to use FIPS 140-2 encryption (e.g., owned or operated by or on behalf of the U.S. Government) then TLS must be used and SSL disabled. Details on why SSL is unacceptable are described in Section 7.1 of [http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program].

Further reading on the use of TLS to protect highly sensitive data against determined attackers can be viewed in [http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf SP800-52 Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations]

== Secure Server Design ==

=== Rule - Use TLS for All Login Pages and All Authenticated Pages ===

The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session.

=== Rule - Use TLS on Any Networks (External and Internal) Transmitting Sensitive Data ===

All networks, both external and internal, which transmit sensitive data must utilize TLS or an equivalent transport layer security mechanism. It is not sufficient to claim that access to the internal network is "restricted to employees". Numerous recent data compromises have shown that the internal network can be breached by attackers. In these attacks, sniffers have been installed to access unencrypted sensitive data sent on the internal network.

=== Rule - Do Not Provide Non-TLS Pages for Secure Content ===

All pages which are available over TLS must not be available over a non-TLS connection. A user may inadvertently bookmark or manually type a URL to a HTTP page (e.g. http://example.com/myaccount) within the authenticated portion of the application. If this request is processed by the application then the response, and any sensitive data, would be returned to the user over the clear text HTTP.

=== Rule - Do Not Mix TLS and Non-TLS Content ===

A page that is available over TLS must be comprised completely of content which is transmitted over TLS. The page must not contain any content that is transmitted over unencrypted HTTP. This includes content from unrelated third party sites.

An attacker could intercept any of the data transmitted over the unencrypted HTTP and inject malicious content into the user's page. This malicious content would be included in the page even if the overall page is served over TLS. In addition, an attacker could steal the user's session cookie that is transmitted with any non-TLS requests. This is possible if the cookie's 'secure' flag is not set. See the rule 'Use "Secure" Cookie Flag'

=== Rule - Use "Secure" Cookie Flag ===

The "Secure" flag must be set for all user cookies. Failure to use the "secure" flag enables an attacker to access the session cookie by tricking the user's browser into submitting a request to an unencrypted page on the site. This attack is possible even if the server is not configured to offer HTTP content since the attacker is monitoring the requests and does not care if the server responds with a 404 or doesn't respond at all.

=== Rule - Keep Sensitive Data Out of the URL ===

Sensitive data must not be transmitted via URL arguments. A more appropriate place is to store sensitive data in a server side repository or within the user's session. When using TLS the URL arguments and values are encrypted during transit. However, there are two methods that the URL arguments and values could be exposed.

1. The entire URL is cached within the local user's browser history. This may expose sensitive data to any other user of the workstation.

2. The entire URL is exposed if the user clicks on a link to another HTTPS site. This may expose sensitive data within the referral field to the third party site. This exposure occurs in most browsers and will only occur on transitions between two TLS sites.

For example, a user following a link on [http://owasp.org https://example.com] which leads to [http://owasp.org https://someOtherexample.com] would expose the full URL of [http://owasp.org https://example.com] (including URL arguments) in the referral header (within most browsers). This would not be the case if the user followed a link on [http://owasp.org https://example.com] to [http://owasp.org http://someHTTPexample.com]

=== Rule - Prevent Caching of Sensitive Data ===

The TLS protocol provides confidentiality only for data in transit but it does not help with potential data leakage issues at the client or intermediary proxies. As a result, it is frequently prudent to instruct these nodes not to cache or persist sensitive data. One option is to add anticaching headers to relevant HTTP responses, (for example, "Cache-Control: no-cache, no-store" and "Expires: 0" for coverage of many modern browsers as of 2013). For compatibility with HTTP/1.0 (i.e., when user agents are really old or the webserver works around quirks by forcing HTTP/1.0) the response should also include the header "Pragma: no-cache". More information is available in [https://tools.ietf.org/html/rfc2616 HTTP 1.1 RFC 2616], section 14.9.

=== Rule - Use HTTP Strict Transport Security ===

See: [[HTTP Strict Transport Security]]

===Rule - Use Public Key Pinning===

See: [[Certificate and Public Key Pinning]]

 

== Server Certificate ==
Note: If using a FIPS 140-2 cryptomodule disregard the following rules and defer to the recommended configuration for the particular cryptomodule. Nevertheless we recommend to use this rules to audit your configuration.

=== Rule - Use Strong Keys & Protect Them ===

The private key used to generate the cipher key must be sufficiently strong for the anticipated lifetime of the private key and corresponding certificate. The current best practice is to select a key size of at least 2048 bits. Additional information on key lifetimes and comparable key strengths can be found in [http://www.keylength.com/en/compare/], [http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf NIST SP 800-57]. In addition, the private key must be stored in a location that is protected from unauthorized access.

=== Rule - Use a Certificate That Supports Required Domain Names ===

A user should never be presented with a certificate error, including prompts to reconcile domain or hostname mismatches, or expired certificates. If the application is available at both [https://owasp.org https://www.example.com] and [https://owasp.org https://example.com] then an appropriate certificate, or certificates, must be presented to accommodate the situation. The presence of certificate errors desensitizes users to TLS error messages and increases the possibility an attacker could launch a convincing phishing or man-in-the-middle attack.

For example, consider a web application accessible at [https://owasp.org https://abc.example.com] and [https://owasp.org https://xyz.example.com]. One certificate should be acquired for the host or server ''abc.example.com''; and a second certificate for host or server ''xyz.example.com''. In both cases, the hostname would be present in the Subject's Common Name (CN).

Alternatively, the Subject Alternate Names (SANs) can be used to provide a specific listing of multiple names where the certificate is valid. In the example above, the certificate could list the Subject's CN as ''example.com'', and list two SANs: ''abc.example.com'' and ''xyz.example.com''. These certificates are sometimes referred to as "multiple domain certificates".

=== Rule - Use Fully Qualified Names in Certificates ===

Use fully qualified names in the DNS name field, and do not use unqualifed names (e.g., 'www'), local names (e.g., 'localhost'), or private IP addresses (e.g., 192.168.1.1) in the DNS name field. Unqualifed names, local names, or private IP addresses violate the certificate specification.

=== Rule - Do Not Use Wildcard Certificates ===

You should refrain from using wildcard certificates. Though they are expedient at circumventing annoying user prompts, they also [[Least_privilege|violate the principal of least privilege]] and asks the user to trust all machines, including developer's machines, the secretary's machine in the lobby and the sign-in kiosk. Obtaining access to the private key is left as an exercise for the attacker, but its made much easier when stored on the file system unprotected.

Statistics gathered by Qualys for [http://media.blackhat.com/bh-us-10/presentations/Ristic/BlackHat-USA-2010-Ristic-Qualys-SSL-Survey-HTTP-Rating-Guide-slides.pdf Internet SSL Survey 2010] indicate wildcard certificates have a 4.4% share, so the practice is not standard for public facing hosts. Finally, wildcard certificates violate [https://www.cabforum.org/EV_Certificate_Guidelines.pdf EV Certificate Guidelines].

=== Rule - Do Not Use RFC 1918 Addresses in Certificates ===

Certificates should not use private addresses. RFC 1918 is [https://tools.ietf.org/html/rfc1918 Address Allocation for Private Internets]. Private addresses are Internet Assigned Numbers Authority (IANA) reserved and include 192.168/16, 172.16/12, and 10/8.

Certificates issued with private addresses violate [https://www.cabforum.org/EV_Certificate_Guidelines.pdf EV Certificate Guidelines]. In addition, Peter Gutmann writes in in [http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf Engineering Security]: "This one is particularly troublesome because, in combination with the router-compromise attacks... and ...OSCP-defeating measures, it allows an attacker to spoof any EV-certificate site."

=== Rule - Use an Appropriate Certification Authority for the Application's User Base ===

An application user must never be presented with a warning that the certificate was signed by an unknown or untrusted authority. The application's user population must have access to the public certificate of the certification authority which issued the server's certificate. For Internet accessible websites, the most effective method of achieving this goal is to purchase the TLS certificate from a recognize certification authority. Popular Internet browsers already contain the public certificates of these recognized certification authorities.

Internal applications with a limited user population can use an internal certification authority provided its public certificate is securely distributed to all users. However, remember that all certificates issued by this certification authority will be trusted by the users. Therefore, utilize controls to protect the private key and ensure that only authorized individuals have the ability to sign certificates.

The use of self signed certificates is never acceptable. Self signed certificates negate the benefit of end-point authentication and also significantly decrease the ability for an individual to detect a man-in-the-middle attack.

=== Rule - Always Provide All Needed Certificates ===

Clients attempt to solve the problem of identifying a server or host using PKI and X509 certificate. When a user receives a server or host's certificate, the certificate must be validated back to a trusted root certification authority. This is known as path validation.

There can be one or more intermediate certificates in between the end-entity (server or host) certificate and root certificate. In addition to validating both endpoints, the user will also have to validate all intermediate certificates. Validating all intermediate certificates can be tricky because the user may not have them locally. This is a well-known PKI issue called the “Which Directory?" problem.

To avoid the “Which Directory?" problem, a server should provide the user with all required certificates used in a path validation.

=== Rule - Be aware of and have a plan for the SHA-1 deprecation plan ===

In order to avoid presenting end users with progressive certificate warnings, organizations must proactively address the browser vendor's upcoming SHA-1 deprecation plans. The Google Chrome plan is probably the most specific and aggressive at this point: [http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html Gradually sunsetting SHA-1]

If your organization has no [https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility SHA256 compatibility issues] then it may be appropriate to move your site to a SHA256 signed certificate/chain. If there are, or may be, issues - you should ensure that your SHA-1 certificates expire before 1/1/2017.

== Server Protocol and Cipher Configuration ==
Note: If using a FIPS 140-2 cryptomodule disregard the following rules and defer to the recommended configuration for the particular cryptomodule. Nevertheless we recommend to use this rules to audit your configuration.

=== Rule - Only Support Strong Protocols ===

SSL/TLS is a collection of protocols. Weaknesses have been identified with earlier SSL protocols, including [http://www.schneier.com/paper-ssl-revised.pdf SSLv2] and [http://www.yaksman.org/~lweith/ssl.pdf SSLv3], hence SSL versions 1, 2, and 3 should not longer be used. The best practice for transport layer protection is to only provide support for the TLS protocols - TLS 1.0, TLS 1.1 and TLS 1.2. This configuration will provide maximum protection against skilled and determined attackers and is appropriate for applications handling sensitive data or performing critical operations.

[http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers Nearly all modern browsers support at least TLS 1.0]. As of February 2014, contemporary browsers (Chrome v20+, Firefox v27+, IE v8+, Opera v10+, and Safari v5+) [http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers support TLS 1.1 and TLS 1.2]. You should provide support for TLS 1.1 and TLS 1.2 to accommodate clients that support these protocols. The client and server (usually) negotiate the best protocol that is supported on both sides.

TLS 1.0 is still widely used as the 'best' protocol by a lot of browsers that are not patched to the very latest version. It suffers from [http://www.yassl.com/yaSSL/Blog/Entries/2010/10/7_Differences_between_SSL_and_TLS_Protocol_Versions.html CBC Chaining attacks and Padding Oracle attacks]. TLSv1.0 should only be used after risk analysis and acceptance. PCI DSS 3.1 [https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement_v1.pdf prohibits] use of TLS 1.0 after June 30, 2016.

Under no circumstances either SSLv2 or SSLv3 should be enabled as a protocol selection:
* The [http://www.schneier.com/paper-ssl-revised.pdf SSLv2 protocol is broken] and does not provide adequate transport layer protection.
* [http://www.yaksman.org/~lweith/ssl.pdf SSLv3 had been known for weaknesses] which severely compromise the channel's security long before the [https://www.openssl.org/~bodo/ssl-poodle.pdf 'POODLE'-Bug] finally stopped to tolerate this protocol by October 2014. Switching off SSLv3 terminates the support of legacy browsers like [https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=6&platform=XP IE6/XP] and elder (in their default configuration).

=== Rule - Prefer Ephemeral Key Exchanges ===

Ephemeral key exchanges are based on Diffie-Hellman and use per-session, temporary keys during the initial SSL/TLS handshake. They provide perfect forward secrecy (PFS), which means a compromise of the server's long term signing key does not compromise the confidentiality of past session (see [[#Rule_-_Only_Support_Strong_Cryptographic_Ciphers | following rule]]). When the server uses an ephemeral key, the server will sign the temporary key with its long term key (the long term key is the customary key available in its certificate).

Use cryptographic parameters (like DH-parameter) that use a secure length that match to the supported keylength of your certificate (>=2048 bits or equivalent Elliptic Curves). As some middleware had some issues with this, upgrade to the latest version.
Note: There are some legacy browsers or old Java versions that are not capable to cope with DH-Params >1024 bits, please read the [[#Rule_-_Only_Support_Strong_Cryptographic_Ciphers | following rule]] how this can be solved.

Do *not* use standardized DH-parameters like they are defined by RFCs 2409, 3526, or 5114. Generate your individual DH-parameters to get unique prime numbers (this may take a long time):
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
openssl dhparam 2048 -out dhparam2048.pem
{{Top_10_2010:ExampleEndTemplate}}
Set the path to use this parameter file, e.g. when using Apache:
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
SSLOpenSSLConfCmd DHParameters <path to dhparam2048.pem>
{{Top_10_2010:ExampleEndTemplate}}

If you have a server farm and are providing forward secrecy, then you might have to disable session resumption. For example, Apache writes the session id's and master secrets to disk so all servers in the farm can participate in resuming a session (there is currently no in-memory mechanism to achieve the sharing). Writing the session id and master secret to disk undermines forward secrecy.

=== Rule - Only Support Strong Cryptographic Ciphers ===

Each protocol (TLSv1.0, TLSv1.1, TLSv1.2, etc) provides cipher suites. As of TLS 1.2, [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 there is support for over 300 suites (320+ and counting)], including [http://www.mail-archive.com/cryptography@randombit.net/msg03785.html national vanity cipher suites]. The strength of the encryption used within a TLS session is determined by the encryption cipher negotiated between the server and the browser. In order to ensure that only strong cryptographic ciphers are selected the server must be modified to disable the use of weak ciphers and to configure the ciphers in an adequate order. It is recommended to configure the server to only support strong ciphers and to use sufficiently large key sizes. In general, the following should be observed when selecting CipherSuites:
* Use the very latest recommendations, they may be volantile these days
* Setup your Policy to get a Whitelist for recommended Ciphers, e.g.:
** Activate to set the Cipher Order by the Server
** Highest Priority for Ciphers that support 'Forward Secrecy' (-> Support ephemeral Diffie-Hellman key exchange, see rule above) [http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html]
** Favor DHE over ECDHE (and monitor the CPU usage, see Notes below), ECDHE lacks now of really reliable Elliptic Curves, see discussion about secp{224,256,384,521}r1 and secp256k1, cf. [http://safecurves.cr.yp.to], [https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929]. The solution might be to use [http://www.researchgate.net/profile/Johannes_Merkle/publication/260050106_Standardisierung_der_Brainpool-Kurven_fr_TLS_und_IPSec/file/60b7d52f36a0cc2fdd.pdf Brainpool Curves <nowiki>[German]</nowiki>], defined for TLS in [https://tools.ietf.org/html/rfc7027 RFC 7027], or [http://eprint.iacr.org/2007/286 Edwards Curves]. The most promising candidates for the latter are [https://tools.ietf.org/html/draft-josefsson-tls-curve25519-06 'Curve25519'] and [http://sourceforge.net/p/ed448goldilocks/wiki/Home/ Ed448-Goldilocks] (see [https://tools.ietf.org/html/draft-irtf-cfrg-curves-02 DRAFT-irtf-cfrg-curves]), that is not yet defined for TLS, cf. [http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 IANA] 
** Use RSA-Keys (no DSA/DSS: they get very weak, if a bad entropy source is used during signing, cf. [https://projectbullrun.org/dual-ec/tls.html], [https://factorable.net/weakkeys12.conference.pdf]) 
** Favor GCM over CBC regardless of the cipher size. In other words, use Authenticated Encryption with Associated Data (AEAD), e.g. AES-GCM, AES-CCM.
** Watch also for Stream Ciphers which XOR the key stream with plaintext (such as AES/CTR mode) 
** Priorize the ciphers by the sizes of the Cipher and the MAC
** Use SHA1 or above for digests, prefer SHA2 (or equivalent)
** Disable weak ciphers (which is implicitly done by this whitelist) without disabling legacy browsers and bots that have to be supported (find the best compromise), actually the cipher TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) does this job.
*** Disable cipher suites that do not offer encryption (eNULL, NULL)
*** Disable cipher suites that do not offer authentication (aNULL). aNULL includes anonymous cipher suites ADH (Anonymous Diffie-Hellman) and AECDH (Anonymous Elliptic Curve Diffie Hellman).
*** Disable export level ciphers (EXP, eg. ciphers containing DES)
*** Disable key sizes smaller than 128 bits for encrypting payload traffic (see [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html BSI: TR-02102 Part 2 (German)])
*** Disable the use of MD5 as a hashing mechanism for payload traffic
*** Disable the use of IDEA Cipher Suites (see [https://tools.ietf.org/html/rfc5469])
*** Disable RC4 cipher suites (see [https://tools.ietf.org/html/rfc7465], [http://www.isg.rhul.ac.uk/tls/])
** Ciphers should be usable for DH-Pamameters >= 2048 bits, without blocking legacy browsers (The cipher ‘DHE-RSA-AES128-SHA’ is suppressed as some browsers like to use it but are not capable to cope with DH-Params > 1024 bits.)
* Define a Cipher String that works with different Versions of your encryption tool, like openssl
* Verify your cipher string
** with an audit-tool, like [[O-Saft|OWASP 'O-Saft' (OWASP SSL audit for testers / OWASP SSL advanced forensic tool)]]
** listing it manually with your encryption software, e.g. openssl ciphers -v <cipher-string> (the result may differ by version), e.g.:
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
openssl ciphers -v "EDH+aRSA+AESGCM:EDH+aRSA+AES:DHE-RSA-AES256-SHA:EECDH+aRSA+AESGCM:EECDH+aRSA+AES:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:RSA+AESGCM:RSA+AES+SHA:DES-CBC3-SHA:-DHE-RSA-AES128-SHA" 
<nowiki>#</nowiki>add optionally ':!aNULL:!eNULL:!LOW:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:!ADH:!IDEA' to protect older Versions of OpenSSL 
<nowiki>#</nowiki>you may use openssl ciphers -V "..." for openssl >= 1.0.1:

0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
0x00,0x39 - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1

{{Top_10_2010:ExampleEndTemplate}}

* Inform yourself how to securely configure the settings for your used services or hardware, e.g. [https://bettercrypto.org BetterCrypto.org: Applied Crypto Hardening (DRAFT)]
* Check new software and hardware versions for new security settings.

Notes:
* According to my researches the most common browsers should be supported with this setting, too (see also [https://www.ssllabs.com/ssltest/index.html SSL Labs: SSL Server Test -> SSL Report -> Handshake Simulation]).
* Monitor the performance of your server, e.g. the TLS handshake with DHE hinders the CPU abt 2.4 times more than ECDHE, cf. [http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html#some-benchmarks Vincent Bernat, 2011], [http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html nmav's Blog, 2011].
* Use of Ephemeral Diffie-Hellman key exchange will protect confidentiality of the transmitted plaintext data even if the corresponding RSA or DSS server private key got compromised. An attacker would have to perform active man-in-the-middle attack at the time of the key exchange to be able to extract the transmitted plaintext. All modern browsers support this key exchange with the notable exception of Internet Explorer prior to Windows Vista.

Additional information can be obtained within the [https://tools.ietf.org/html/rfc5246 TLS 1.2 RFC 5246], [https://www.ssllabs.com/projects/best-practices/index.html SSL Labs: 'SSL/TLS Deployment Best Practices'], [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html BSI: 'TR-02102 Part 2 (German)'], [http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report ENISA: 'Algorithms, Key Sizes and Parameters Report'], [https://tools.ietf.org/html/rfc7525 RFC 7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)] and [http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf FIPS 140-2 IG].

=== Rule - Support TLS-PSK and TLS-SRP for Mutual Authentication ===

When using a shared secret or password offer TLS-PSK (Pre-Shared Key) or TLS-SRP (Secure Remote Password), which are known as Password Authenticated Key Exchange (PAKEs). TLS-PSK and TLS-SRP properly bind the channel, which refers to the cryptographic binding between the outer tunnel and the inner authentication protocol. IANA currently reserves [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 79 PSK cipehr suites] and [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 9 SRP cipher suites].

Basic authentication places the user's password on the wire in the plain text after a server authenticates itself. Basic authentication only provides unilateral authentication. In contrast, both TLS-PSK and TLS-SRP provide mutual authentication, meaning each party proves it knows the password without placing the password on the wire in the plain text.

Finally, using a PAKE removes the need to trust an outside party, such as a Certification Authority (CA).

=== Rule - Only Support Secure Renegotiations ===

A design weakness in TLS, identified as [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3555 CVE-2009-3555], allows an attacker to inject a plaintext of his choice into a TLS session of a victim. In the HTTPS context the attacker might be able to inject his own HTTP requests on behalf of the victim. The issue can be mitigated either by disabling support for TLS renegotiations or by supporting only renegotiations compliant with [https://tools.ietf.org/html/rfc5746 RFC 5746]. All modern browsers have been updated to comply with this RFC.

=== Rule - Disable Compression ===

Compression Ratio Info-leak Made Easy (CRIME) is an exploit against the data compression scheme used by the TLS and SPDY protocols. The exploit allows an adversary to recover user authentication cookies from HTTPS. The recovered cookie can be subsequently used for session hijacking attacks.

== Test your overall TLS/SSL setup and your Certificate ==
This section shows the most common references only. For more tools and such, please refer to [[#Tools|Tools]].

* [[Testing_for_SSL-TLS_%28OWASP-CM-001%29 | OWASP Testing Guide: Chapter on SSL/TLS Testing]]
* [[O-Saft|OWASP 'O-Saft' (OWASP SSL audit for testers / OWASP SSL advanced forensic tool)]]
* [https://www.ssllabs.com/ssltest SSL LABS Server Test]
* other Tools: [[Testing_for_Weak_SSL/TSL_Ciphers,_Insufficient_Transport_Layer_Protection_%28OWASP-EN-002%29#References| Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002) (DRAFT)]] - References - Tools

== Client (Browser) Configuration ==

The validation procedures to ensure that a certificate is valid are complex and difficult to correctly perform. In a typical web application model, these checks will be performed by the client's web browser in accordance with local browser settings and are out of the control of the application. However, these items do need to be addressed in the following scenarios:

* The application server establishes connections to other applications over TLS for purposes such as web services or any exchange of data
* A thick client application is connecting to a server via TLS

In these situations extensive certificate validation checks must occur in order to establish the validity of the certificate. Consult the following resources to assist in the design and testing of this functionality. The NIST PKI testing site includes a full test suite of certificates and expected outcomes of the test cases.
* [http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html NIST PKI Testing]
* [https://tools.ietf.org/html/rfc5280 IETF RFC 5280]

As specified in the above guidance, if the certificate can not be validated for any reason then the connection between the client and server must be dropped. Any data exchanged over a connection where the certificate has not properly been validated could be exposed to unauthorized access or modification.

== Additional Controls ==

=== Extended Validation Certificates ===

Extended validation certificates (EV Certificates) proffer an enhanced investigation by the issuer into the requesting party due to the industry's race to the bottom. The purpose of EV certificates is to provide the user with greater assurance that the owner of the certificate is a verified legal entity for the site. Browsers with support for EV certificates distinguish an EV certificate in a variety of ways. Internet Explorer will color a portion of the URL in green, while Mozilla will add a green portion to the left of the URL indicating the company name.

High value websites should consider the use of EV certificates to enhance customer confidence in the certificate. It should also be noted that EV certificates do not provide any greater technical security for the TLS. The purpose of the EV certificate is to increase user confidence that the target site is indeed who it claims to be.

=== Client-Side Certificates ===

Client side certificates can be used with TLS to prove the identity of the client to the server. Referred to as "two-way TLS", this configuration requires the client to provide their certificate to the server, in addition to the server providing their's to the client. If client certificates are used, ensure that the same validation of the client certificate is performed by the server, as indicated for the validation of server certificates above. In addition, the server should be configured to drop the TLS connection if the client certificate cannot be verified or is not provided.

The use of client side certificates is relatively rare currently due to the complexities of certificate generation, safe distribution, client side configuration, certificate revocation and reissuance, and the fact that clients can only authenticate on machines where their client side certificate is installed. Such certificates are typically used for very high value connections that have small user populations.

=== Certificate and Public Key Pinning ===

Hybrid and native applications can take advantage of [[Certificate_and_Public_Key_Pinning|certificate and public key pinning]]. Pinning associates a host (for example, server) with an identity (for example, certificate or public key), and allows an application to leverage knowledge of the pre-existing relationship. At runtime, the application would inspect the certificate or public key received after connecting to the server. If the certificate or public key is expected, then the application would proceed as normal. If unexpected, the application would stop using the channel and close the connection since an adversary could control the channel or server.

Pinning still requires customary X509 checks, such as revocation, since CRLs and OCSP provides real time status information. Otherwise, an application could possibly (1) accept a known bad certificate; or (2) require an out-of-band update, which could result in a lengthy App Store approval.

Browser based applications are at a disadvantage since most browsers do not allow the user to leverage pre-existing relationships and ''a priori'' knowledge. In addition, Javascript and Websockets do not expose methods to for a web app to query the underlying secure connection information (such as the certificate or public key). It is noteworthy that Chromium based browsers perform pinning on selected sites, but the list is currently maintained by the vendor.

For more information, please see the [[Pinning Cheat Sheet]].

= Providing Transport Layer Protection for Back End and Other Connections =

Although not the focus of this cheat sheet, it should be stressed that transport layer protection is necessary for back-end connections and any other connection where sensitive data is exchanged or where user identity is established. Failure to implement an effective and robust transport layer security will expose sensitive data and undermine the effectiveness of any authentication or access control mechanism.

== Secure Internal Network Fallacy ==

The internal network of a corporation is not immune to attacks. Many recent high profile intrusions, where thousands of sensitive customer records were compromised, have been perpetrated by attackers that have gained internal network access and then used sniffers to capture unencrypted data as it traversed the internal network.

== Protocol and Cipher Configuration for Back End and Other Connections ==
It is important to provide TLS for server-to-server communication in addition to client-to-server communication. Secure the 'client side' configuration of your server that is used for backend and other connections according to [[#Server_Protocol_and_Cipher_Configuration | Server Protocol and Cipher Configuration]]. Be sure to deactivate insecure protocols and ciphers. (e.g. Only support a minimum strong configuration when your server acts as 'client').

= Tools =
=== local/offline ===
* [[O-Saft|O-Saft - OWASP SSL advanced forensic tool]]
* [http://sourceforge.net/projects/sslscan/ SSLScan - Fast SSL Scanner]
* [https://github.com/iSECPartners/sslyze SSLyze]
* [http://www.g-sec.lu/sslaudit/sslaudit.zip SSL Audit]

=== Online ===
* [https://www.ssllabs.com/ssltest SSL LABS Server Test]

* [https://www.htbridge.com/ssl/ High-Tech Bridge online tool to verify SSL/TLS compliance with NIST SP 800-52 guidelines and PCI DSS requirements on any TCP port]

= Related Articles =

* Mozilla – [https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations Mozilla Recommended Configurations]
* OWASP – [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]]
* OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]
* OWASP – ASVS Article on [[Why you need to use a FIPS 140-2 validated cryptomodule]]
* SSL Labs – [https://www.ssllabs.com/projects/best-practices/index.html SSL/TLS Deployment Best Practices]
* SSL Labs – [http://www.ssllabs.com/projects/rating-guide/index.html SSL Server Rating Guide]
* ENISA – [http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report Algorithms, Key Sizes and Parameters Report]
* BSI – [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html BSI TR-02102 Part 2 (German)]
* yaSSL – [http://www.yassl.com/yaSSL/Blog/Entries/2010/10/7_Differences_between_SSL_and_TLS_Protocol_Versions.html Differences between SSL and TLS Protocol Versions]
* NIST – [http://csrc.nist.gov/publications/PubsSPs.html#800-52 SP 800-52 Rev. 1 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations]
* NIST – [http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf FIPS 140-2 Security Requirements for Cryptographic Modules]
* NIST – [http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program]
* NIST – [http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf NIST SP 800-57 Recommendation for Key Management, Revision 3], [http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-57-Part%203-Rev.1 Public DRAFT]
* NIST – [http://csrc.nist.gov/publications/drafts.html#sp800-95 SP 800-95 Guide to Secure Web Services]
* IETF – [https://tools.ietf.org/html/rfc5280 RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile]
* IETF – [https://tools.ietf.org/html/rfc2246 RFC 2246 The Transport Layer Security (TLS) Protocol Version 1.0 (JAN 1999)]
* IETF – [https://tools.ietf.org/html/rfc4346 RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 (APR 2006)]
* IETF – [https://tools.ietf.org/html/rfc5246 RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 (AUG 2008)]
* IETF – [https://tools.ietf.org/html/rfc7525 RFC 7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)]
* bettercrypto - [https://bettercrypto.org Applied Crypto Hardening: HOWTO for secure crypto settings of the most common services (DRAFT)]

= Authors and Primary Editors =

Torsten Gigler - torsten.gigler[at]owasp.org 
Michael Coates - michael.coates[at]owasp.org 
Dave Wichers - dave.wichers[at]owasp.org 
Tyler Reguly -treguly[at]sslfail.com

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]
[[Category:OWASP Best Practices]]

Testing for SSL-TLS (OWASP-CM-001)

2015-11-19T10:55:22Z

ADHTB: /* References */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==

Due to historic export restrictions of high grade cryptography, legacy and new web servers are often able and configured to handle weak cryptographic options.

Even if high grade ciphers are normally used and installed, some server misconfiguration could be used to force the use of a weaker cipher to gain access to the supposed secure communication channel.

==Testing SSL / TLS Cipher Specifications and Requirements ==

The http clear-text protocol is normally secured via an SSL or TLS tunnel, resulting in https traffic. In addition to providing encryption of data in transit, https allows the identification of servers (and, optionally, of clients) by means of digital certificates.

Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of, at most, 40 bits, a key length which could be broken and would allow the decryption of communications. Since then, cryptographic export regulations have been relaxed (though some constraints still hold); however, it is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. SSL-based services should not offer the possibility to choose weak ciphers.

Cipher determination is performed as follows: in the initial phase of a SSL connection setup, the client sends the server a Client Hello message specifying, among other information, the cipher suites that it is able to handle. A client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not be a web server, though this is the most common case. (For example, a noteworthy class of SSL clients is that of SSL proxies such as stunnel (www.stunnel.org) which can be used to allow non-SSL enabled tools to talk to SSL services.) A cipher suite is specified by an encryption protocol (DES, RC4, AES), the encryption key length (such as 40, 56, or 128 bits), and a hash algorithm (SHA, MD5) used for integrity checking. Upon receiving a Client Hello message, the server decides which cipher suite it will use for that session. It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control, for example, whether or not conversations with clients will support 40-bit encryption only.

==SSL Testing Criteria==
Large number of available cipher suites and quick progress in cryptoanalysis makes judging a SSL server a non-trivial task. These criteria are widely recognised as minimum checklist:

* SSLv2, due to known weaknesses in protocol design [http://www.schneier.com/paper-ssl.html]
* SSLv3, due to known weaknesses in protocol design [http://www.yaksman.org/~lweith/ssl.pdf]
* Compression, due to known weaknesses in protocol design [http://www.ekoparty.org/2012/juliano-rizzo.php]
* Cipher suites with symmetric encryption algorithm smaller than 112 bits
* X.509 certificates with RSA key smaller than 2048 bits
* X.509 certificates with DSA key smaller than 2048 bits
* X.509 certificates signed using MD5 hash, due to known collision attacks on this hash
* TLS Renegotiation vulnerability [http://www.phonefactor.com/sslgap/ssl-tls-authentication-patches]

The following standards can be used as reference while assessing SSL servers:

* [http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf NIST SP 800-52] recommends U.S. federal systems to use at least TLS 1.0 with ciphersuites based on RSA or DSA key agreement with ephemeral Diffie-Hellman, 3DES or AES for confidentality and SHA1 for integrity protection. NIST SP 800-52 specifically disallows non-FIPS compliant algorithms like RC4 and MD5. An exception is U.S. federal systems making connections to outside servers, where these algorithms can be used in SSL client mode.
* [https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml PCI-DSS v1.2] in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used[http://www.digicert.com/news/DigiCert_PCI_White_Paper.pdf].
* [https://www.ssllabs.com/projects/rating-guide/index.html SSL Server Rating Guide] has been proposed to standardize SSL server assessment and currently is in draft version.

SSL Server Database can be used to assess configuration of publicly available SSL servers[https://www.ssllabs.com/ssldb/analyze.html] based on SSL Rating Guide[https://www.ssllabs.com/projects/rating-guide/index.html]

==Black Box Test and example==

In order to detect possible support of weak ciphers, the ports associated to SSL/TLS wrapped services must be identified. These typically include port 443, which is the standard https port; however, this may change because a) https services may be configured to run on non-standard ports, and b) there may be additional SSL/TLS wrapped services related to the web application. In general, a service discovery is required to identify such ports.

The nmap scanner, via the “–sV” scan option, is able to identify SSL services. Vulnerability Scanners, in addition to performing service discovery, may include checks against weak ciphers (for example, the Nessus scanner has the capability of checking SSL services on arbitrary ports, and will report weak ciphers).

'''Example 1'''. SSL service recognition via nmap.

<pre>
[root@test]# nmap -F -sV localhost

Starting nmap 3.75 ( http://www.insecure.org/nmap/ ) at 2005-07-27 14:41 CEST
Interesting ports on localhost.localdomain (127.0.0.1):
(The 1205 ports scanned but not shown below are in state: closed)

PORT STATE SERVICE VERSION
443/tcp open ssl OpenSSL
901/tcp open http Samba SWAT administration server
8080/tcp open http Apache httpd 2.0.54 ((Unix) mod_ssl/2.0.54 OpenSSL/0.9.7g PHP/4.3.11)
8081/tcp open http Apache Tomcat/Coyote JSP engine 1.0

Nmap run completed -- 1 IP address (1 host up) scanned in 27.881 seconds
[root@test]#
</pre>

'''Example 2'''. Identifying weak ciphers with Nessus.
The following is an anonymized excerpt of a report generated by the Nessus scanner, corresponding to the identification of a server certificate allowing weak ciphers (see underlined text).

'''https (443/tcp)'''
'''Description'''
Here is the SSLv2 server certificate:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=**, ST=******, L=******, O=******, OU=******, CN=******
Validity
Not Before: Oct 17 07:12:16 2002 GMT
Not After : Oct 16 07:12:16 2004 GMT
Subject: C=**, ST=******, L=******, O=******, CN=******
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:98:4f:24:16:cb:0f:74:e8:9c:55:ce:62:14:4e:
6b:84:c5:81:43:59:c1:2e:ac:ba:af:92:51:f3:0b:
ad:e1:4b:22:ba:5a:9a:1e:0f:0b:fb:3d:5d:e6:fc:
ef:b8:8c:dc:78:28:97:8b:f0:1f:17:9f:69:3f:0e:
72:51:24:1b:9c:3d:85:52:1d:df:da:5a:b8:2e:d2:
09:00:76:24:43:bc:08:67:6b:dd:6b:e9:d2:f5:67:
e1:90:2a:b4:3b:b4:3c:b3:71:4e:88:08:74:b9:a8:
2d:c4:8c:65:93:08:e6:2f:fd:e0:fa:dc:6d:d7:a2:
3d:0a:75:26:cf:dc:47:74:29
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
Page 10
Network Vulnerability Assessment Report 25.05.2005
X509v3 Subject Key Identifier:
10:00:38:4C:45:F0:7C:E4:C6:A7:A4:E2:C9:F0:E4:2B:A8:F9:63:A8
X509v3 Authority Key Identifier:
keyid:CE:E5:F9:41:7B:D9:0E:5E:5D:DF:5E:B9:F3:E6:4A:12:19:02:76:CE
DirName:/C=**/ST=******/L=******/O=******/OU=******/CN=******
serial:00
Signature Algorithm: md5WithRSAEncryption
7b:14:bd:c7:3c:0c:01:8d:69:91:95:46:5c:e6:1e:25:9b:aa:
8b:f5:0d:de:e3:2e:82:1e:68:be:97:3b:39:4a:83:ae:fd:15:
2e:50:c8:a7:16:6e:c9:4e:76:cc:fd:69:ae:4f:12:b8:e7:01:
b6:58:7e:39:d1:fa:8d:49:bd:ff:6b:a8:dd:ae:83:ed:bc:b2:
40:e3:a5:e0:fd:ae:3f:57:4d:ec:f3:21:34:b1:84:97:06:6f:
f4:7d:f4:1c:84:cc:bb:1c:1c:e7:7a:7d:2d:e9:49:60:93:12:
0d:9f:05:8c:8e:f9:cf:e8:9f:fc:15:c0:6e:e2:fe:e5:07:81:
82:fc
Here is the list of available SSLv2 ciphers:
RC4-MD5
EXP-RC4-MD5
RC2-CBC-MD5
EXP-RC2-CBC-MD5
DES-CBC-MD5
DES-CBC3-MD5
RC4-64-MD5
The SSLv2 server offers 5 strong ciphers, but also 0 medium strength and '''2 weak "export class" ciphers'''.
The weak/medium ciphers may be chosen by an export-grade or badly configured client software. They only offer a limited protection against a brute force attack
Solution: disable those ciphers and upgrade your client software if necessary.
See http://support.microsoft.com/default.aspx?scid=kben-us216482
or http://httpd.apache.org/docs-2.0/mod/mod_ssl.html#sslciphersuite
This SSLv2 server also accepts SSLv3 connections.
This SSLv2 server also accepts TLSv1 connections.

Vulnerable hosts
''(list of vulnerable hosts follows)''

'''Example 3'''. Manually audit weak SSL cipher levels with OpenSSL. The following will attempt to connect to Google.com with SSLv2.
<pre>
[root@test]# openssl s_client -no_tls1 -no_ssl3 -connect www.google.com:443
CONNECTED(00000003)
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDYzCCAsygAwIBAgIQYFbAC3yUC8RFj9MS7lfBkzANBgkqhkiG9w0BAQQFADCB
zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh
d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl
cnZlckB0aGF3dGUuY29tMB4XDTA2MDQyMTAxMDc0NVoXDTA3MDQyMTAxMDc0NVow
aDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDU1v
dW50YWluIFZpZXcxEzARBgNVBAoTCkdvb2dsZSBJbmMxFzAVBgNVBAMTDnd3dy5n
b29nbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/e2Vs8U33fRDk
5NNpNgkB1zKw4rqTozmfwty7eTEI8PVH1Bf6nthocQ9d9SgJAI2WOBP4grPj7MqO
dXMTFWGDfiTnwes16G7NZlyh6peT68r7ifrwSsVLisJp6pUf31M5Z3D88b+Yy4PE
D7BJaTxq6NNmP1vYUJeXsGSGrV6FUQIDAQABo4GmMIGjMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjBABgNVHR8EOTA3MDWgM6Axhi9odHRwOi8vY3JsLnRo
YXd0ZS5jb20vVGhhd3RlUHJlbWl1bVNlcnZlckNBLmNybDAyBggrBgEFBQcBAQQm
MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLnRoYXd0ZS5jb20wDAYDVR0TAQH/
BAIwADANBgkqhkiG9w0BAQQFAAOBgQADlTbBdVY6LD1nHWkhTadmzuWq2rWE0KO3
Ay+7EleYWPOo+EST315QLpU6pQgblgobGoI5x/fUg2U8WiYj1I1cbavhX2h1hda3
FJWnB3SiXaiuDTsGxQ267EwCVWD5bCrSWa64ilSJTgiUmzAv0a2W8YHXdG08+nYc
X/dVk5WRTw==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
---
No client certificate CA names sent
---
Ciphers common between both SSL endpoints:
RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5
EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5
RC4-64-MD5
---
SSL handshake has read 1023 bytes and written 333 bytes
---
New, SSLv2, Cipher is DES-CBC3-MD5
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv2
Cipher : DES-CBC3-MD5
Session-ID: 709F48E4D567C70A2E49886E4C697CDE
Session-ID-ctx:
Master-Key: 649E68F8CF936E69642286AC40A80F433602E3C36FD288C3
Key-Arg : E8CB6FEB9ECF3033
Start Time: 1156977226
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
closed
</pre>

'''Example 4'''. Testing supported protocols and ciphers using SSLScan.

SSLScan is a free command line tool that scans a HTTPS service to enumerate what protocols (supports SSLv2, SSLv3 and TLS1) and what ciphers the HTTPS service supports. It runs both on Linux and Windows OS (OSX not tested) and is released under a open source license.

<pre>
[user@test]$ ./SSLScan --no-failed mail.google.com
_
___ ___| |___ ___ __ _ _ __
/ __/ __| / __|/ __/ _` | '_ \
\__ \__ \ \__ \ (_| (_| | | | |
|___/___/_|___/\___\__,_|_| |_|

Version 1.9.0-win
http://www.titania.co.uk
Copyright 2010 Ian Ventura-Whiting / Michael Boman
Compiled against OpenSSL 0.9.8n 24 Mar 2010

Testing SSL server mail.google.com on port 443

Supported Server Cipher(s):
accepted SSLv3 256 bits AES256-SHA
accepted SSLv3 128 bits AES128-SHA
accepted SSLv3 168 bits DES-CBC3-SHA
accepted SSLv3 128 bits RC4-SHA
accepted SSLv3 128 bits RC4-MD5
accepted TLSv1 256 bits AES256-SHA
accepted TLSv1 128 bits AES128-SHA
accepted TLSv1 168 bits DES-CBC3-SHA
accepted TLSv1 128 bits RC4-SHA
accepted TLSv1 128 bits RC4-MD5

Prefered Server Cipher(s):
SSLv3 128 bits RC4-SHA
TLSv1 128 bits RC4-SHA

SSL Certificate:
Version: 2
Serial Number: -4294967295
Signature Algorithm: sha1WithRSAEncryption
Issuer: /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
Not valid before: Dec 18 00:00:00 2009 GMT
Not valid after: Dec 18 23:59:59 2011 GMT
Subject: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:d9:27:c8:11:f2:7b:e4:45:c9:46:b6:63:75:83:
b1:77:7e:17:41:89:80:38:f1:45:27:a0:3c:d9:e8:
a8:00:4b:d9:07:d0:ba:de:ed:f4:2c:a6:ac:dc:27:
13:ec:0c:c1:a6:99:17:42:e6:8d:27:d2:81:14:b0:
4b:82:fa:b2:c5:d0:bb:20:59:62:28:a3:96:b5:61:
f6:76:c1:6d:46:d2:fd:ba:c6:0f:3d:d1:c9:77:9a:
58:33:f6:06:76:32:ad:51:5f:29:5f:6e:f8:12:8b:
ad:e6:c5:08:39:b3:43:43:a9:5b:91:1d:d7:e3:cf:
51:df:75:59:8e:8d:80:ab:53
Exponent: 65537 (0x10001)
X509v3 Extensions:
X509v3 Basic Constraints: critical
CA:FALSE X509v3 CRL Distribution Points:
URI:http://crl.thawte.com/ThawteSGCCA.crl
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication, Netscape Server Gated Crypto Authority Information Access:
OCSP - URI:http://ocsp.thawte.com
CA Issuers - URI:http://www.thawte.com/repository/Thawte_SGC_CA.crt
Verify Certificate:
unable to get local issuer certificate

Renegotiation requests supported
</pre>

'''Example 5'''. Testing common SSL flaws with ssl_tests

ssl_tests (http://www.pentesterscripting.com/discovery/ssl_tests) is a bash script that uses sslscan and openssl to check for various flaws - ssl version 2, weak ciphers, md5withRSAEncryption,SSLv3 Force Ciphering Bug/Renegotiation.

<pre>

[user@test]$ ./ssl_test.sh 192.168.1.3 443
+++++++++++++++++++++++++++++++++++++++++++++++++
SSL Tests - v2, weak ciphers, MD5, Renegotiation
by Aung Khant, http://yehg.net
+++++++++++++++++++++++++++++++++++++++++++++++++

[*] testing on 192.168.1.3:443 ..

[*] tesing for sslv2 ..
[*] sslscan 192.168.1.3:443 | grep Accepted SSLv2
Accepted SSLv2 168 bits DES-CBC3-MD5
Accepted SSLv2 56 bits DES-CBC-MD5
Accepted SSLv2 40 bits EXP-RC2-CBC-MD5
Accepted SSLv2 128 bits RC2-CBC-MD5
Accepted SSLv2 40 bits EXP-RC4-MD5
Accepted SSLv2 128 bits RC4-MD5

[*] testing for weak ciphers ...
[*] sslscan 192.168.1.3:443 | grep 40 bits | grep Accepted
Accepted SSLv2 40 bits EXP-RC2-CBC-MD5
Accepted SSLv2 40 bits EXP-RC4-MD5
Accepted SSLv3 40 bits EXP-EDH-RSA-DES-CBC-SHA
Accepted SSLv3 40 bits EXP-DES-CBC-SHA
Accepted SSLv3 40 bits EXP-RC2-CBC-MD5
Accepted SSLv3 40 bits EXP-RC4-MD5
Accepted TLSv1 40 bits EXP-EDH-RSA-DES-CBC-SHA
Accepted TLSv1 40 bits EXP-DES-CBC-SHA
Accepted TLSv1 40 bits EXP-RC2-CBC-MD5
Accepted TLSv1 40 bits EXP-RC4-MD5

[*] sslscan 192.168.1.3:443 | grep 56 bits | grep Accepted
Accepted SSLv2 56 bits DES-CBC-MD5
Accepted SSLv3 56 bits EDH-RSA-DES-CBC-SHA
Accepted SSLv3 56 bits DES-CBC-SHA
Accepted TLSv1 56 bits EDH-RSA-DES-CBC-SHA
Accepted TLSv1 56 bits DES-CBC-SHA

[*] testing for MD5 certificate ..
[*] sslscan 192.168.1.3:443 | grep MD5WithRSAEncryption

[*] testing for SSLv3 Force Ciphering Bug/Renegotiation ..
[*] echo R | openssl s_client -connect 192.168.1.3:443 | grep DONE
depth=0 /C=DE/ST=Berlin/L=Berlin/O=XAMPP/OU=XAMPP/CN=localhost/emailAddress=admin@localhost
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=DE/ST=Berlin/L=Berlin/O=XAMPP/OU=XAMPP/CN=localhost/emailAddress=admin@localhost
verify return:1
RENEGOTIATING
depth=0 /C=DE/ST=Berlin/L=Berlin/O=XAMPP/OU=XAMPP/CN=localhost/emailAddress=admin@localhost
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=DE/ST=Berlin/L=Berlin/O=XAMPP/OU=XAMPP/CN=localhost/emailAddress=admin@localhost
verify return:1
DONE

[*] done

</pre>

==White Box Test and example==

Check the configuration of the web servers which provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well.

'''Example:''' The following registry path in Microsoft Windows 2003 defines the ciphers available to the server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\

==Testing SSL certificate validity – client and server==

When accessing a web application via the https protocol, a secure channel is established between the client (usually the browser) and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this Guide, we will focus on the main criteria involved in ascertaining certificate validity: a) checking if the Certificate Authority (CA) is a known one (meaning one considered trusted), b) checking that the certificate is currently valid, and c) checking that the name of the site and the name reported in the certificate match.
Remember to upgrade your browser because CA certs expired too, in every release of the browser, CA Certs has been renewed. Moreover it's important to update the browser because more web sites require strong cipher more of 40 or 56 bit.

Let’s examine each check more in detail.

a) Each browser comes with a preloaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an https server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via https; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates).

b) Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed.

c) What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signalled by the browser. To avoid this, one of two techniques should be used. First is Server Name Indication (SNI), which is a TLS extension from [http://www.ietf.org/rfc/rfc3546.txt RFC 3546]; and second is IP-based virtual servers must be used. [2] and [3] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced.

===Black Box Testing and examples===

Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match namewise with the site to which they should refer. By clicking on the padlock which appears in the browser window when visiting an https site, you can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc.

If the application requires a client certificate, you probably have installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates.

These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an https administrative port left open, https services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services.

'''Examples'''

Rather than providing a fictitious example, we have inserted an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming.

The following screenshots refer to a regional site of a high-profile IT company.

Warning issued by Microsoft Internet Explorer. We are visiting an ''.it'' site and the certificate was issued to a ''.com ''site! Internet Explorer warns that the name on the certificate does not match the name of the site.

[[Image:SSL Certificate Validity Testing IE Warning.gif]]

Warning issued by Mozilla Firefox. The message issued by Firefox is different – Firefox complains because it cannot ascertain the identity of the ''.com'' site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come preloaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.

[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]

===White Box Testing and examples===

Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level; however, there may be additional communication paths protected by SSL (for example, towards the DBMS). You should check the application architecture to identify all SSL protected channels.

==References==
'''Whitepapers''' 
* [1] RFC2246. The TLS Protocol Version 1.0 (updated by RFC3546) - http://www.ietf.org/rfc/rfc2246.txt
* [2] RFC2817. Upgrading to TLS Within HTTP/1.1 - http://www.ietf.org/rfc/rfc2817.txt
* [3] RFC3546. Transport Layer Security (TLS) Extensions - http://www.ietf.org/rfc/rfc3546.txt
* [4] www.verisign.net features various material on the topic

'''Tools'''

* https://www.ssllabs.com/ssldb/

* Vulnerability scanners may include checks regarding certificate validity, including name mismatch and time expiration. They usually report other information as well, such as the CA which issued the certificate. Remember that there is no unified notion of a “trusted CA”; what is trusted depends on the configuration of the software and on the human assumptions made beforehand. Browsers come with a preloaded list of trusted CAs. If your web application relies on a CA which is not in this list (for example, because you rely on a self-made CA), you should take into account the process of configuring user browsers to recognize the CA.

* The Nessus scanner includes a plugin to check for expired certificates or certificates which are going to expire within 60 days (plugin “SSL certificate expiry”, plugin id 15901). This plugin will check certificates ''installed on the server.

* Vulnerability scanners may include checks against weak ciphers. For example, the Nessus scanner (http://www.nessus.org) has this capability and flags the presence of SSL weak ciphers (see example provided above).

* You may also rely on specialized tools such as SSL Digger (http://www.mcafee.com/us/downloads/free-tools/ssldigger.aspx), or – for the command line oriented – experiment with the openssl tool, which provides access to OpenSSL cryptographic functions directly from a Unix shell (may be already available on *nix boxes, otherwise see www.openssl.org).

* To identify SSL-based services, use a vulnerability scanner or a port scanner with service recognition capabilities. The nmap scanner features a “-sV” scanning option which tries to identify services, while the nessus vulnerability scanner has the capability of identifying SSL-based services on arbitrary ports and to run vulnerability checks on them regardless of whether they are configured on standard or non-standard ports.

* In case you need to talk to a SSL service but your favourite tool doesn’t support SSL, you may benefit from a SSL proxy such as stunnel; stunnel will take care of tunneling the underlying protocol (usually http, but not necessarily so) and communicate with the SSL service you need to reach.

* ssl_tests, http://www.pentesterscripting.com/discovery/ssl_tests

* testssl.sh http://drwetter.eu/software/ssl/

* Finally, a word of advice. Though it may be tempting to use a regular browser to check certificates, there are various reasons for not doing so. Browsers have been plagued by various bugs in this area, and the way the browser will perform the check might be influenced by configuration settings that may not be evident. Instead, rely on vulnerability scanners or on specialized tools to do the job.

* [http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet OWASP Transport Layer Protection Cheat Sheet]

* [https://www.htbridge.com/ssl/ High-Tech Bridge] - Online tool to verify SSL/TLS compliance with NIST SP 800-52 guidelines and PCI DSS requirements on any TCP port.

[[Category:Cryptographic Vulnerability]]
[[Category:SSL]]

SSL TLS Knowledge Center

2015-11-19T10:52:08Z

ADHTB: /* Online Tools */

=Purpose=
The SSL/TLS Knowledge Center serves as a central point to provide references to SSL/TLS. This is a community driven page. Please contribute by adding links or requests for links.

=Resources=

== OWASP Resources ==

[[Transport_Layer_Protection_Cheat_Sheet]] - OWASP SSL/TLS Cheat Sheet

[[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]]

[[Guide to Cryptography]]

== Articles & Blogs ==

[http://hackademix.net/2009/09/23/strict-transport-security-in-noscript/ STS in No Script] - How to enable STS support within No Script plugin

[http://michael-coates.blogspot.com/2009/11/https-data-exposure-get-vs-post.html HTTPS Data Exposure] - HTTPS data exposure comparison for GET and POST

[https://www.ssllabs.com/projects/rating-guide/index.html SSL Server Rating Guide] - SSL Labs guide providing information on correct configuration of SSL. Focuses mainly at the network layer

== Online Tools ==

[https://www.ssllabs.com/ SSL Labs] - Online tool to verify SSL/TLS certificate and configuration.

[https://www.htbridge.com/ssl/ High-Tech Bridge] - Online tool to verify SSL/TLS compliance with NIST SP 800-52 guidelines and PCI DSS requirements.

== NIST Guides ==

[http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf SP 800-52 Guidelines for the selection and use of transport layer security (TLS) Implementations]

[http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf FIPS 140-2 Security Requirements for Cryptographic Modules]

[http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program]

[http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf SP 800-57 Recommendation for Key Management, Revision 2]

[http://csrc.nist.gov/publications/drafts.html#sp800-95 SP 800-95 Guide to Secure Web Services]

== Specs ==
[http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html Strict Transport Security Spec] - Specification for STS which allows a website to instruct the browser to not send requests to the web server over non-TLS channels.

[http://www.ietf.org/rfc/rfc3280.txt RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile]

[http://www.ietf.org/rfc/rfc4346.txt RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1]

= Needed =
Guides for configuring SSL/TLS cipher support in common web servers

References to current SSL/TLS RFC specs

More entries to this "Needed" list

Anything else that would be helpful related to SSL/TLS