Shulou(Shulou.com)06/01 Report--

In this article, the editor introduces in detail "what are the interview questions for the browser", the content is detailed, the steps are clear, and the details are handled properly. I hope this article "what are the interview questions for the browser" can help you solve your doubts? let's follow the editor's ideas to learn new knowledge.

1. What are the common browser kernels?

The kernel of the browser can be divided into two parts:

Rendering engine and JS engine (Note: the browser kernel we often talk about refers to the rendering engine)

As the JS engine becomes more and more independent, the kernel only refers to the rendering engine. The rendering engine is mainly used to request web page resources to be parsed and presented to users after they are parsed and typeset.

Browser / RunTime kernel (rendering engine) JavaScript engine ChromeBlink (28 ~) Webkit (Chrome 27) V8FireFoxGeckoSpiderMonkeySafariWebkitJavaScriptCoreEdgeEdgeHTMLChakra (For JavaScript) IETridentChakra (For JScript) OperaPresto- > blinkLinear A (4.06.1) / Linear B (7.09.2) / Futhark (9.510.2) / Carakan (10.5 -) Node.js-V82. What are the main components of the browser?

User interface: including address bar, forward / back / refresh / bookmark buttons

Browser engine: passing instructions between the user interface and the rendering engine

Rendering engine: used to draw the requested content

Network: used to make network calls, such as http requests, with platform-independent interfaces that can work on different platforms

JavaScript interpreter: used to parse and execute JavaScript code

User interface backend: used to draw basic widgets, such as combo boxes and windows, the underlying user interface using the operating system

Data storage: belongs to the persistence layer, the browser stores all kinds of data similar to cookie in the hard disk. HTML5 defines web database technology, which is a lightweight and complete client storage technology.

Note: unlike most browsers, each tab of the Chrome browser corresponds to an instance of the rendering engine. Each tab is a separate process.

3. Tell me what happens from input URL to page rendering?

This question can be said to be the most common question in the interview and can be infinitely difficult. In general, the interviewer asks this question to examine the depth of your front-end knowledge.

1. The browser accepts URL to open the network request thread (involving browser mechanism, threads and processes, etc.)

2. Start the network thread to issue a complete http request (involving: DNS query, TCP/IP request, layer 5 network protocol, etc.)

3. Receive the request from the server to the corresponding backend (related to: load balancing, security interception, backend internal processing, etc.)

4. Http interaction between background and foreground (related to: http header, response code, message structure, cookie, etc.)

5. Cache issues (involving: http strong cache and negotiation cache, cache header, etag,expired,cache-control, etc.)

6. The parsing process after the browser receives the http packet (involves html lexical analysis, parsing into DOM tree, parsing CSS to generate CSSOM tree, and merging to generate render rendering tree. Then layout layout, painting rendering, composite layer composition, GPU drawing, outer chain processing, etc.)

7. Css visualization model (related to: element rendering rules, such as: including blocks, control boxes, BFC,IFC, etc.)

8. JS engine parsing process (involving: JS parsing phase, preprocessing phase, execution phase generation execution context, VO (global object), scope chain, recycling mechanism, etc.)

