Learn about the same Origin policy, cross-site scripting (XSS), cross-domain request forgery (CSRF), and security sandbox.
Here is the mind map for this article. Just give it a thumbs up.
(mobile phone may not be clear) to obtain hd PDF, please reply to the wechat public number [Little Lion front-end Vue] browser security
The same-origin policy
What is the same Origin policy
Two urls are said to be homologous if they share the same protocol, domain name, and port. If two different sources want to access each other’s resources or manipulate the DOM, they are constrained by a basic set of security policies, which we call the same-origin policy.
- DOM level: Limits how JavaScript scripts from different sources can read and write to the current DOM object.
- Data level: The Cookie, IndexDB, LocalStorage and other data of the current site can be read by sites with different sources.
- Network layer: Limits the ability to send data from a site to a site with different sources via XMLHttpRequest, etc.
Second, safety and convenience trade-offs
- Third party resources can be embedded in the page. – > XSS attacks
- To address XSS attacks, a content security policy, called CSP, has been introduced in browsers.
- The core idea of CSP is to let the server decide what resources the browser can load and whether the browser can execute inline JavaScript code.
- By doing so, you can greatly reduce XSS attacks.
- Cross-domain resource sharing
-
Cross-domain requests cannot be made directly using XMLHttpRequest or Fetch, so browsers introduce cross-domain resource sharing policies on top of this strict policy to make it safe for cross-domain operations.
-
Cross-domain resource sharing (CORS), which enables cross-domain access control and secure cross-domain data transfer.
- Cross-document messaging mechanisms
- The DOM of two different sources cannot be manipulated with each other, so the browser implements cross-document messaging and communicates with the DOM of different sources through the JavaScript interface of window.postMessage.
The interview questions
What is the relationship between the same Origin policy, CSP, and CROS?
The same origin policy means that courtyard pages can operate with each other, but different sources can operate with each other only by means provided by browsers, for example:
- Reading data and manipulating the DOM crosses the document mechanism
- Cross-domain requests use the CROS mechanism
- Use SCP to refer to third-party resources
Why can’t XMLHttpRequest request resources across domains?
- The same origin policy exists and resource requests from different sources are blocked.
- Cross-domain requests cannot be made directly with XMLHttpRequest, so browsers add cross-domain resource sharing to this strict policy to make it safe for cross-domain operations.
Cross-site scripting (XSS)
XSS can do
- Cookie information can be stolen
- You can listen for user behavior
- The DOM can be modified to forge a fake login window to trick users into entering information such as user names and passwords
- You can also generate floating window ads within the page, which can seriously affect the user experience
How is the malicious script injected?
- Stored XSS attacks: hackers store malicious code on vulnerable servers, browsers visit pages containing malicious code, and browsers upload user information to only servers.
- Reflective XSS attack: A user submits a request containing malicious code to the Web server. When the Web server receives the request, the malicious code is reflected back to the browser.
- Dom-based XSS attacks that do not involve the page Web server and modify the data of a Web page during the transfer of Web resources or during the user’s use of the page. For example, through network hijacking, the content of the HTML page is modified during the page transmission. There are many types of hijacking, including WiFi router hijacking, and local malware hijacking.
Iii. How to prevent XSS attacks?
- The server filters or transcodes the input script
- Make full use ofCSP
- Restrict the loading of resource files in other domains, so that even if a hacker inserts a JavaScript file, the JavaScript file cannot be loaded;
- Do not submit data to third-party domains, so that user data is not leaked.
- Prohibit execution of inline scripts and unauthorized scripts;
- It also provides a reporting mechanism, which helps us discover XSS attacks as quickly as possible so that problems can be fixed as quickly as possible.
- Use the HttpOnly attribute
- Verification code
- Prevent scripts from posing as users to submit dangerous operations
- Limit the length
- You can also limit the input length for untrusted inputs
Cross-domain request forgery (CSRF) attack
Don't click on strange links
What is a CSRF attack?
Hackers take advantage of users’ login status and use third-party sites to do bad things.
- Automatically initiates Get requests
- Automatically initiates a POST request
- Entice users to click on links
Unlike XSS, CSRF attacks do not require the injection of malicious code into a user’s page, but simply exploit the vulnerability of the server and the user’s login status to carry out the attack.
How to prevent CSRF attacks?
Three requirements for a CSRF attack? 1. The target site must have CSRF vulnerability; 2. The user must have logged in to the target site and maintained the login status of the site on the browser. 3. Users are required to open a third-party site, which can be a hacker’s site or some forums;
1. Make full use of the SameSite attribute of Cookie.
- Strict is strictest. The browser completely forbids third-party cookies.
- Lax is a little looser. Linked open, Get forms carry cookies.
- None, which sends Cookie data in any case.
2. Verify the source site of the requestOrigin information during Post requests (using CSDN as an example)
3. CSRF Token
- First, when the browser makes a request to the server, the server generates a CSRF Token.
- Step 2: If you want to initiate a transfer request on the browser side, you need to bring the CSRF Token in the page, and then the server will verify whether the Token is valid.
4.X-FRAME-OPTIONS
- DENY indicates that the page is not allowed to be displayed in iframe mode
- SAMEORIGIN, the same domain name can be displayed via ifame
- Allow-from, which can be displayed in the iframe of the specified source
Security sandbox
Is the wall between the page and the system
First, how does the safety sandbox affect the functions of each module?
Persistent storage Modern browsers do all the reading and writing of files in the browser kernel, and then relay the results to the renderer process via IPC.
The Web access browser kernel checks whether the renderer has permission to request a URL before processing it. For example, check whether XMLHttpRequest or Fetch is a cross-site request, or check whether an HTTPS site contains an HTTP request.
The user interaction
- The renderer does not have direct access to window handles.
- Limits the ability of the renderer to monitor user input events
Ii. Site Isolation
Site isolation is when Chrome puts related pages from the same site (including the same root domain and the same protocol address) into the same rendering process.
conclusion
⭐️ article output is not easy, please merciless three even bar ~