List of articles

• CSRF attack
  • #1 What is? CSRF attack
  • #2 Cookie
  • #3 The same source strategy for browsers
  • #3 How to avoid the front and back end separation project CSRF attack
  • • #3.1 Defense one --- Verification Code
    • #3.2 Defense two --- HTTP Referer
    • #3.3 Defense three --- TOKEN

CSRF attack

#1 What is? CSRF attack

CSRF Cross-site request forgery (Cross—Site Request Forgery)

The attacker stole your identity (TOKEN or Cookie Etc ), Send a request to the server in your name , This request is perfectly legal to the server , But it does what the attacker wants , And you don't know , for example : Send email in your name , Transfer and other operations

CSRF The attack process :

1. user Tom Open the browser , visit https://weibo.com/, Enter your account and password to log in to Weibo
2. Microblog background verification account password passed , Will return a Cookie, Save to browser , At this time, the user login successfully , And be able to send requests like Weibo
3. When the user doesn't have to log out of the microblog , Open another website A, Website A After receiving the user's request , Return some offensive code , And send a request to visit Weibo
4. After the browser receives the attack code , According to the website A Request , Without the user's knowledge , carry Cookie Send a request to Weibo , For Weibo backstage , This request is perfectly legal , So according to the user Tom Of Cookie Information to Tom Permission to process the request , Lead from website A The malicious code was executed .

CSRF Attack instance :

Xiaoming uses the browser to log in to the bank website , The back office of the bank will return a Cookie Coexist in the browser of Xiaoming computer , In this Cookie Before the expiration date , Xiao Ming clicks on the pop-up advertisement in the browser , Now jump to another website A, Website A There's a piece of malicious code , The code content is : Send a transfer request to the bank's back office ( carry Cookie), At this time , Tragedy struck , This url The request is answered , Money will be transferred from Xiaoming's account to the attacker's account , Xiao Ming didn't know about it at that time , Later, Xiaoming found that the account money was less , Even if he went to the bank to check the log , He can only find that there is indeed a legitimate request from himself to transfer funds , There is no trace of being attacked .

#2 Cookie

natural CSRF attack , The request sent by the attack will be carried automatically by default Cookie

For one Http POST request http://xxx.minhung.me/ooooo/create-msg Come on

If the following conditions are satisfied ：

• On the browser side Cookie Of domain Field equals xxx.minhung.me perhaps minhung.me
• All are http perhaps https, Or in different situations Secure The attribute is false
• The path to send the request , Above http://xxx.minhung.me/ooooo/create-msg Of ooooo With the browser side Cookie Of path Attributes must be consistent , Or browser side Cookie Of path A subdirectory , For example, the browser side Cookie Of path by /test, that ooooo It has to be for /test perhaps /test/xxxx Wait for a subdirectory to

above 3 Two conditions must be satisfied at the same time , Otherwise Post The request can't automatically bring the existing browser side Cookie

Because in CSRF In attack , It's about setting up Cookie The server interface of , So it will be carried automatically when you visit Cookie

#3 The same source strategy for browsers

The same source strategy for browsers , In general, there are three limitations ：

• One is from one source js You can only read and write the storage of your own source, but not the storage of other sources , Storage includes Cookie、Session Storage、Local Storage、Cache、Indexed DB etc. .
• The second is from one source js You can only read and write from your own source DOM Trees cannot read from other sources DOM Trees . That is, if we start talking about ,iframe If the inner and outer layers are not homologous, they can't operate with each other , If the outer layer wants to get the content of the inner layer, it can only be used with click hijacking ; The principle of implementation is also unknown as mentioned above .
• Third, generally speaking, it comes from one source js You can only send requests to the interface of your own source, not to the interface of other sources . Of course, the essence is , On the one hand, the browser finds a source of js When sending a request to an interface of another source, it will automatically bring Origin The header identifies the source from , Let the server pass through Origin Judge whether to respond to ; On the other hand , If the browser does not find Access-Control-Allow-Origin The domain that sends the request is allowed to request, and that does not allow parsing . I've complained about it before , It's not that the server doesn't respond, the server doesn't respond, the browser doesn't （ allow js） Is it meaningless to analyze ; Now it seems , Write by yourself python And so on, they can actually request other servers and parse their results , The browser doesn't have Access-Control-Allow-Origin One is to maintain the idea of homology strategy, the other is to ensure that it will not appear in yourself A Fields can be detected at will B The case of the domain , So it can't be said that it's totally useless .
• Fourth, it comes from one source js Can't operate resources outside the browser at will . For example, open a command prompt 、 Execute system commands and so on . If you visit a website, the website's js You can directly call system commands to add users to your computer , That's a big problem .

Under the same origin strategy of browser , Other sites js Can't read and write other sites Cookie、Session Storage、Local Storage、Cache、Indexed DB

#3 How to avoid the front and back end separation project CSRF attack

Defense plan :

• User operation restrictions , For example, verification code
• Request source restriction , For example, restrictions HTTP Referer To complete the operation
• token Authentication mechanism , For example, add a token, Verify the validity of the request when responding to it

#3.1 Defense one — Verification Code

When sending a request , Verification code is needed to verify whether it is the user himself , The user experience is significantly affected by the sub scheme , And there are additional development costs

#3.2 Defense two — HTTP Referer

The cost of the second scheme is the lowest , But there is no guarantee that 100% Security , And it's likely to be buried

Referer yes HTTP request header Part of , When browser （ Or simulate browser behavior ） towards web When the server sends the request , The header contains Referer . For example, I am in www.google.com There's one in it www.baidu.com link , So click on this www.baidu.com , its header There's... In the message ：

Referer=http://www.google.com

therefore , Put this http After the request is sent to the server , If the server requires that it must be an address or several addresses to access , And you sent referer It doesn't meet his requirements , Will intercept or jump to the address he asked for , And then visit through this address .

#3.3 Defense three — TOKEN

After the user logs in successfully , The server generates a user name and some key data Token, take Token Package to Cookie in , Then send it to the client , Every time a client sends a request , First get Cookie Medium Token, And then carry it with you Token Access server