You will find that a simple input URL to the page rendering, there will be so much between the process, do not feel collapsed in an instant? (don't worry, we will not go so deep in this chapter, first teach you how to answer this question, the following section will be covered separately.)

The browser obtains the IP address of the domain name through the DNS server and requests the HTML text from this IP address.

Browser rendering process parses HTML text and builds DOM tree

When parsing HTML, if you encounter an inline style or style file, download and build the style rules. If you encounter a JavaScript script, you will download and execute the script.

After the DOM tree and CSSOM are built, the rendering process merges the two into a render tree (render tree)

The rendering process begins to lay out the render tree to generate a layout tree (layout tree)

The rendering tree draws the layout tree to generate drawing records.

4. How does the browser parse the code?

Parsing HTML

HTML is parsed line by line, and the browser's rendering engine parses the HTML document and converts it into a DOM node.

Parse HTML into many Tokens

Parse Tokens into object

Combine object into a DOM tree

Parsing CSS

The browser parses the CSS selector from right to left

We know that merging the DOM tree and the CSSOM tree into a render tree actually attaches the CSSOM to the DOM tree, so we need to traverse the DOM tree according to the information provided by the selector.

Let's look at an example:

.nav .title span {color:blue} Nanjiu front end

Match from right to left:

First find all the rightmost node span, and for each span, look up for the node div.title

The node of div.nav is searched up by h4.

Finally, finding the root element html ends the traversal of the branch.

Parsing JS

There is a js parser tool in the browser that is specifically used to parse our js code.

When the browser encounters js code, it immediately summons the "js parser" to work.

The parser finds all variables, functions, parameters, and so on in the js and assigns the variable to undefined.

Take the function out into a function block and store it in the warehouse. When this is done, you begin to parse the code line by line (from top to bottom, from left to right), and then match it to the repository.

The difference between 5.DOMContentLoaded and load?

DOMContentLoaded: triggered only after DOM parsing is completed, excluding stylesheets, images and other resources.

Load: triggered when all the DOM, stylesheets, scripts, images, and other resources on the page have been loaded.

6. What is the difference between browser redrawing domain rearrangement?

Rearrange: part of the render tree or the whole render tree needs to be reanalyzed and the node size needs to be recalculated, as shown by regenerating the layout and rearranging elements

Redraw: due to a change in the geometric properties or style of a node, such as an element background element, the appearance of some elements is changed.

Redrawing does not necessarily lead to rearrangement, but rearrangement must lead to redrawing.

How to trigger redrawing and rearrangement?

Any change to the information used to build the render tree results in a rearrangement or redrawing:

Add, delete, update DOM nodes

Hide a DOM node through display: none-trigger rearrangement and redraw

Hide a DOM node through visibility: hidden-only triggers a redraw because there is no geometric change

Move or animate the DOM node on the page

Add a style sheet and adjust the style properties

User behavior, such as resizing windows, changing font sizes, or scrolling.

How to avoid redrawing or rearranging?

Focus on changing styles: for example, using class to change styles

Using document.createDocumentFragment (): we can create a node that is outside the DOM tree through createDocumentFragment, then operate in batches on this node, and finally insert it into the DOM tree, so only one rearrangement is triggered.

Upgrade to synthetic layer

Promoting an element to a composite layer has the following advantages:

The bitmap of the synthesis layer will be synthesized by GPU, which is faster than CPU processing.

When you need repaint, you only need repaint itself, which will not affect other layers.

For transform and opacity effects, layout and paint are not triggered

The best way to improve the composition layer is to use the will-change property of CSS

7. Why is JS single-threaded?

This is mainly related to the use of JS, JS as a browser scripting language, initially mainly to achieve the interaction between users and browsers, as well as the operation of DOM. This determines that it can only be single-threaded, otherwise it will bring a lot of complex synchronization problems.

For example: if JS is multithreaded and one thread modifies a DOM element and the other thread wants to delete the DOM element, the browser doesn't know who to listen to. So to avoid complexity, JavaScript has been designed to be single-threaded since it was born.

In order to take advantage of the computing power of multicore CPU, HTML5 proposes the Web Worker standard, which allows JavaScript scripts to create multiple threads, but child threads are completely controlled by the main thread and cannot operate DOM. Therefore, this new standard does not change the nature of JavaScript single thread.

Will 8.CSS loading block DOM?

Come to a conclusion first

CSS does not block parsing of DOM, but does block rendering of DOM

CSS blocks JS execution, but does not block the download of JS files

The role of CSSOM

The first is the ability for JavaScript to manipulate stylesheets

The second is to provide basic style information for the composition of layout trees.

The CSSOM embodied in DOM is document.styleSheets.

From the browser rendering process mentioned earlier, we can see that:

DOM and CSSOM are usually built in parallel, so CSS loading does not block DOM parsing

The render tree depends on the DOM tree and the CSSOM tree, so it must wait until both have been loaded before it can start to build rendering, so CSS loading blocks DOM rendering.

Because JavaScript can manipulate DOM and CSS, if you modify these element attributes and render the interface at the same time (that is, the JavaScript thread and UI thread do at the same time), the elements obtained before and after the rendering thread may be inconsistent. So in order to prevent unexpected results from rendering, the browser sets the mutually exclusive relationship between the GUI rendering thread and the JavaScript thread

JS needs to wait for CSS to download. Why? (CSS blocks DOM execution)

If the content of the JS script is to get the style of the element, it must rely on CSS. Because browsers don't know what to do inside JS, in order to avoid style acquisition, they have to wait until all the previous styles have been downloaded before executing JS. However, the JS file is downloaded in parallel with the CSS file, and the CSS file will be loaded and executed before the subsequent JS file is executed, so CSS will block the subsequent JS execution.

Avoid white screen and improve the loading speed of CSS

Use CDN (CDN will select the nearest node with cached content to provide you with resources according to the state of your network, so you can reduce the loading time)

Compress CSS

Rational use of cach

Reduce the number of http requests and merge CSS files

Will 9.JS block the page?

Come to a conclusion first

JS blocks the parsing of DOM, thus blocking the loading of pages

That's why we always talk about putting the JS file at the bottom.

Because JavaScript can manipulate DOM, if you modify these element attributes and render the interface at the same time (that is, the JavaScript thread and the UI thread run at the same time), the element data obtained before and after the rendering thread may be inconsistent.

Therefore, in order to prevent unexpected results in rendering, the browser sets the relationship between the GUI rendering thread and the JavaScript engine as mutually exclusive.

When the JavaScript engine executes, the GUI thread is suspended and the GUI update is saved in a queue until the engine thread is idle.

When the browser executes the JavaScript program, the GUI rendering thread is saved in a queue until the JS program is finished.

Therefore, if the JS is executed for too long, it will cause the rendering of the page to be incoherent, resulting in the feeling of blocking the page rendering load.

The difference between 10.defer and async?

Both load external JS files asynchronously and do not block DOM parsing

Async is executed after the external JS is loaded and before the Load event is triggered when the browser is idle. Scripts marked async are not guaranteed to be executed in the order in which they are specified, and this attribute has no effect on inline scripts (that is, scripts without the * * "src" * * attribute).

Defer is executed after JS loading, after the entire document parsing is complete, and before triggering the DOMContentLoaded event. If the src attribute (that is, embedded script) is missing, it should not be used because it does not work in this case.

11. Garbage collection mechanism of browsers

Garbage collection is an automatic memory management mechanism. When dynamic memory on your computer is no longer needed, it should be freed.

It should be noted that automatic means that the browser can automatically help us collect memory garbage, but it does not mean that we do not have to worry about memory management. If we do not operate properly, there will still be a memory overflow in JavaScript, causing the system to crash.

Since strings, arrays, objects, and so on do not have a fixed size, they need to be dynamically allocated when their size is known. Every time a JavaScript program creates a string, array, or object, the interpreter must allocate memory to store that entity.

The JavaScript interpreter can detect when a program is no longer using an object, and when it determines that the object is useless, it knows that the object is no longer needed and can free up the memory it occupies.

There are two methods of garbage collection commonly used by browsers: tag removal and reference counting.

Mark clear

This is the most commonly used garbage collection method in JavaScript.

Since 2012, all modern browsers have used the garbage collection method of tag removal, except for the reference counting method used in the earlier version of IE.

So what is mark removal?

There is a global object in JavaScript. Periodically, the garbage collector will start with this global object, find all the objects referenced from this global object, and then find the objects referenced by these objects. For these active object tags, this is the marking phase. The clear phase is to know the objects that are not marked.

One problem with tag cleanup is that after cleanup, the memory space is discontiguous, that is, memory fragmentation occurs. If a large contiguous memory space is needed later, it will not be able to meet the requirements. The tagging method can solve this problem effectively.

In the process of marking, the concept is introduced: tricolor labeling, tricolor is:

White: objects that are not marked, that is, unreachable objects (objects that are not scanned), can be recycled

Gray: an object that has been marked (reachable), but the object has not been scanned and cannot be recycled

Black: has been scanned (reachable object) and cannot be recycled

Tag finishing:

The marking phase is no different from tag cleanup, except that after the tag is finished, the tag collation moves the surviving objects to one side of memory, and finally cleans up the boundary memory.

Reference count

The meaning of reference counting is to track the number of times each value is referenced. When a variable An is assigned, the reference number of this value is 1, and when variable An is re-assigned, the reference number of the previous value is subtracted by 1. When the number of references becomes 0, there is no way to access the value, so you can clear the memory occupied by this value.

Most browsers have abandoned this recycling method.

Memory leak

To avoid memory leaks, once the data is no longer in use, it is best to release its reference by setting its value to null. This method is called contact reference.

What conditions can cause memory leaks? How to avoid it?

Take Vue as an example, there are usually these situations:

Monitoring is not unbound in window/body and other events.

Events bound to EventBus are not unbound

There is no unwatch after the $store,watch of Vuex.

Created using a third-party library without calling the correct destroy function

Solution: destroy in time in beforeDestroy

Event addEventListener, removeEventListener in the DOM/BOM object is bound.

Observer mode $on,$off processing.

If a timer is used in the component, the processing should be destroyed.

If a third-party library is used in the mounted/created hook, the corresponding initialization is destroyed.

Use weak references weakMap, weakSet.

When is the memory of different types of variables released in the browser?

Reference type

After there is no reference, it is automatically recycled through V8.

Basic type

If you are in the case of a closure, it will not be reclaimed by V8 until the closure has no reference.

In the case of non-closure, it is reclaimed when waiting for the new generation switch of V8.

twelve。 Tell me about the caching mechanism of the browser?

Understanding browser caching

When the browser requests a website, it will load a variety of resources, for some infrequent resources, the browser will save them in local memory, the next time to directly load these resources to improve access speed.

How do you know if a resource is a requested server or a read cache?

Looking at the figure above, some resources have size values, some are from disk cache, some are from memory cache, the size is the requested server resource, and the latter two are read caches.

Disk cache: it stores resources on disk and reads them directly from disk without downloading them when waiting for the next visit. Its direct operation object is CurlCacheManager. (slower than memory cache, but with large storage capacity and long storage time)

Memory cache: cache the resource in memory and read it directly from memory without downloading it again when you wait for the next access. It is the fastest in terms of efficiency and the shortest in terms of survival time. )

