Skip to content

Commit

Permalink
cllient and server side attacks
Browse files Browse the repository at this point in the history
  • Loading branch information
wbamberg committed Nov 7, 2024
1 parent e1de7e1 commit 16c7c39
Show file tree
Hide file tree
Showing 3 changed files with 43 additions and 2 deletions.
3 changes: 3 additions & 0 deletions files/en-us/web/security/attacks/xss/client-side-xss.svg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
39 changes: 37 additions & 2 deletions files/en-us/web/security/attacks/xss/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -128,12 +128,47 @@ For example, a website might include a blog that allows comments. Since anyone c

### DOM-based XSS

A DOM-based XSS attack happens when a website's front-end takes some input that could have been crafted by an attacker, and without sanitizing it, passes it to an API that could result in the input becoming executable. APIs like this are referred to as _sinks_.
A DOM-based XSS attack happens when a website's front-end takes some input that could have been crafted by an attacker, and without sanitizing it, passes it to an API that could result in the input becoming executable. APIs like this are referred to as _injection sinks_.

The first XSS example we saw in this page is an example of DOM-based XSS, in which the sink is the {{domxref("Element.innerHTML")}} property. Some, like `innerHTML`, modify the DOM, and can make their input executable by injecting {{htmlelement("script")}} tags, `javascript:` URLs, or inline event handlers. Others, like [`eval()`](/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval), directly execute their arguments as JavaScript.
The first XSS example we saw in this page is an example of DOM-based XSS, in which the injection sink is the {{domxref("Element.innerHTML")}} property.

Some injection sinks modify the DOM, and can make input executable by injecting {{htmlelement("script")}} tags, `javascript:` URLs, or inline event handlers. For example:

- {{domxref("Element.innerHTML")}}
- {{domxref("Element.outerHTML")}}
- {{domxref("Element.insertAdjacentHTML()")}}
- {{domxref("Document.write()")}}

Other injection sinks directly execute their arguments as JavaScript. For example:

- [`eval()`](/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval)
- {{domxref("Window.setTimeout()")}} and {{domxref("Window.setInterval()")}}

APIs provided by third-party frameworks or libraries can also contain injection sinks. For example:

- [`dangerouslySetInnerHTML()`](https://react.dev/reference/react-dom/components/common#dangerously-setting-the-inner-html) in React
- [`html()`](https://api.jquery.com/html/) in jQuery

### Client versus server XSS

Alongside the three categories described above — reflected, stored, and DOM-based XSS — is a different but overlapping taxonomy, which distinguishes attacks based on whether they take place in the server side or the client side of a website.

DOM-based XSS is always a client-side attack, but reflected and stored XSS may be either server-side or client-side, depending on the website's architecture.

For example, consider a stored XSS attack which uses blog post comments to inject malicous code.

In one architecture, the user navigates to the blog post by following a normal link. The browser makes an HTTP GET request to the server, which retrieves the blog post and comments from a database, then feeds them into a template to construct the response as an HTML document. The browser receives the HTML document containing the malicious code, and renders it.

![Diagram of server-side XSS](server-side-xss.svg)

In an alternative architecture, the website is implemented as a {{glossary("SPA", "single-page app")}}. When the user navigates to the blog post, the navigation is handled by the front-end JavaScript code. This code might get the blog post and comments from the server as JSON using the {{domxref("Window.fetch()", "fetch()")}} API, and then render them as HTML client-side.

![Diagram of client-side XSS](client-side-xss.svg)

Although the attack and the result are the same in both cases, the point at which the malicious code is introduced into the HTML document is different: in the first case, it's the server code that is failing to sanitize the blog post comments before including them in the document, and in the second case, it's the front-end code. Note that in the second case, the attack is a stored XSS attack _and_ a DOM-based attack.

The distinction between server and client XSS matters because effective defenses against XSS are different depending on where the vulnerability is.

## Defenses against XSS

### Do you need an XSS defense?
Expand Down
3 changes: 3 additions & 0 deletions files/en-us/web/security/attacks/xss/server-side-xss.svg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 16c7c39

Please sign in to comment.