This is the 19th day of my participation in the August Wenwen Challenge.More challenges in August

What is an XSS attack

“XSS stands for Cross Site Scripting. To differentiate it from CSS, it’s called XSS for short, which translates to” cross-site Scripting.” An XSS attack is a malicious attacker that injects malicious scripts into HTML files or DOM. When a user browses the page, Script code embedded in the Web will be executed to attack the user.”

In the beginning, this attack was implemented across domains, hence the name “cross-domain scripting.” Nowadays, there are more and more ways to inject malicious code into HTML files, so cross-domain injection of scripts is not the only method of injection, but the name XSS is still used today.

When a page is injected with malicious JavaScript, the browser cannot distinguish between malicious JavaScript and normal page content, so the maliciously injected JavaScript also has all script permissions. Let’s take a look at what a malicious JavaScript script can do if it’s injected into a page

  • Cookie information can be stolen. Malicious JavaScript can obtain cookie information through “document.cookie” and send the data to the malicious server using XMLHttpRequest or Fetch plus CORS. Once the malicious server gets hold of the user’s Cookie information, it can simulate the user’s login on other computers and perform operations such as transferring money.
  • You can listen for user behavior. Malicious JavaScript can use the “addEventListener” interface to listen for keyboard events, such as credit card information entered by the user, and send it to a malicious server. With that information, hackers can do a lot of illegal things.
  • The DOM can be modified to forge a fake login window to trick users into entering information such as user names and passwords.
  • You can also generate floating window ads within the page, which can seriously affect the user experience.

In addition to these cases, malicious scripts can do many other things that I won’t cover here. In short, if we insert malicious scripts into our pages, we are exposing our private data and behavior to hackers.

How is an XSS attack implemented

Reflective XSS

The principle of reflective XSS is as follows: reflective XSS generally means that the attacker lures the victim to visit a URL containing malicious code in a specific way. When the victim clicks on a malicious link URL, the malicious code is executed directly in the browser on the victim’s host.

Reflective XSS can also be called non-persistent XSS. Why is it called reflective XSS? That’s because the injected code for this attack is reflected back from the target server through error messages, search results, etc. Why is it called non-persistent XSS? That’s because it’s a one-time attack.

For example, an attacker sends a malicious link containing an injection script to the victim via email. When the victim clicks on the link, the injection script is transmitted to the target server, which then “reflects” the injection script to the victim’s browser, which then executes the script.

Therefore, the attack steps of reflective XSS are as follows:

  1. The attacker adds malicious attack code to the parameter after the URL.
  2. When a user opens a URL with malicious code, the web server takes the malicious code out of the URL, splices it into HTML and returns it to the browser.
  3. The user’s browser parses the response and the malicious code is also executed.
  4. Attackers use malicious code to steal user data and send it to the attacker’s website. Attackers will obtain information such as cookies, and then use the information to pretend to be legitimate users, call the target website interface to perform attacks and other operations.

Type stored XSS

The principle of stored XSS is that the malicious code is uploaded or stored on the server and executed the next time the victim browses a page containing the malicious code.

For example, I now create a blog site, and an attacker publishes an article on it, which reads as follows: ) If I do nothing with the article and save it to the database, the next time another user accesses the article, the server reads it from the database and responds to the client, the browser executes the script, and the attacker gets the user’s cookie. The cookie is then sent to the attacker’s server.

Therefore, the steps of storage XSS attack are as follows:

  1. The attacker submits malicious code to the target website database.
  2. When a user opens a target site, the site server pulls the malicious code out of the database, splices it into HTML and returns it to the browser.
  3. When the user’s browser receives the response and parses it, the malicious code is also executed.
  4. 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 gets the

Cookie will then impersonate the user’s behavior, call the target website interface and other illegal operations.

DOM – -based XSS

Our client JS can dynamically operate the page DOM node, such as inserting and modifying the content of the page. For example, the client extracts the data from the URL and executes it locally. If the data entered by the user on the client contains malicious JS scripts, but these scripts are not filtered, then our application is vulnerable to DOM-based XSS attacks. Therefore, the steps of DOM XSS attack are as follows:

  1. An attacker constructs a special URL that may contain malicious code.
  2. The user opens a URL with malicious code.
  3. The user browser parses the response and executes it. The front end uses JS to fetch malicious code from the URL and execute it.
  4. When executed, malicious code steals user data and sends it to the attacker’s website, which then takes the data and impersonates the user. Invoke the target web site interface

Perform some of the attacker’s actions.

DOM XSS is XSS based on the Document Object Model. Generally, DOM operations are as follows:

  1. Use Document.write to output the data directly.
  2. Output the data directly using innerHTML.
  3. Use location, location.href, location.replace, iframe.src, document.referer, window.name, etc.

SQL injection

SQL injection is the execution of malicious SQL statements by injecting SQL commands into an application database through client input. What does that mean? Let’s take an example: we have a login box and we need to enter a username and password, right, and then our password is ‘or ‘123’ = ‘123’ something like that.

Select * from user where username = “and password =” select * from user where username = “and password =”. SQL statement like this, now we enter the password like this, then we concatenate the parameters, the concatenate SQL statement is like this: select * from user where username = ” and password = ‘ ‘ or ‘123’ = ‘123 ‘; If either one of these is true, then the condition is true, so 123 = 123. So validation is skipped. This is just a simple example, like a password like this: ‘; drop table user; In this case, the SQL command becomes:

select * from user where username = ” and password = ”; drop table user; Delete the user table.

The SQL statement is attacked because it forges parameters and then concatenates the parameters to form an XSS attack SQL statement. Eventually, the database will be attacked.

How do I prevent XSS attacks

Cookie security policies use the HttpOnly attribute

Since many XSS attacks are designed to steal cookies, we can also secure our cookies by using the HttpOnly attribute.

Usually the server can set some cookies to the HttpOnly flag, which is set by the server through the HTTP response header, which is shown below when Google is opened

set-cookie: NID=189=M8q2FtWbsR8RlcldPVt7qkrqR38LmFY9jUxkKo3-4Bi6Qu_ocNOat7nkYZUTzolHjFnwBw0izgsATSI7TZyiiiaV94qGh-BzEYsNVa7TZmjAYTxYTOM9L_- 0CN9ipL6cXi8l6-z41asXtm2uEwcOC5oh9djkffOMhWqQrlnCtOI; expires=Sat,18-Apr-2020 06:52:22 GMT; path=/; domain=.google.com; HttpOnly
Copy the code

As you can see, the set-cookie attribute value ends up marking the cookie with HttpOnly. As the name implies, cookies that use the HttpOnly tag can only be used during an HTTP request, so they cannot be read by JavaScript.

The server filters or transcodes the input script

In both reflective and stored XSS attacks, we can transcode some key characters on the server side, such as the most typical:

code:<script>alert('You've been attacked by XSS')</script>
Copy the code

This code is filtered, leaving only: code

Thus, when the user requests the page again, the script cannot be executed on the client side because the contents of the

In addition to filtering, the server can transcode this content

X – XSS – Protection Settings

This property is currently protected by XSS by default on all major browsers. This parameter is set in the response header to defend against XSS attacks. It has the following configurations: Values: 0 by default: XSS protection is disabled. 1: enable XSS protection. 1; mode=block; Enable XSS protection and stop rendering the page when an XSS attack is detected.