-memory cachedisk cache similarities can only store some derived class resource files, only some derived class resource files can be stored. When the data exits the process at different points, the data will be cleared. When the data exits the process, the data will not be erased. Generally, scripts, fonts and pictures will be stored in memory, such as css and so on.

Browser cache classification

Strong cache

Negotiation cache

When the browser requests resources from the server, it first determines whether it hits the strong cache, and then determines whether it hits the negotiation cache.

Strong cache

When loading a resource, the browser will first determine whether to hit the strong cache according to the header of the local cache resource. If it does, it will directly use the resource in the cache and will not send a request to the server. (the information in header here refers to expires and cache-control.)

Expires

This field is the http1.0 specification, and its value is an absolute time GMT formatted time string, such as Expires:Mon,18 Oct 2066 23:59:59 GMT. This time represents the expiration time of the resource, before which the cache is hit. This approach has an obvious disadvantage, because the expiration time is an absolute time, so when the time deviation between the server and the client is large, it will lead to cache confusion. So this approach was quickly abandoned in later versions of HTTP1.1.

Cache-Control

Cache-Control is the header information that appears when http1.1, which is mainly judged by the max-age value of this field. It is a relative time, such as Cache-Control:max-age=3600, which represents that the validity period of the resource is 3600 seconds. In addition to this field, cache-control has the following common setting values:

