This is the 27th day of my participation in the August Genwen Challenge.More challenges in August

preface

Cross-site scripting is a common Web vulnerability called XSS so as not to conflict with cascading style sheet CSS.

The principle of XSS attack is that the attacker inserts malicious script code into the page. When the user browses the page, the embedded malicious code will be executed, so as to steal user information or violate the user’s security and privacy.

Although XSS attacks vary widely, they can be broadly divided into three categories: persistent, reflective, and DOM.

A persistent

Persistent XSS is also called stored XSS. As the name implies, THE XSS attack code is stored in the server database. When the server receives the corresponding request, the XSS attack code is embedded in the resource file and sent to the client as a response, thus launching the attack.

Take Ximalaya FM once XSS vulnerability as an example, when editing the album name, there is no escape filter on the album name saved to the server, if the saved album name is a paragraph with package malicious script, so when the user opens the relevant webpage, malicious code as part of the page source code is parsed and executed by the browser, the attack is achieved.

reflective

Reflective type XSS is also called the non-persistent XSS, when users click on a malicious link, submit a form or entering a malicious web site, the malicious code will be as a response is sent together with normal data returned to the victim’s browser, and deceive the browser, make mistook a malicious script from the trusted server, that allows a malicious script to execute.

The principle of

After the attacker induces the user to visit a URL with malicious code, the server side receives the data and processes it, and then sends the data with malicious code to the browser side. The browser side parses the data with XSS code, executes it as a script, and finally completes the XSS attack. This process is like a reflection. Hence the name reflective XSS.

Attack steps

  1. The attacker constructs a specialURL, which contains malicious code.
  2. The user is induced to open the code with malicious codeURL, the server sends malicious code fromURL, and then returns data with malicious code to the user.
  3. The user’s browser receives the response parsing execution, and the malicious code mixed in is executed.
  4. Malicious code steals sensitive user data and sends it to the attacker, or impersonates the user’s behavior and calls the target website interface to perform the operations specified by the attacker.

The DOM model

Dom-based XSS attacks occur entirely on the browser, independent of the server, and are likely to occur when a page needs user input to create DOM elements.

Take the current editor for example, when we use! When the []() syntax inserts an image, the editor creates an IMG element using the image URL we entered, and we can use this feature to launch DOM XSS attacks.

First build a markdown attack code:

! [img] (#" onError ="alert(' this is an XSS attack '))
Copy the code

#” onError =”alert(‘ this is an XSS attack ‘) is inserted by the editor as the image URL into the img SRC attribute. Since the attributes in the HTML are wrapped in a pair of double quotes, the resulting img tag looks like this:

<img src="#" onerror="Alert (' This is an XSS attack ')" alt="img">
Copy the code

In theory, an alert bar should pop up like this:

However, the attack is invalid because the editor escapes the URL, escaping characters such as double quotes and Angle brackets into hexadecimal code values. Therefore, escaping user input is an important means to defend against XSS attacks.

The above attack code only destroys the page structure, we can also launch more advanced attacks to steal cookies by splicing URLS to create a script tag, and since the editor is saved online, the attack code will also be stored in the server. If the server has no defense measures, once the article is published, All users browsing articles are attacked, and this becomes persistent XSS.

defense

To defend against XSS attacks, the front and back ends need to work together:

  1. The front end is in the render pageDOMYou should choose not to trust any backend data, and any fields should be escaped.
  2. The front end for immediate conversion intoDOMTo escape user input, especially rich text processing.
  3. The backend should choose not to trust any front-end data before entering the repository and uniformly escape all fields.
  4. The back end uniformly escapes the output data to the front end.
  5. Strict managementcookieThe read and write permission of thecookiethehttp-onlyProperties.

conclusion

For the front end, users’ input and input should never be trusted, and for the back end, the input of the front end should never be trusted. Otherwise, attackers can use this vulnerability to inject malicious code into the website, thereby stealing users’ cookies (session tokens) or damaging the website structure. The vast majority of XSS attacks can be protected by front – and back-end two-factor authentication.