XSS and CSRF

As shown in the preceding example, we still need to take the east and west websites written in notepad slowly, although all of them belong to low-end texts.
 
 
These can be found everywhere on the Internet, but I think it is still necessary to understand your own language, so it may be wrong to understand it.
 
0X01 same-origin policy
 
The same-origin policy does not need to be discussed. Here we only mention a concept related to CSRF and XSS:
 
The same-origin policy only prevents scripts from reading content from other sites and blocking responses to requests. However, it does not prevent scripts from sending requests to other sites.
 
The request content is equivalent to a soul, no body, and the site is equivalent to a house.
 
The door of the house (same-origin policy) will not reject the entry of the soul (the soul can penetrate the wall), and will reject the entry of others (javascript in other domains) who are not in this house.
 
Therefore, the owner (Program) in the house turns a blind eye to the soul, or is invisible. And ignore naughty requests.
 
0X02 why XSS?
 
Many articles on the Internet directly talk about the types of XSS, how to use XSS, and how to discover XSS. It seems that I didn't explain why XSS is used (maybe I have not widely read it), so I will summarize it myself.
 
Someone will ask: Save type XSS aside don't talk about, why use reflected type XSS and DOM-BASE XSS, so troublesome, it is better to attack A site, store a piece of malicious JavaScript code directly on Site B controlled by the attacker and send a link directly pointing to this script to the user?
 
Cause 1: disguise. The attacker sends a url starting with site A, instead of a url starting with site B.
 
For example: A: the site is: http://www.bkjia.com/
 
Site B: http://www.bkjia.com/
 
So you construct URL: http://www.bkjia.com/hello. asp? Message = http://www.bkjia.com/edrop. js/* http://www.bkjia.com/edrop. js scripts for other domains */
 
Than directly constructing a URL: The http://www.bkjia.com/edevil. js is sent to the user, making it easier for the user to click.
 
Even more, the URL after the message can also be encoded, which will confuse users. This type is more used for phishing.
 
Cause 2: The second and most important point is that, due to the restriction of the same source policy, the browser will not execute the script or return the data that the attacker wants if XSS is not used.
 
The XSS was successful because the attacker's malicious JS was committed by http://www.bkjia.com/hello. asp.
 
The browser mistakenly thought it was submitted by www.2cto.com.
 
As a result, the browser will execute the malicious script of http://www.bkjia.com/edevil. js.
 
In the following scenarios:
 
Site A is equivalent to the manufacturing plant of the Blue Army (non-aggressive), site B is equivalent to the base area of the green army (aggressive)
 
At a time, the green army dispatched agents (malicious js) to the manufacturing plant to steal confidential information, but the blue army's manufacturing factory door (same-origin policy) was closed and the agents could not cross (because it was not a request ),
 
However, after a superior dress-up technique (XSS), the agent pretended to be a member of the manufacturing factory, so the door opened to the agent (bypass same-origin policy) and then the agent achieved the goal.
 
0X03 CSRF and XSS
 
At the beginning, I had a misunderstanding that CSRF was a one-time service and would not cause worm. Later I realized that I was naive, but CSRF should be one-way.
 
If CSRF succeeds, the user must log on to the target site and browse the site controlled by the attacker.
 
The most different from XSS is that CSRF can achieve the goal without JS (the difference between GET and POST ).
 
In addition, the attacker only needs to send a request to the target site to succeed. As stated in 0X01, requests can bypass the same-source policy.
 
Another natural condition is the security defect of the browser:
 
When the Cookie function was initially added, the browser did not consider the security factor. Assume that a website uses cookies. After a user completes authentication, the browser obtains a Cookie that identifies the user, as long as the user does not exit or close the browser. When you access a page under the same website in the future, the browser will intelligently attach the Cookie of the website to identify itself for each request, users can be recognized by the website without re-authentication. When a third-party WEB page initiates a request pointing to the current website domain, the request also carries the Cookie of the current website. This authentication method is called implicit authentication.
 
In addition to Cookie authentication, other Web Authentication mechanisms also face the same problems. For example, after the user passes the basic HTTP authentication. The browser will still intelligently append the user name and password to the requests sent by a third party to the site. Even if the website uses Secure Sockets (SSL) to encrypt the connection, the browser automatically intelligently adds the SSL authentication information to the requests sent to the website by a third party.
 
Therefore, a third-party request is equivalent to a non-physical soul. Although a third-party request can enter the house, it can only flow around without any action.
 
However, when the soul encounters an automatically attached body (cookie), it will become a complete person, who has passed the House authentication and is part of the house.
 
Once the soul is resurrected, it begins to leak its nature and execute malicious behaviors. Although it can only be in the House, it is enough to cause chaos. (For example, adding an administrator or posting a fraudulent status ).
 
It is a CSRF that has been published by Renren to use the Page code. The CSRF of Renren should not be uncommon. It will happen almost every time you engage in an activity.
 
 
 
The figure shows that the CSRF code can be executed on a third-party site, so even if there is an input check,
 
CSRF can be bypassed in the same way. Therefore, if an application has an XSS vulnerability, a CSRF vulnerability may occur,
 
However, an application does not have the XSS vulnerability and does not have the CSRF vulnerability.
 
0X04 Summary
 
We won't talk about how to prevent XSS and CSRF, but the attack has been done, but the leakage has not been done,
 
There are detailed methods on the materials. If you have any, try again.