Understanding the nature of XSS

Notes from the Author: I design Cover Images disgusting. Yes I have no soul

For some reason, the first thing that comes to my mind when I say my vulnerability is XSS. Maybe it's because it's a security vulnerability that I first learned about, or because XSS is like a puzzle. I am writing this article because there is a very strange situation that I noticed among my fellow software developers. XSS is not taken seriously for a reason I don't know, or it is not given enough attention when it is taken seriously. I'm going to tell you a little bit of XSS technically today, but the first thing I'm going to do is talk about the nature of XSS.

Wilderness Cross-site Scripting (XSS)

In nature, XSS arises for very simple reasons. Sometimes a little filtering is skipped, sometimes too lazy to do it, sometimes it results from the fact that XSS checked in one step is not checked in another. What's wrong with XSS is that it goes undetected until the vulnerability is exploited. When it is realized, it is too late for everything, as we Turks say, "The one who took the horse passed Üsküdar".

XSS Types

Now let's get into some technical details and talk about XSS types and which type changes what.

Stored XSS

Stored XSS is when an attacker stores their malicious code in the target web application and then uses it to show it to other users.

A Stored XSS attack typically targets a form field such as a comment or message box on a forum, blog, or e-commerce site. The attacker writes malicious code to these domains and submits it. These codes are saved in the target web application's database and run when subsequent users view the page. This could include any JavaScript code that the attacker could run on any web page, so the attacker could infect users, steal their session information, or alter the page content.

For example, an attacker could target users by commenting on a forum. A window can be opened in the target users' browser by typing the following codes in the comment box:

<script>alert('Hello My name is Stored XSS')</script>

Of course, this attack script will not work in any of the modern web applications. There is a classic situation that I see in everyone who is just starting out. They may look for a magic wand about which attack script is more effective and working, or they may use some tools to discover these vulnerabilities. My advice is not to use tools. These automated tools do not improve or move you forward. Manually generate your attack codes one by one by intelligently examining your attack point. This may be difficult at first, but as you understand XSS, you will start to really enjoy it.

Lets continue. When you manage to run the script I gave above or similar, a warning window will appear on the screen saying "Hello My name is Stored XSS". Congratulations if this script is being saved on the website you have discovered your first Stored XSS.

Reflected XSS

Reflected XSS (Cross-Site Scripting) is a web vulnerability that is exploited by triggering insecure user input stored on a page on the target website, via a specially crafted link or form that an attacker sends to a website.

This type of XSS attack is performed on the search results page of user-supplied input, such as injecting a JavaScript code into a search box on the target website. The attacker sends a specially crafted link or form to the target website, and these entries are displayed on a page on the target website. While the user is viewing this page, the JavaScript code is automatically executed and performs a malicious action.

For example, an attacker could perform a Reflected XSS attack by submitting an entry like the following to a search box on the target website:

https://batuhanaydn.com/search?q=<script>alert("Reflected XSS");</script>

This entry will be displayed on the search results page and the JavaScript code will automatically run, thus displaying a malicious message to the user.

DOM XSS

DOM (Document Object Model) XSS is one of the vulnerabilities in web applications and is a subset of Cross-Site Scripting (XSS) attack. DOM XSS sends specially crafted input to the attacker's target website, causing JavaScript code to run on the page viewed by the user.

DOM XSS is similar to Reflected XSS but relies on a different mechanism. Reflected XSS attacks are performed because user inputs are displayed directly on the website, while DOM XSS attacks are performed by modifying the JavaScript code in the target website on the DOM tree.

A DOM tree is the structural representation of an HTML document and includes all elements (for example, tags, text, images, etc.) on the web page. The JavaScript code in the web page can access the DOM tree and modify or manipulate these elements. Using this feature, attackers perform DOM XSS attacks to modify the JavaScript code on the target website.

For example, an attacker might submit an entry like the following to a form field on the target website:

<input type="text" id="input">
<button onclick="updateText()">Update Text</button>

<script>
function updateText() {
  var input = document.getElementById("input").value;
  document.getElementById("output").innerHTML = input;
}
</script>

This code will take the text the user entered and update the content of an HTML element named "output". However, if the attacker sends the following code as input:

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

This entry will cause a DOM XSS vulnerability on the target website because it does not properly close the JavaScript code. Thus, by controlling the user's input, the attacker can modify the JavaScript code on the target website and perform a malicious operation.

XSSi (Cross-Site Script Inclusion)

Yes, let's come to XSSi, which is one of the most fun and effective security holes in my opinion, which some people have never heard of and some of us are not very familiar with.

XSSI can allow attackers to use JavaScript files (usually in JSON data) from the target website to run malicious JavaScript code in the browsers of target website users.

XSSI attacks target requests to a JSON service on the target website. This service is generally used to facilitate data interaction in the web application. The target website sends JSON data to clients while allowing JavaScript codes on that data to be run. Therefore, attackers can send a specially crafted request to the target website's JSON service, using JavaScript codes from the target website to cause malicious code to run in the target users' browsers.

For example, a JSON service on the target website might look like this:

https://example.com/api/data.json?id=1234

This service sends data to clients in JSON format using the "id=1234" parameter. To target this service, attackers can send a request like:

https://example.com/api/data.json?id=1234&callback=myfunction

This request is used to call back a JavaScript function named "myfunction". The target website sends a JSON response to the client like this:

myfunction({"data": "1234"});

An attacker can insert malicious JavaScript codes into the "data" field in this JSON response:

myfunction({"data": "<script>alert('XSS')</script>"});

This JSON response will bypass the browser's firewall, causing malicious JavaScript codes to run in the target user's browser.

How to protect from XSS

Since there are thousands of code examples that can be produced for these, I will list the items that need attention instead of giving code examples here:

Input validation and data validation: All input fields and data points need to be validated. This verifies that all data sent to the server is valid and in expected formats.

Output encoding and filtering: All user input must be properly filtered or encoded before being processed. This ensures safe handling of special characters in data from users.

Secure HTTP headers: HTTP headers can be used to protect against XSS attacks. For example, the "X-XSS-Protection" header can enable XSS protection in browsers.

Security of cookies: Cookies are a common target for XSS attacks. Therefore, the "HttpOnly" and "Secure" features should be used for the security of cookies.

Secure coding practices: Secure coding practices are among the most important preventers of XSS attacks. Regular code reviews should be done to ensure coding is secure, data validation is done correctly, and to eliminate unsafe code.

Safe browser settings: Browsers' secure settings can be used to protect users from XSS attacks. These settings can prevent the use of JavaScript, ActiveX, and other potentially dangerous features.

When you implement them correctly, you will be protected by 90 percent of XSS vulnerabilities. Remember, there is no such thing as 100 percent security. Happy Hacking