Following up the book, JS Security Policy, we have a quick overview of some common security policies in Web development. This article continues with another Web defense strategy, the HTTP Security Header.

An overview of the

HTTP Headers is subordinate information added by the client and server during HTTP transmission. A request header consists of a name (case insensitive) followed by a colon:, and a specific value (without a newline character). There are several common Http headers, such as:

  • Auth class: Authorization, www-authenticate, proxy-authenticate and so on
  • Cache classes: Age, Expires, cache-control, and so on
  • Conditional request classes: if-match, if-modified-since, etc

These headers should be familiar; However, for the security class HTTP header, I asked the surrounding partner, many people are not familiar with; So, this period on the opportunity to introduce a few very practical safety head, we have a look at their own use of several.

Trusted Types

Let’s start with the trusted types mentioned earlier. Trusted Types are primarily used to defend against DOM-based cross-site scripting attacks (DOM-based XSS).

Dom-based XSS: an attack method to transmit malicious data to a dynamic language receiver; The most commonly attacked receivers in JS are eval() and.innerhtml.

Trusted Types is a blacklisting mechanism that prevents vulnerable Web apis from being called by browsers. In addition, major browser vendors now provide a special object called trustedTypes to replace the API.

Enabling Trusted Types is simple. The server returns HTTP messages with the following security headers:

Content-Security-Policy: require-trusted-types-for 'script'
Copy the code

With this enabled, the following code — modify.innerhtml — throws an exception directly.

el.innerHTML = "<img src=x onerror=alert(1)>"; // This throws an exception.
Copy the code

The alternative is to bypass the checks using strings generated by trustedTypes. In the following example, by using trustedTypes, let the developer consciously replace the tag tags — < and > — in the inner HTML with special symbols (< and >) to prevent XSS injection.

const policy = trustedTypes.createPolicy("escapePolicy", {
  createHTML: (str) = > {
    return str.replace(/\</g."&lt;").replace(/>/g."&gt;"); }});// accepted operation
const escaped = policy.createHTML("<img src=x onerror=alert(1)>");
el.innerHTML = escaped; // '< img src=x onerror=alert(1)> '
Copy the code

Content Security Policy (CSP)

We’ve talked about CSP many times, but let’s go through it again very quickly. CSP is a security policy used primarily to prevent cross-site script execution. It is generally recommended that all Web applications enable CSP:

  • If the script is rendered by the server, at least enable the Nonce mechanism of CSP
  • If the script is hosted by a static resource, at least enable the Integrity mechanism of CSP

X-Content-Type-Options

Some browsers, such as Internet Explorer < 8.0, will have a MIME obfuscation. As a common example, some images contain legitimate HTML tags (you know), and when browsers load these images, they execute the HTML script inside them, triggering what is known as a MIME-based scripting attack.

However, this Type of attack can be avoided if x-Content-Type-options: nosniffing is added to the server response header. The browser will force the resource to be described as “content-Type”, otherwise an exception will be raised.

SEC7112: Script from http://xxx.com was blocked due to mime type mismatch script.asp
Copy the code

For image resources with MIME types (such as image/ JPEG), the browser will treat them as static resources and will not continue executing the script.

X-Frame-Options

X-frame-options as the name implies, and iframe embedded security header. Some sites may embed your web page as iframe, and then hijack your user operation; Some uninformed users can be hijacked by feedback directed to insecure sites or reveal sensitive information. This is the classic spectre-type attacks.

If you don’t want others to embed in your site, use a security header x-frame-options: DENY, and its < Frame >,

HTTP Strict Transport Security (HSTS)

The HSTS header is also easy to understand: enforces HTTPS transport. HTTP is an unencrypted connection, which is vulnerable to interception by network eavesdroppers. If the strict-transport-Security header is enabled, the browser does not load HTTP-related resources, but HTTPS resources instead.

Strict-Transport-Security: max-age=31536000
Copy the code

Cross-origin (Cross domain)

There are also some common security mechanisms related to cross-domains, which we’ll quickly go through:

  • Cross-Origin Resource Policy (CORP)

    The default mechanism of the browser is the same origin policy, which means that cross-domain resources cannot be loaded. However, there are situations where we want to change the default mechanism, and that’s when CORP can be enabled. CORP accepts only three values: same-origin, same-site, and cross-origin, as the name implies, same-origin (default), same-site, and accept cross-domain resources.

    Cross-Origin-Resource-Policy: same-origin
Copy the code

  • Cross-Origin Resource Sharing (CORS)

    As mentioned above, the same origin policy for browsers can be enabled to whitelist specific sites, which is known as CORS. If you add trusted sites to security, the specified cross-domain resources are allowed to load:

    Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Copy the code

  • Cross-Origin Embedder Policy (COEP)

    COEP is often used in conjunction with CORP and CORS, so that resources embedded in your site (script or worker) can only load cross-domain resources configured with CORP or CORS. The enabling mode is as follows:

    Cross-Origin-Embedder-Policy: require-corp
Copy the code

    The benefit of COEP is to enable cross-domain isolation by using if(self.crossoriginIsolated) {… }. After the success of the isolation, can use the default browser banned SharedArrayBuffer, performance. MeasureUserAgentSpecificMemory () some JS Self – Profiling API.

  • Cross-Origin Opener Policy (COOP)

    COOP deals with user privacy policies, where some sites open other sites in a new TAB in the browser using window.open() or target=”_blank”; However, this operation will be traced to the source information by the other website, resulting in the disclosure of user privacy or other harmful attacks. In order to avoid this kind of surprise, we will produce the price COOP head, to prevent user privacy disclosure:

    Cross-Origin-Opener-Policy: same-origin-allow-popups
Copy the code

summary

This article lists some HTTP headers that secure your site. You can also go back and check yourself if you’re using these heads in your project; If not, turn it on as soon as possible. These are tried-and-true strategies that can work when started.