No-cache: you need to negotiate caching and send a request to the server to confirm whether to use caching.

No-store: the use of caching is prohibited and data is re-requested each time.

Public: can be cached by all users, including end users and intermediate proxy servers such as CDN.

Private: it can only be cached by the end user's browser, and relay cache servers such as CDN are not allowed to cache it.

Cache-Control and Expires can be enabled on the server side at the same time, and Cache-Control has a high priority when enabled at the same time.

Negotiation cache

When the strong cache fails, the browser sends a request to the server, which determines whether or not to hit the negotiation cache based on the information in the header. If hit, 304 is returned, telling the browser that the resource has not been updated and that the local cache can be used. (the header information here refers to Last-Modify/If-Modify-Since and ETag/If-None-Match.)

Last-Modify/If-Modify-Since

When the browser requests a resource for the first time, the header returned by the server will add Last-Modify,Last-modify as a time to identify the last modification time of the resource.

When the browser requests the resource again, the request header of the request contains If-Modify-Since, which is the Last-Modify returned before caching. After receiving the If-Modify-Since, the server determines whether the cache is hit according to the last modification time of the resource.

If the cache is hit, it returns 304, and no resource content is returned, and no Last-Modify is returned.

Disadvantages:

Resources have changed in a short period of time, and Last-Modified will not change.

