MozillaWiki

Security/Guidelines/Web Security: Difference between revisions

Page Discussion

Security/Guidelines/Web Security (view source)

Revision as of 22:38, 19 October 2017

582 bytes added ,  19 October 2017
Automated sync from https://github.com/mozilla/wikimo_content
(Automated sync from https://github.com/mozilla/wikimo_opsec)
(Automated sync from https://github.com/mozilla/wikimo_content)
 
(4 intermediate revisions by 3 users not shown)
Line 235: Line 235:
* <tt>max-age:</tt> how long user agents will redirect to HTTPS, in seconds
* <tt>max-age:</tt> how long user agents will redirect to HTTPS, in seconds
* <tt>includeSubDomains:</tt> whether user agents should upgrade requests on subdomains
* <tt>includeSubDomains:</tt> whether user agents should upgrade requests on subdomains
* <tt>preload:</tt> whether the site should be included in the [https://hstspreload.appspot.com/ HSTS preload list]
* <tt>preload:</tt> whether the site should be included in the [https://hstspreload.org/ HSTS preload list]


<tt>max-age</tt> must be set to a minimum of six months (15768000), but longer periods such as one year (31536000) are recommended.  Note that once this value is set, the site must continue to support HTTPS until the expiry time has been reached.
<tt>max-age</tt> must be set to a minimum of six months (15768000), but longer periods such as two years (63072000) are recommended.  Note that once this value is set, the site must continue to support HTTPS until the expiry time has been reached.


<tt>includeSubDomains</tt> notifies the browser that all subdomains of the current origin should also be upgraded via HSTS.  For example, setting <tt>includeSubDomains</tt> on <tt>domain.mozilla.com</tt> will also set it on <tt>host1.domain.mozilla.com</tt> and <tt>host2.domain.mozilla.com</tt>. Extreme care is needed when setting the <tt>includeSubDomains</tt> flag, as it could disable sites on subdomains that don't yet have HTTPS enabled.
<tt>includeSubDomains</tt> notifies the browser that all subdomains of the current origin should also be upgraded via HSTS.  For example, setting <tt>includeSubDomains</tt> on <tt>domain.mozilla.com</tt> will also set it on <tt>host1.domain.mozilla.com</tt> and <tt>host2.domain.mozilla.com</tt>. Extreme care is needed when setting the <tt>includeSubDomains</tt> flag, as it could disable sites on subdomains that don't yet have HTTPS enabled.


<tt>preload</tt> allows the website to be included in the [https://hstspreload.appspot.com/ HSTS preload list], upon submission. As a result, web browsers will do HTTPS upgrades to the site without ever having to receive the initial HSTS header.  This prevents downgrade attacks upon first use and is recommended for all high risk websites.  Note that being included in the HSTS preload list requires that <tt>includeSubDomains</tt> also be set.
<tt>preload</tt> allows the website to be included in the [https://hstspreload.org/ HSTS preload list], upon submission. As a result, web browsers will do HTTPS upgrades to the site without ever having to receive the initial HSTS header.  This prevents downgrade attacks upon first use and is recommended for all high risk websites.  Note that being included in the HSTS preload list requires that <tt>includeSubDomains</tt> also be set.


=== Examples ===
=== Examples ===


<pre># Only connect to this site via HTTPS for the next year (recommended)
<pre># Only connect to this site via HTTPS for the two years (recommended)
Strict-Transport-Security: max-age=31536000</pre>
Strict-Transport-Security: max-age=63072000</pre>


<pre># Only connect to this site and subdomains via HTTPS for the next year and also include in the preload list
<pre># Only connect to this site and subdomains via HTTPS for the next two years and also include in the preload list
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload</pre>
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload</pre>


=== See Also ===
=== See Also ===
Line 381: Line 381:
* [http://www.cspplayground.com/ Content Security Policy Playground]
* [http://www.cspplayground.com/ Content Security Policy Playground]
* [https://www.w3.org/TR/CSP2/ Content Security Policy Level 2 Standard]
* [https://www.w3.org/TR/CSP2/ Content Security Policy Level 2 Standard]
* [https://csp-evaluator.withgoogle.com/ Google CSP Evaluator]
* [[#X-Frame-Options|Using the frame-ancestors directive to prevent framing]]
* [[#X-Frame-Options|Using the frame-ancestors directive to prevent framing]]


Line 387: Line 388:
<tt>contribute.json</tt> is a text file placed within the root directory of a website that describes what it is, where its source exists, what technologies it uses, and how to reach support and contribute.  <tt>contribute.json</tt> is a Mozilla standard used to describe all active Mozilla websites and projects.
<tt>contribute.json</tt> is a text file placed within the root directory of a website that describes what it is, where its source exists, what technologies it uses, and how to reach support and contribute.  <tt>contribute.json</tt> is a Mozilla standard used to describe all active Mozilla websites and projects.


Its existence can greatly speed up the process of bug triage, particularly for smaller websites with just a handful of maintainers. It further assists with helping security researchers find testable of websites and instructs them on where where in Bugzilla to file their bugs against. As such, <tt>contribute.json</tt> is mandatory for all Mozilla websites, and must be maintained as contributors join and depart projects.
Its existence can greatly speed up the process of bug triage, particularly for smaller websites with just a handful of maintainers. It further assists security researchers to find testable websites and instructs them on where to file their bugs against. As such, <tt>contribute.json</tt> is mandatory for all Mozilla websites, and must be maintained as contributors join and depart projects.


Require subkeys include <tt>name</tt>, <tt>description</tt>, <tt>bugs</tt>, <tt>participate</tt> (particularly <tt>irc</tt> and <tt>irc-contacts</tt>), and <tt>urls</tt>.
Require subkeys include <tt>name</tt>, <tt>description</tt>, <tt>bugs</tt>, <tt>participate</tt> (particularly <tt>irc</tt> and <tt>irc-contacts</tt>), and <tt>urls</tt>.
Line 444: Line 445:
== Directives ==
== Directives ==


* Name: Cookie names may be either be prepended with either <tt>__Secure-</tt> or <tt>__Host-</tt> to prevent cookies from being overwritten by insecure sources
** Use <tt>__Host-</tt> for all cookies needed only on a specific domain (no subdomains) where <tt>Path</tt> is set to <tt>/</tt>
** Use <tt>__Secure-</tt> for all other cookies sent from secure origins (such as HTTPS)
* <tt>Secure</tt>: All cookies must be set with the <tt>Secure</tt> flag, indicating that they should only be sent over HTTPS
* <tt>Secure</tt>: All cookies must be set with the <tt>Secure</tt> flag, indicating that they should only be sent over HTTPS
* <tt>HttpOnly:</tt> Cookies that don't require access from JavaScript should be set with the <tt>HttpOnly</tt> flag
* <tt>HttpOnly:</tt> Cookies that don't require access from JavaScript should be set with the <tt>HttpOnly</tt> flag
Line 451: Line 455:
* <tt>Domain:</tt> Cookies should only be set with this if they need to be accessible on other domains, and should be set to the most restrictive domain possible
* <tt>Domain:</tt> Cookies should only be set with this if they need to be accessible on other domains, and should be set to the most restrictive domain possible
* <tt>Path:</tt> Cookies should be set to the most restrictive path possible, but for most applications this will be set to the root directory
* <tt>Path:</tt> Cookies should be set to the most restrictive path possible, but for most applications this will be set to the root directory
== Experimental Directives ==
* Name: Cookie names may be either be prepended with either <tt>__Secure-</tt> or <tt>__Host-</tt> to prevent cookies from being overwritten by insecure sources
** Use <tt>__Host-</tt> for all cookies set to an individual host (no Domain parameter) and with no Path parameter
** Use <tt>__Secure-</tt> for all other cookies


== Examples ==
== Examples ==
Line 472: Line 470:


* [https://tools.ietf.org/html/rfc6265 RFC 6265 (HTTP Cookies)]
* [https://tools.ietf.org/html/rfc6265 RFC 6265 (HTTP Cookies)]
* [https://tools.ietf.org/html/draft-west-cookie-prefixes HTTP Cookie Prefixes (Experimental)]
* [https://tools.ietf.org/html/draft-west-cookie-prefixes HTTP Cookie Prefixes]




Line 579: Line 577:
# Only send the shortened referrer to a foreign origin, full referrer to a local host
# Only send the shortened referrer to a foreign origin, full referrer to a local host
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: strict-origin-when-cross-origin
# Disable referrers for browsers that don't support strict-origin-when-cross-origin
# Uses strict-origin-when-cross-origin for browsers that do
Referrer-Policy: no-referrer, strict-origin-when-cross-origin


# Do the same, but with a meta tag
# Do the same, but with a meta tag
&lt;meta http-equiv="Referrer-Policy" content="strict-origin-when-cross-origin"&gt;
&lt;meta http-equiv="Referrer-Policy" content="no-referrer, strict-origin-when-cross-origin"&gt;


# Do the same, but only for a single link
# Do the same, but only for a single link
&lt;a href="https://mozilla.org/" referrerpolicy="strict-origin-when-cross-origin"&gt;</pre>
&lt;a href="https://mozilla.org/" referrerpolicy="no-referrer, strict-origin-when-cross-origin"&gt;</pre>


== See Also ==
== See Also ==
Line 681: Line 683:
== Examples ==
== Examples ==


<pre># Block site from being framed
<pre># Block site from being framed with X-Frame-Options and CSP
Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY</pre>
X-Frame-Options: DENY</pre>
<pre># Do the same thing, but with Content Security Policy
Content-Security-Policy: frame-ancestors 'none'</pre>


<pre># Only allow my site to frame itself
<pre># Only allow my site to frame itself
Content-Security-Policy: frame-ancestors 'self'
X-Frame-Options: SAMEORIGIN</pre>
X-Frame-Options: SAMEORIGIN</pre>


<pre># Do the same thing, but with Content Security Policy, and also allow frame-you.mozilla.org to frame the site
<pre># Allow only framer.mozilla.org to frame site
Content-Security-Policy: frame-ancestors 'self' https://frame-you.mozilla.org</pre>
# Note that this blocks framing from browsers that don't support CSP2+
Content-Security-Policy: frame-ancestors https://framer.mozilla.org
X-Frame-Options: DENY</pre>


== See Also ==
== See Also ==


* [https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options MDN on X-Frame-Options]
* [https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options MDN on X-Frame-Options]
* [https://www.w3.org/TR/CSP2/#directive-frame-ancestors CSP standard on 'frame-ancestors']
* [https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet OWASP Clickjacking Defense Cheat Sheet]
* [https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet OWASP Clickjacking Defense Cheat Sheet]


Line 719: Line 723:
! scope="col" style="width: 6em;" | Editor
! scope="col" style="width: 6em;" | Editor
! Changes
! Changes
|-
| style="padding-left: .5em; text-align: left;" | June, 2017
| align="center" | April
| style="padding-left: .5em;" | Moved cookie prefixes to no longer be experimental
|-
|-
| style="padding-left: .5em; text-align: left;" | November, 2016
| style="padding-left: .5em; text-align: left;" | November, 2016
| align="center" | April
| align="center" | April
| style="padding-left: .5em;" | Added Referrer Policy
| style="padding-left: .5em;" | Added Referrer Policy, tidied up XFO examples
|-
|-
| style="padding-left: .5em; text-align: left;" | October, 2016
| style="padding-left: .5em; text-align: left;" | October, 2016
Gdestuynder
Confirmed users
502

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1154686...1182557"