User:Apking/Web Security Guidelines: Difference between revisions

* <tt>Domain:</tt> Cookies should only be set with this if they need to be accessible on other sites, and should use the most restrictive domain possible

* <tt>Path:</tt> Cookies should be set to the most restrictive path possible, but for most applications this is set to the root ("/")

** Use <tt>__Secure-</tt> for all other cookies, preventing them from being overwritten by insecure sources

<pre># Set a session identifier cookie only accessible on this host that gets purged when the user closes their browser

Set-Cookie: MOZSESSIONID=980e5da39d4b472b9f504cac947e; Path=/; Secure; HttpOnly</pre>

<pre># Set a session cookie for all mozilla.org sites that expires in 30 days using the experimental __Secure- prefix

Set-Cookie: __Secure-MOZSESSIONID=7307d70a86bd4ab5a004997627f3; Max-Age=2592000; Domain=mozilla.org; Path=/; Secure; HttpOnly</pre>

<pre># Javascript sets a long-lived cookie for the current host, accessible by Javascript, when the user accepts the ToS

<tt>Access-Control-Allow-Origin</tt> is an HTTP header in that defines which foreign origins are allowed to access the content of pages on your domain via scripts using methods such as XMLHttpRequest.  <tt>crossorigin.xml</tt> and <tt>clientaccesspolicy.xml</tt> provide similar functionality, but for Flash and Silverlight-based applications, respectively.

These headers and files should not be present unless specifically needed. Use cases include content delivery networks (CDNs) that provide hosting for JavaScript/CSS libraries and public API endpoints. If present, they should be locked down to as few origins and resources as is needed for proper function. For example, if your server provides both a website and an API intended for XMLHttpRequest access on a remote websites, <em>only</em> the API resources should return the <tt>Access-Control-Allow-Origin</tt> header. Failure to do so will allow foreign origins to read the contents of any page on your origin.

Cross-site reference forgeries are a class of attacks where unauthorized commands are transmitted from a user that the website trusts. Because they inhirit the users cookies (and hence session information), they appear to be validly issued commands. A CSRF attack might like like this:

When a user visits a page with that HTML fragment, the browser will attempt to make a GET request to that URL. If the user is logged in, the browser will send along their session cookies and the account deletion attempt will be successful.

While there are a variety of mitigation strategies such as Origin/Referrer checking and challenge-response systems (such as CAPTCHA), the most common and transparent method of CSRF mitigation is the use of anti-CSRF tokens. Anti-CSRF tokens prevent CSRF attacks by requiring the existence of a secret, unique, and unpredictable token on all destructive changes. These tokens can be set for an entire user session, rotated on a regular basis, or be created uniquely for each request.

robots.txt is a text file placed within the root directory of a site that tells robots (such as indexers employed by search engines) how to behave, particularly by telling them not to index certain paths on the website. This is particularly useful for reducing load on your website, by stopping the indexing of automatically generated content.

Sites may optionally use robots.txt, but should only use it for the purpose of reducing load on a website. It should not be used as a way to prevent the disclosure of private information or to hide portions of a website. Although this does prevent these sites from appearing in search engines, it does not prevent its discovery from attackers, as robots.txt is frequently used for reconnaisance.

<pre># Using robots.txt to hide certain pages is a terrible idea

Subresource integrity is a recent W3C standard that protects against attackers from modifying the contents of JavaScript libraries hosted on content delivery networks in order to create vulnerabilities in applications.

For example, a JavaScript resource on jquery.org that is loaded from mozilla.org has access to the entire contents of everything of mozilla.org. If this resource was successfully attacked, it could modify download links, deface the site, steal credentials, cause denial-of-service attacks, and more.

Subresource integrity locks an external JavaScript resource to its known contents at a specific point in time. If the file was modified at any point thereafter, web browsers will refuse to load it. As such, the use of subresource integrity is mandatory for all external JavaScript resources loaded from sources not hosted on Mozilla-controlled systems.

Note that CDNs must support the Cross Origin Resource Sharing (CORS) standard by setting the Access-Control-Allow-Origin header. Most CDNs already do this, but if the CDN you are loading does not support CORS, please contact Information Security. We are happy to contact the CDN on your behalf.

* <tt>crossorigin:</tt> should be <tt>anonymous</tt> to inform browsers to send anonymous requests, without cookies, etc.

* [https://www.srihash.org/ SRI Hash Generator] - generates the <tt>&lt;script&gt;</tt> tags for you, and informs you if the CDN lacks CORS support

X-Frame-Options is an HTTP header that allows sites control over how your site may be framed within an iframe. Clickjacking is a practical attack that allows malicious sites to trick users into clicking links on your site even though they may appear to be something else entirely. As such, the use of the X-Frame-Options header is mandatory for all new websites, and all existing websites are expected to add support for X-Frame-Options as soon as possible.

Sites that require the ability to be iframed must either use the ALLOW-FROM directive or employ JavaScript defenses to prevent Clickjacking from malicious origins.

* <tt>SAMEORIGIN</tt>: allow the same origin to iframe the site

* <tt>ALLOW-FROM <em>uri</em></tt>: allow specified URI to iframe site (not supported in Chrome and Safari)

X-XSS-Protection is an feature of Internet Explorer and Chrome that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. New sites should use this header, but given the small but possible risk of false positives, is only recommended for existing sites.