Periodic changes. If the resource is modified back to its original form within a cycle, we think it is possible to use caching, but Last-Modified does not think so, so there is ETag.

ETag/If-None-Match

Unlike Last-Modify/If-Modify-Since, Etag/If-None-Match returns a check code. ETag can guarantee that each resource is unique, and changes in resources will lead to changes in ETag. The server determines whether to hit the cache based on the If-None-Match value sent on the browser.

Unlike Last-Modified, when the server returns a response of 304 Not Modified, because the ETag has been regenerated, the ETag will also be returned in response header, even if the ETag is the same as before.

Last-Modified and ETag can be used together, and the server will first verify the ETag. If it is consistent, it will continue to compare the Last-Modified, and finally decide whether to return it or not.

Summary

When a browser accesses a resource that has already been visited, its steps are:

1. Let's first see if it hits the strong cache, hit? Use the cache directly if the

two。 If you fail to hit the strong cache, a request will be sent to the server to see if it is hit. Negotiation cache

3. If the negotiation cache is hit, the server returns 304 and tells the browser that the local cache can be used.

4. If the negotiation cache is missed, the server will return the new resource to the browser

13. What is the homologous strategy of browsers and cross-domain?

Homologous strategy

Homologous strategy is a self-protective behavior of browsers. The so-called homology means that the protocol, domain name and port should all be the same.

Most of the content in the browser is restricted by the same origin policy, but the following three tags are not restricted:

Cross-domain

Cross-domain means that browsers cannot execute scripts under other domain names. It is restricted by the browser's homologous policy.

You may wonder whether the cross-domain request has been sent to the server or not.

In fact, a cross-domain request can be sent to the server, and the server can pass the accepted request and return the result normally, but the result is blocked by the browser.

Cross-domain solutions (list several commonly used ones)

JSONP

It mainly uses script tags that are not limited by the browser's same origin policy, and can get the data transferred from other sources, which needs the support of the server.

Advantages and disadvantages:

It has good compatibility and can be used to solve the problem of cross-domain data access in mainstream browsers. The disadvantage is that it only supports get requests, which is limited and insecure, and may be attacked by XSS.

Train of thought:

Declare a callback function with a function name (such as show) as a parameter value to be passed to the server that requests data across domains. The function parameter is to get the target data (the data returned by the server).

Create a tag, assign that cross-domain API data interface address to script's src, and pass the function name to the server in this address (you can pass the parameter:? callback=show through the question mark).

After receiving the request, the server needs to do special processing: concatenate the name of the passed function and the data it needs to give you into a string, for example: the name of the passed function is show, and the data it prepares is show ('Nanjiu').

Finally, the server returns the prepared data to the client through the HTTP protocol, and the client calls to execute the previously declared callback function (show) to operate on the returned data.

