Web security is a thing that cannot be overemphasized. We found that many websites in China have not implemented full-site HTTPS, and the practice of other security policies is even less. The purpose of this paper is not to discuss the details of security and attack, but to trigger the thinking and attention to security from the perspective of policy.

1. Data channel security

The network connection under THE HTTP protocol is based on plaintext, and the information is likely to be leaked and tampered with. Even users do not know whether the communication partner is the server they want to connect to. Therefore, the security of the information channel has the following two objectives:

  • The identity authentication
  • Data cannot be leaked or tampered with

Fortunately HTTPS solves the above problem.

(For more details on HTTPS, see the inside scoop on HTTPS.)

In theory HTTPS is secure, but even so HTTPS should be taken seriously, because in theory it is the same as in practice, but in practice it is another matter. The recent heart bug is one example.

2. Browser security

HTTPS solves point-to-point security and authentication issues. There are only two areas where the next problem will occur: the browser and the server. There is no silver bullet that can solve the security problem at this level.

2.1 origin source

One concept that is particularly important to understand browser security is origin. What is a source?

  • The same HOST
  • Same protocol
  • Same port

For chestnuts

  • https://www.wilddog.com and http://www.wilddog.com are not cognates because of different protocols.
  • http://wilddog.com and http://www.wilddog.com are not cognates because domain names are different.
  • http://wilddog.com and http://wilddog.com:8080 are not cognate because the ports are different.

The importance of the concept of source starts with the same origin policy.

2.2 Same Origin Policy

The same origin policy restricts how loaded text or scripts from one origin can interact with resources from other sources. Simply put, js on a page of one source can only access the resources of the current source, not other sources.

So what are the resources?

  • DOM
  • Network resources requested through AJAX
  • Cookie
  • WebStorage, webSql
  • …

Obviously, the same origin policy separates resources by source, protecting user information security.

The same-origin policy is a wall, but the wall is not impervious. There are many ways to bypass the same-origin policy and allow javascript to access resources from other sources. Such as:

JSONP

Iframe +window.name iframe+window.domain iframe+webMessage

CORS

For more details, check out my other blog at jackxy.com/cross-origi…

Of these, ONLY CORS is a “legitimate” way to bypass the same-origin policy

The same origin policy is the basis of the browser security policy, but the same origin policy is helpless against many attacks, such as XSS

2.3 XSS (Cross Site Script)

Cross-site scripting attacks have a similar name to same-origin policies, but in fact they are almost unrelated. Cross-site scripting attacks are essentially injection attacks (see here for more on injection attacks). The principle, in a nutshell, is to use various means to add malicious code to the web page and get the victim to execute the script. There are many examples of XSS just search for them. XSS does everything a user can do with a browser. You can see that the same-origin policy does not guarantee protection from XSS attacks because the attacker is in the same origin.

XSS attacks are classified into attack modes

  • reflective
  • Storage type
  • The document type

This classification method is somewhat outdated. For a long time, it has been believed that there are three types of XSS classification, but in practice it is often impossible to distinguish them, so a more specific classification method can be divided into the following two types:

  • Client (Client type)
  • Server (Server type)

Server-side XSS is when code is inserted on the server side, and client-side XSS is when code is inserted on the client side.

2.4 Preventing XSS Attacks – Escape

Both server-side and client-side XSS require two conditions for an attack to be completed

  • Code is injected
  • The code is executed

In fact, XSS attacks can be completely eliminated by ensuring that code is not executed under any circumstances. See this document for details

Here’s a quick conclusion:

Never insert untrusted data directly into the DOM anywhere; always escape.

2.4.1 For some locations, untrusted data can be escaped to ensure security

  • General tag attribute value
  • Internal HTML for div Body

2.4.2 For some positions, it is not safe even after escaping

  • In the script
  • In the comments
  • The attribute name of the TAB
  • Tag name
  • CSS tags

Parse request content-type: application/ JSON;

2.4.4 If part of the URL of the link is dynamically generated, it must be escaped.

2.5 HTML Escape:

 -- amp;
  -- lt;
  -- gt;
 " -- quot;
 ' -- #x27;
 / -- #x2F;Copy the code

2.6 Using the XSS-filter of the Browser

Modern browsers have some protection against reflective XSS, which checks for dependencies between URLS and elements in the DOM. But this does not completely prevent reflective XSS. In addition, browsers are not immune to stored XSS for the simple reason that user needs are diverse. So you can’t rely on browsers to defend against XSS.

You can control whether xSS-filter is turned on via the HTTP header, which of course is turned on by default. X-XSS-Protection

2.7 CSP (the Content Security Policy)

