With the advancement in technology and the current pandemic situation, the world has shifted to remote work on a large scale. Cybercriminals have become more active and come with more sophisticated ways to attack. The security risk at many organizations has increased since employees have started working from their home networks and personal machines.

Cross-site scripting (XSS) vulnerability is one of the most popular high-risk web application vulnerabilities. In this article, we will discuss the potential risks of XSS attack and how to scan vulnerable sites using XSStrike tool, we will also see ways to prevent it. But let’s first understand what XSS vulnerability is, and how does it work.

What is Cross-Site Scripting (XSS)

Cross-site scripting, often abbreviated as XSS, is a web security vulnerability that lets hackers inject malicious JavaScript code into a vulnerable website. XSS attacks are different from other web attacks, such as SQL injection. It does not attack the web app itself, but the users of that application are at risk. 

Cross-site scripting is basically a client-side code injection attack in which hackers execute malicious scripts in the browser of victims by adding malicious code in web applications. The actual attack happens when a user visits the website that executes malicious code. The malicious site becomes a source to deliver malicious code to the victim’s browser. The vulnerable source commonly used for XSS attacks are web pages that allow user input, such as comments, message boards, and forums.

How XSS Works

To carry out an XSS attack, a hacker injects malicious code into user-provided data. They can also attack by changing a request. If a website is vulnerable to cross-site scripting vulnerability, the user-provided inputs run as code. There are several ways to stimulate an XSS attack. For example, the execution can trigger automatically when a user reloads a page or hovers over a particular element of the page, such as hyperlinks.

Here are two stages of a common XSS attack:

  1. To execute a malicious script in the victim’s browser, the hacker must find ways to inject malicious code into the website that a victim visits.
  2. Once the web page gets malicious, the user must visit it. When the attack is directed at specific victims, the hacker can use phishing or social engineering to send malicious links to the victim.

Types of XSS Attacks

Cross-site Scripting attacks are divided into three types:

  • Reflected XSS (non-persistent)
  • Stored XSS (persistent)
  • DOM-based XSS (Document Object Model)

Some other categories exist as well, but they are not seen much. These include

  • XSSI
  • Flash-based XSS

Here we’ll discuss the common cross-site scripting attacks.

Reflected XSS

Reflected XSS attacks occur when hackers store the payload in the data sent from the browser to the server. The most common example of reflected  XSS is a search form, where users send their search queries to the server and see the result. Hackers send custom links to victims that direct them to a vulnerable page or site.

Stored XSS

Stored XSS attacks occur when hackers save their payload on a compromised server. It causes web applications to deliver the malicious script to other visitors. This method just requires an initial action from the hackers and then compromises a lot of visitors. Stored XSS is the most common but most dangerous type of cross-site scripting. An example of stored XSS attacks is the profile fields, such as email or username, saved on the server and displayed on your account page.

DOM-Based XSS

DOM-based XSS attacks occur when the server with JavaScript on the web page is vulnerable to XSS. This attack is different from persistent and reflected cross-site scripting, as in that the web app does not serve the malicious code directly to the victim’s browser. For example, DOM-based attacks occur when the site changes the language from default to the one provided in the link. DOM-based attacks show that XSS vulnerabilities are not restricted to the server-side.

Impacts of XSS

When a website is vulnerable, a lot of issues can emerge. Here are some possible impacts of cross-site scripting attacks:

  • Hackers steal sensitive information of users and impersonate them.
  • Upload malicious ‘Trojan horse’ programs.
  • Modify website content.
  • Redirect web pages to harmful websites.

A successful XSS attack can have devastating impacts on a business’s reputation. Depending on the attack’s severity, user accounts may get compromised, misleading users into willingly providing their sensitive data.

Scanning with XSStrike Tool

In this section, we’ll be using XSStrike tool that is made with Python to scan toy vulnerable website.

To get started with the tool, we need to first clone the repository:

$ git clone https://github.com/s0md3v/XSStrike

After that, let’s change directory to the repository and install the dependencies of this tool:

$ cd XSStrike
$ pip3 install -r requirements.txt

After everything is installed, you can get started with the tool. In order to get all available parameters of this tool, you can use the --help or -h for that:

$ python3 xsstrike.py -h
        XSStrike v3.1.4
usage: xsstrike.py [-h] [-u TARGET] [--data PARAMDATA] [-e ENCODE] [--fuzzer] [--update] [--timeout TIMEOUT] [--proxy]
                   [--params] [--crawl] [--json] [--path] [--seeds ARGS_SEEDS] [-f ARGS_FILE] [-l LEVEL]
                   [--headers [ADD_HEADERS]] [-t THREADCOUNT] [-d DELAY] [--skip] [--skip-dom] [--blind]
                   [--console-log-level {DEBUG,INFO,RUN,GOOD,WARNING,ERROR,CRITICAL,VULN}]
                   [--file-log-level {DEBUG,INFO,RUN,GOOD,WARNING,ERROR,CRITICAL,VULN}] [--log-file LOG_FILE]

