CSRF, XSS science popularization and defense

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

CSRF The attack just borrowed Cookie, Can't get Cookie Information in , So we can't get Cookie Medium token, You can't send a request in POST perhaps GET Set in token, When sending a request to the server ,token Verification failed , Then the request will not be processed .

  Case presentation ：

The user login http://127.0.0.1:9000 Website , Enter the user name and password to log in to a website , The server records the login of the user cookie Save to browser , At this time, the login status of the user is logged in

Since then, each interface request under the website domain name will carry cookie（ After receiving the request, the interface considers that the user has logged in ）

At this time, the user calls the interface to realize transfer ：

After the user completes the transfer , Did not log out in time （cookie There is still user login status in ）,

At this time, a phishing website induces users to visit ： The phishing website has a picture ( Wisely , Width and height are 0, At this time, the user can't see at all ), The image src The path is the transfer interface address ,

When the phishing website is loaded , It is equivalent to calling the transfer interface ：（ Because the domain name cookie For logged in , I brought this... With me when I asked cookie To the server , Transfer interface call succeeded ！）

If it is POST Submit Form , You can do this ：

User identification is the use of cookie, Then the way to pretend to be a user is to visit other pages under a domain name , The browser will carry cookie This feature .

Defensive thinking ：

1. Distinguish whether the request comes from your front-end page or a third-party website
2. Make your front-end page request different from the third-party forged request

Solution ：

• Use as much as possible POST, Limit GET

GET Interfaces are too easy to make  CSRF attack , Just look at the example above , Just construct a  img label , and  img Tags are unfilterable data . Interfaces are best limited to  POST Use , GET It doesn't work , Reduce the risk of attack .

Of course  POST It's not foolproof , The attacker just constructs a  form Can , But it needs to be done on the third party page , This increases the likelihood of exposure .

• take cookie Set to HttpOnly

CRSF The attacks are largely browser based  cookie, In order to prevent  XSS Loopholes steal  cookie, Need to be in  cookie Set in  “HttpOnly” attribute , So go through the process ( Such as  JavaScript Script 、 Applet etc. ) Can't read it  cookie Information , Avoid forgery by attackers  cookie The situation of .

stay  Java Of  Servlet Of API Set in  cookie by  HttpOnly The code for ：response.setHeader("Set-Cookie","cookiename=cookievalue;HttpOnly");

• increase Token

CSRF The attack was successful , It's because an attacker can fake a user's request , All user authentication information in the request exists in  cookie in , So the attacker can directly use the user's  cookie To pass security verification . Thus we can see that , To resist  CSRF The key to the attack is ： Put information in the request that the attacker can't forge , And the letter never existed in  cookie In . In view of this , The system developer can be in  HTTP Was added a request in the form of randomly generated parameter  token, And on the server  token check , If not in the request  token perhaps  token The content is not correct , Think it is  CSRF Attack and reject the request .

• adopt Referer distinguish

according to  HTTP agreement , stay  HTTP There is a field in the header called  Referer, It records the time to  HTTP The source address of the request . In general , All requests to access a restricted page come from the same website . For example, the transfer of a bank is through user access  http://www.xxx.com/transfer.do Page completed , Users must log in first  www.xxx.com, Then click the submit button on the page to trigger the transfer event . When a user submits a request , Of the transfer request  Referer The value would be The page where the submit button is located  URL.

If the attacker wants to execute on the bank website  CSRF attack , He can only construct requests on other websites , When a user sends a request to the bank through another website , The requested  Referer The value of is the address of other websites , Not the address of the bank transfer page . therefore , Be defensive  CSRF attack , The bank website only needs to verify each transfer request  Referer value , If so  www.xx.om Address at the beginning of the domain name , It means that the request is from the bank's website , It's legal. ; If  Referer It's another website , It could be  CSRF attack , Then reject the request .

XSS （Cross-Site Scripting） Cross-site scripting attacks

utilize xss, Hackers can forge user login , So as to pretend to be a user 、 Brush Click 、 Play the advertisement 、 Spread worms and so on . According to the type, it can be divided into reflection type and storage type .

reflective XSS：

 

Storage type XSS:

  

Case presentation ：

The user enters information in the browser ：

Server side html Form returns part of the input ：

If injected script label ：

  After successful submission , The server still returns script label , This constitutes XSS attack ：

Solution ：

1. WAF Rule library code （Web Application Firewall , Web Application firewall , To guard against SQL Inject ,XSS etc. ）