In principle, preventing XSS is a simple matter, but in practice, business code is so diverse and complex that vulnerabilities still occur. CSP is not designed to prevent XSS attacks, but to minimize damage if XSS occurs. In fact, there is no other way to prevent XSS from happening than to do XSS escape by the developer himself. CSP is arguably the most affordable thing HTML5 has brought to Web security. The CSP’s role is to limit the behavior of a page whether or not it is controlled by Javacript. How do you introduce a CSP?

Through the response header

// Only scripts are allowed to load content-security-policy from the source: script-src ‘self’

Through the HTML META tag

Meta http-equiv= “content-security-policy” Content = “script-src ‘self'”

So what else can CSP restrict besides script-src?

Base-uri: limits the uri of this document child-src: limits the source of the child window (iframe, pop-ups, etc.) instead of frame-src connect-src: limits the source that the script can access Limiting the font's source form-action: Limiting the source frame-rooted piece to which the form can be submitted: Defines which pages can load frame-src with iframe,frame,object, etc. : Deprecated with child-src, which limits which sources the current page can load, corresponding to frame-rooted img-src: limits which sources an image can load media-src from: Restrict video, audio, source, track which sources can be loaded from Object-src: Restrict which sources plug-ins can be loaded from sandbox: Force sandbox mode onCopy the code

As you can see, CSP is a powerful strategy that limits the source of almost all available resources. Using CSP well can greatly reduce the risk of XSS

In addition, CSP provides a content-security-policy-report-only Report header, which is used to Report CSP status to the server without going into details.

Content-Security-Policy-Report-Only: script-src 'self'; 
            report-uri /csp-report-endpoint/Copy the code

CSP currently has two versions, CSP1 and CSP2. You can check the support status of the two versions at caniuse.com/#search=csp.

CSP1:

CSP2:

2.8 X – Frame – the Options

This is the response header that is being used now, but could later be replaced by the CSP frame-rooted. A better way to use the currently supported state than CSP frame-rooted:

X-frame-options :DENY// This page is not allowed to be loaded in Frame mode. X-frame-options :SAMEORIGIN// This page is only allowed to be loaded in same-origin pages. X-frame-options: URI // This page is only allowed to be loaded in specific fieldsCopy the code

2.9 Http – Only

Protecting cookies with HTTP-only ensures that a user’s cookie is secure even if XSS occurs. Cookies protected with HTTP-only are not read or written by javascript.

2.10 Iframe Sandbox Environment

Despite the same origin policy, there are many problems with iframes, such as the use of iframes across sources. HTML5 provides a security property called the Sandbox for iframe. If you use this property, the power of iframe will be limited, which we will discuss in more detail in a future article.

2.11 Other SECURity-related HTTP Headers

X-content-type-options prevents the browser from doing content-type sniffing. Tells the browser to trust the type of resources delivered by this server to prevent type-sniffing attacks.

HPKP(Public Key Pinning) Public Key Pinning is a response header that detects whether a certificate’s Public Key has changed, preventing man-in-the-middle attacks.

HSTS (HTTP strict-transport-Security) enforces the USE of TSL as the data channel. It’s also detailed in the inside scoop on HTTPS sites

Said so much we look at the following some of the various sites to achieve the situation.

Google is the benchmark of the industry, there is no peer in the Internet, just learn from Google!

www.wilddog.com also implements several important HTTP headers.

Baidu is doing worse. Such a large-scale Internet company is so insensitive to security and technology, which can only be said to be very sad. It fully shows that Chinese Internet enterprises attach very little importance to security. It is worth noting that baidu’s HTTP to HTTPS redirect is actually done by the server.

Let’s look at the industry joke 12306!

3.HTML5’s impact on Web security

Html5 brings a lot of new features that give more power to browsers and javascript. However, the greater the capability, the greater the danger of being breached.

HTML5’s influence on XSS is mainly reflected in:

  • The bigger the attack surface, the more tags and attributes HTML5 brings, the more likely XSS will happen
  • The greater the harm, the more resources of HTML5 can be utilized by XSS. Hackers can take advantage of all browser permissions, such as local storage, GEO, WebSocket, Webworker.

Unfortunately HTML does not bring a systemic solution to XSS and XSRF. Under this premise, CSP becomes very important and can greatly reduce the harm after XSS.

The HTML5 era is actually putting more demands on developers, because there’s more interaction, there’s more front-end behavior, there’s more API in HTML5. Hope to encourage each other, do not do doctor Mongolia, with the majority of developers to improve the User experience of the Chinese Internet!

About the author: jackxy.com/

4. references

Security-related HTTP headers ↩

Same Origin policy ↩

CSP ↩

HPKP ↩

The w3c iframe element ↩

MDN web security ↩

XSS cheet sheet ↩