optional arguments:
  -h, --help            show this help message and exit
  -u TARGET, --url TARGET
                        url
  --data PARAMDATA      post data
  -e ENCODE, --encode ENCODE
                        encode payloads
  --fuzzer              fuzzer
  --update              update
  --timeout TIMEOUT     timeout
  --proxy               use prox(y|ies)
  --params              find params
  --crawl               crawl
  --json                treat post data as json
  --path                inject payloads in the path
  --seeds ARGS_SEEDS    load crawling seeds from a file
  -f ARGS_FILE, --file ARGS_FILE
                        load payloads from a file
  -l LEVEL, --level LEVEL
                        level of crawling
  --headers [ADD_HEADERS]
                        add headers
  -t THREADCOUNT, --threads THREADCOUNT
                        number of threads
  -d DELAY, --delay DELAY
                        delay between requests
  --skip                don't ask to continue
  --skip-dom            skip dom checking
  --blind               inject blind XSS payload while crawling
  --console-log-level {DEBUG,INFO,RUN,GOOD,WARNING,ERROR,CRITICAL,VULN}
                        Console logging level
  --file-log-level {DEBUG,INFO,RUN,GOOD,WARNING,ERROR,CRITICAL,VULN}
                        File logging level
  --log-file LOG_FILE   Name of the file to log

A lot of parameters, and will let you explore most of them by your self, now let’s scan this vulnerable toy site:

$ python3 xsstrike.py -u https://xss-game.appspot.com/level1/frame?query=
        XSStrike v3.1.4
[~] Checking for DOM vulnerabilities
[+] WAF Status: Offline
[!] Testing parameter: query
[!] Reflections found: 1
[~] Analysing reflections
[~] Generating payloads
[!] Payloads generated: 3071
------------------------------------------------------------
[+] Payload: <dEtaiLs%09OnTogGle%0d=%0d[8].find(confirm)>
[!] Efficiency: 91
[!] Confidence: 10
------------------------------------------------------------
[+] Payload: <a%09onpOiNtEreNter%09=%09confirm()>v3dm0s
[!] Efficiency: 92
[!] Confidence: 10
------------------------------------------------------------
[+] Payload: <a%0dOnpoinTeRenTer%0a=%0a(confirm)()%0dx>v3dm0s
[!] Efficiency: 93
[!] Confidence: 10
[~] Progress: 54/3071

As you can see in the output, XSStrike generated 3071 payloads for this URL for testing them out, it will take few minutes to finish.

So far, in the output I shared, 54 payloads were tested and 3 of them are successful (hence, the site is vulnerable), you can manually try the payload in the form in that vulnerable site to see it.

XSStrike generates custom payloads for each URL, and scans for them. Besides that, in the above example we used one URL for scanning, but you can also use XSStrike to crawl the site by using --crawl parameter and specify crawling depth using --level parameter (default is 2).

You can also use the --headers parameter to include request headers, such as User-Agent, Accept-Language, and others.

In our example, we used GET requests in the form, but you can also use POST data parameters using the --data argument:

$ python3 xsstrike.py -u "http://example.com/search.php" --data "q=query"

You can use XSStrike to scan for blind, reflected and DOM XSS, WAF detection and evasion is also supported, and much more. I suggest you to explore more about it, check the GitHub repository for detailed information.

Preventing XSS Attacks

Attackers use a lot of methods to exploit web application vulnerabilities. Preventing XSS attacks is not an easy task. However, there are certain protective measures that you should follow to keep your website safe from these attacks:

  • Allow list values: Limit the user input to a certain allowlist. It will ensure that only safe and known values are sent to the server. But this will only work when you know what data you will receive, such as the content of a drop-down menu. It will not work for custom user content.
  • Use encoding: Use appropriate encoding/escaping techniques based on where user input is going to use, such as HTML escape, CSS escape, JavaScript escape, URL escape, etc. Always use existing libraries, do not write your own unless necessary.
  • Sanitize Values: When a web page is using user-generated content, make sure it won’t catch potentially harmful user-provided data. You can’t encode/escape the user input if it needs to contain HTML because it will break valid tags.
  • Set the HTTPOnly flag: Set the HTTPOnly flag for cookies to reduce the consequences of an XSS vulnerability. By doing so, these cookies will not be accessible through client-side JavaScript. 
  • Keep your employees aware: To keep your website safe, everyone involved in developing the web application should be aware of the risks associated with cross-site scripting attacks. Provide security training to all developers, DevOps, QA staff, and system admins.

Conclusion

Cross-site scripting is a versatile attack that opens the door for many client-side attacks and social engineering. It can be used to seize sensitive information, such as user credentials, session tokens, or commercially valuable data.

While Cross-site scripting attacks continue to become popular and successful, thoughtful design and a bit of more testing can keep your web application from being vulnerable.

For organizations, XSS attacks have significant implications from a legal, reputational, and financial point-of-view. By taking precautionary measures, you can keep your users protected from these attacks.

Learn also: Scanning Websites for SQL Injection Vulnerability using SQLMap

Happy Hacking ♥