/ frontfunction jsonp ({url, params, callback}) {return new Promise ((resolve, reject) = > {let script = document.createElement ('script') window [callback] = function (data) {resolve (data) document.body.removeChild (script)} params = {. Params Callback} / / wd=b&callback=show let arrs = [] for (let key in params) {arrs.push (`${key} = ${params [key]}`)} script.src = `${url}? ${arrs.join ('&')} `document.body.appendChild (script)})} jsonp ({url: 'http://localhost:3000/say', params: {wd:' wxgongzhonghao'} Callback: 'show'}) .then (data = > {console.log (data)}) / / server with the help of the express framework let express = require (' express') let app = express () app.get ('/ say', function (req, res) {let {wd, callback} = req.query console.log (wd) / / Iloveyou console.log (callback) / / show res.end (`$ {callback} ('focus on the front end Nanjiu) `)) app.listen (3000)

The above code is equivalent to requesting data from the address http://localhost:3000/say?wd=wxgongzhonghao&callback=show, and then returns show ('focus on front-end Nanjiu') in the background, and finally runs the function show () to print out 'follow front-end Nanjiu'.

Cross-domain resource sharing (CORS)

CORS (Cross-Origin Resource Sharing) cross-domain resource sharing defines how browsers and servers should communicate when cross-domain resources must be accessed. The basic idea behind CORS is to use custom HTTP headers to let the browser communicate with the server to determine whether the request or response should succeed or fail.

CORS requires both browser and backend support. IE 8 and 9 need to be implemented through XDomainRequest.

Browsers will communicate with CORS automatically, and the key to achieving CORS communication is the back end. As long as the backend implements CORS, it implements cross-domain.

CORS can be enabled by setting Access-Control-Allow-Origin on the server. This attribute indicates which domain names can access the resource, and if you set a wildcard, it means that all websites can access the resource.

Although setting up the CORS has nothing to do with the front end, if the cross-domain problem is solved in this way, there will be two situations when sending a request, namely a simple request and a complex request.

Simple request: (the following two conditions are met, that is, simple request)

1. The request method is one of the following:

GET

POST

HEAD

2.Content-Type is one of the following three:

Text-plain

Multiparty/form-data

Application/x-www-form-urlencoded

Complex request:

If it's not a simple request, then it must be a complex request. For a CORS request with a complex request, a HTTP query request, called pre-check request, is added before the request is officially launched. The request is based on the option method to know whether the server allows the cross-domain request.

Nginx reverse proxy

The principle of Nginx reverse proxy is very simple, that is, all client requests must be processed by nginx, and nginx, as a proxy server, forwards the request to the backend, thus avoiding the browser's homology policy.

14. Tell me what a XSS attack is.

What is XSS?

The full name of XSS is Cross Site Scripting. In order to distinguish it from css, it is called XSS for short and cross-site script in Chinese.

XSS is a means for hackers to inject malicious scripts into the page and use malicious scripts to attack users when they browse the page.

What can XSS do?

Steal Cookie

Monitor user behavior, such as sending it to the hacker server after entering the account password

Generate floating window ads in web pages

Modify DOM forged login form

XSS implementation method

Storage XSS attack

Reflexive XSS attack

XSS attack based on DOM

How to stop XSS attacks?

Filter or transcode the input script

Filter or transcode the information entered by the user to ensure that the content entered by the user can not be executed during HTML parsing.

Using CSP

The implementation of this security policy is based on a HTTP header called Content-Security-Policy. (browser content security policy) its core idea is that the server determines which resources the browser loads.

Limit the loading of resource files in other domains, so that even if a hacker inserts a JavaScript file, the JavaScript file cannot be loaded

Prohibit the submission of data to third-party domains, so that user data will not be leaked

Provide a reporting mechanism, which can help us to detect XSS attacks in time.

Prohibit the execution of inline and unauthorized scripts

Using HttpOnly

Since many XSS attacks are designed to steal Cookie, we can also protect our Cookie by using the HttpOnly attribute. In this case, JavaScript cannot read the value of Cookie. This can also be a good defense against XSS attacks.

Usually, the server can set some Cookie to the HttpOnly flag. HttpOnly is set by the server through the HTTP response header. The following is a paragraph in the HTTP response header when Google is opened:

Set-cookie: NID=189=M8l6-z41asXtm2uEwcOC5oh9djkffOMhWqQrlnCtOI; expires=Sat, 18-Apr-2020 06:52:22 GMT; path=/; domain=.google.com; HttpOnly

For untrusted input, you can limit the length of the input

15. Tell me what is a CSRF attack?

What is a CSRF attack?

CSRF full name Cross-site request forgery, Chinese for cross-site request forgery, the attacker induced the victim to enter the third-party website, in the third-party website, send cross-site request to the attacked website. Use the registration credentials that the victim has obtained in the attacked website to bypass the background user authentication to achieve the purpose of pretending to be a user to perform an operation on the attacked website. CSRF attack is that hackers take advantage of the login status of users and do some bad things through third-party sites.

Several common types of attack

CSRF of type 1.GET

CSRF of type GET is very simple and usually requires only one HTTP request:

After the victim visits the page containing the img, the browser automatically sends a HTTP request to http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker. Bank.example will receive a cross-domain request containing the victim's login information.

CSRF of type 2.POST

This type of CSRF is usually leveraged with an automatically submitted form, such as:

Document.forms [0] .submit ()

After visiting the page, the form is automatically submitted, which is equivalent to simulating the user to complete a POST operation.

3. CSRF of link type

Link-type CSRF is not common, and it requires users to click on the link to trigger it, compared with the other two situations in which users get hit when they open the page. This type usually embeds malicious links in pictures posted in forums, or lures users into clicks in the form of advertisements, and attackers usually trick users into clicking with exaggerated words, such as:

Big news!

Since the user previously logged in to the trusted website An and saved the login status, as long as the user actively visited the above PHP page, the attack was successful.

Characteristics of CSRF

Attacks are generally launched on third-party websites, not on the attacked sites. The attacked website cannot prevent the attack from happening.

The attack uses the victim's login credentials on the attacked website to impersonate the victim to submit the operation, rather than directly stealing data.

Throughout the process, the attacker can not get the victim's login credentials, just "fake".

Cross-site requests can be made in a variety of ways: picture URL, hyperlink, CORS, Form submission, and so on. Some of the request methods can be directly embedded in third-party forums and articles, which is difficult to track.

CSRF is usually cross-domain because outdomains are usually more easily controlled by attackers. However, if there are easily exploited functions in this domain, such as forums and comment areas that can post pictures and links, attacks can be carried out directly in this domain, and such attacks are more dangerous.

Protection strategy

Hackers can only use the victim's cookie to swindle the trust of the server, but hackers can not get * * "cookie" * *, nor can they see the content of * * "cookie". In addition, the results returned by the server cannot be parsed by the hacker due to the limitation of the browser's "same origin policy".

This tells us that the objects we want to protect are services that can directly produce data changes, while services that read data do not need to be protected by CSRF. The key to protection is to "put in the request information that the hacker cannot forge."

Homology detection

Since most of the CSRF comes from third-party websites, we directly prohibit external domains (or untrusted domain names) from making requests to us.

So the question is, how can we tell if the request comes from Outland?

In the HTTP protocol, each asynchronous request carries two Header to mark the source domain name:

Origin Header

Referer Header

These two Header are brought automatically in most cases when the browser initiates a request, and the content cannot be customized by the front end. The server can determine the source domain of the request by parsing the domain names in the two Header.

Use Origin Header to determine the source domain name

In some requests related to CSRF, the Origin field is carried in the requested Header. The field contains the requested domain name (excluding path and query).

If Origin exists, you can directly use the fields in Origin to confirm the source domain name.

However, Origin does not exist in the following two situations:

IE11 homology policy: IE11 will not add Origin headers to cross-site CORS requests, and Referer headers will still be unique identifiers. The most fundamental reason is that the definition of homology in IE 11 is different from that of other browsers. There are two main differences. Please refer to MDN Same-origin_policy#IE_Exceptions.

Redirect: the Origin is not included in the redirected request after the 302 redirection, because the Origin may be considered sensitive information from other sources. In the case of 302 redirection, it is directed to the URL on the new server, so the browser does not want to leak the Origin to the new server.

Use Referer Header to determine the source domain name

According to the HTTP protocol, there is a field in the HTTP header called Referer, which records the source address of the HTTP request. For Ajax requests, images, script and other resource requests, Referer is the address of the page that initiated the request. For page jumps, Referer is the previous page address that opened the page history. So we can use the Origin section of the link in Referer to know the source domain name of the request.

This method is not foolproof, the value of Referer is provided by the browser, although there are clear requirements on the HTTP protocol, but each browser for the specific implementation of Referer may be different, there is no guarantee that the browser itself does not have security vulnerabilities. Using the method of validating Referer values is to rely on third parties (that is, browsers) for security, which is not very secure in theory. In some cases, attackers can hide or even modify their requested Referer.

In 2014, the W3C Web Application Security working Group released a draft of Referrer Policy, which specifies in detail how browsers should send Referer. Up to now, most of the new browsers have supported this draft, and we finally have the flexibility to control the Referer strategy of our website. The new version of Referrer Policy specifies five Referer strategies: No Referrer, No Referrer When Downgrade, Origin Only, Origin When Cross-origin, and Unsafe URL. The three pre-existing strategies, never, default and always, have been renamed in the new standard. Their corresponding relationship is as follows:

Policy name attribute value (new) attribute value (old) No Referrerno-ReferrerneverNo Referrer When Downgradeno-Referrer-when-downgradedefaultOrigin Only (same or strict) originoriginOrigin When Cross Origin (strict) origin-when-crossorigin-Unsafe URLunsafe-urlalways

According to the above table, you need to set the policy of Referrer Policy to same-origin, send Referer for links and references of the same origin, and the referer value is Host without Path; cross-domain access without Referer. For example, aaa.com refers to the resources of bbb.com and does not send Referer.

There are three ways to set up Referrer Policy:

Set up in CSP

Add meta tags to the header of the page

A tag adds a referrerpolicy attribute

There's a lot of this, but we know one problem: attackers can hide Referer in their own requests. If the attacker fills in his own request as follows:

Then the attack launched by this request will not carry Referer.

In addition, Referer is not or cannot be trusted under the following circumstances:

If you use _ window.location.href=url to jump to the interface under 1.IE6 and 7, you will lose Referer.

If you use window.open under 2.IE6 and 7, Referer will also be missing.

The 3.HTTPS page jumps to the HTTP page and all browsers Referer are lost.

4. When you click on Flash to get to another website, Referer's situation is messy and unreliable.

Unable to confirm the source domain name

What should I do when the Origin and referer header files do not exist? If neither Origin nor Referer exists, it is recommended to block them directly, especially if you are not using random CSRF Token (see below) as a second check.

How to block external domain requests

Through the verification of Header, we can know the source domain name of the request, which may be the local domain of the website, or a sub-domain name, or an authorized third-party domain name, or an unknown domain name that cannot be trusted.

We already know whether the requested domain name comes from an untrusted domain name. Can we prevent CSRF attacks by blocking these requests directly?

Wait a minute! When a request is a page request (such as the home page of a website) and the source is a link from a search engine (such as Baidu's search results), it will also be regarded as a suspected CSRF attack. Therefore, when judging, you need to filter out the page request. Usually, Header meets the following conditions:

Accept: text/htmlMethod: GET

But accordingly, the page request is exposed to the scope of the CSRF attack. If your site does something to the current user in the GET request of the page, the prevention will be ineffective.

For example, the following page request:

GET https://example.com/addComment?comment=XXX&dest=orderId

Note: strictly speaking, there is not necessarily a risk of CSRF attacks, but there are still many websites that often hang the main document GET request with parameters to achieve product functionality, but there is a security risk for themselves to do so.

In addition, as mentioned earlier, CSRF comes from a third-party domain name in most cases, but it does not rule out local domain origination. If an attacker has permission to post comments (including links, pictures, etc., collectively referred to as UGC) in this domain, he can launch attacks directly in this domain, in which case the same origin policy cannot achieve the protective effect.

To sum up: homology verification is a relatively simple defense method, which can prevent the vast majority of CSRF attacks. But this is not foolproof, for sites with higher security requirements or more user input, we have to take additional protection measures for key interfaces.

CSRF Token

Another feature of CSRF mentioned earlier is that attackers cannot directly steal the user's information (Cookie,Header, website content, etc.), just falsely using the information in Cookie.

The CSRF attack is successful because the server mistook the request sent by the attacker for the user's own request. Then we can require all user requests to carry a Token that CSRF attackers cannot get. By verifying whether the request carries the correct Token, the server distinguishes the normal request from the attacking request, and can also prevent CSRF attacks.

Make use of the SameSite attribute of Cookie

SameSite can be set to three values, Strict, Lax, and None.

In Strict mode, browsers completely prohibit third-party requests from carrying Cookie. For example, requesting sanyuan.com websites can only carry Cookie in the sanyuan.com domain name, but not in other websites.

In Lax mode, it's a little more relaxed, but you can only carry Cookie when the get method submits the form or the a tag sends a get request, and nothing else.

In None mode, Cookie will be sent in all contexts, that is, cross-domain transmission is allowed.

After reading this, the article "what are the interview questions for browsers" has been introduced. If you want to master the knowledge points of this article, you still need to practice and use it yourself to understand it. If you want to know more about related articles, welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.