Editor's Note: Today's post is from Phillip Pham. Phillip is a Security Engineer at APT Security Solutions. In this post, Phillip walks through a cross-site scripting vulnerability he identified in the Fry's web application.
At the time of writing, the stated vulnerability has already been remediated by Fry's Electronics. Thank you for taking swift action!
Fry's Electronics is a consumer electronic retail chain that has presence in various regions across the country. Fry's Electronics introduced a marketing concept to promote sales and track consumers' spending habits by providing personalized "Promo Code". These codes once presented at either online and/or local store will provide shoppers additional discounts to their electronic goods.
Consumers are contacted by Fry's Electronics marketing "bot" periodically via emails which include the aforementioned promo code (as seen in screenshot below). To view full list of discounted products, consumers are required to click on the provided link (example below) with promo code attached as a data parameter which is part of the URL.
Promotional product listing URLs
This URL is hosted by a Limelight Networks, who is a Content Delivery Network (CDN) vendor.
When viewing advertising materials on a mobile device.
Because Fry's Electronics marketing web site exposes the promo code via an unfiltered data parameter, "promocode", thus creates an attack vector for XSS exploitation.
To confirm the Cross-Site Scripting vulnerability, a malicious payload was appended to the end of the promotion code parameter as follows:
Immediately, a popup displayed as shown in screenshot below and the vulnerability was confirmed:
Lets take a look at the offending code:
Do you see any problems here? The "promocode" value, which is partially validated on line 3, is written to the browser using the raw .html method on line 7:
As previously mentioned, XSS allows malicious actors to conduct phishing campaigns to lure their victims to provide personal information. With given context, the phishing campaign proof-of-concept built to trick the users to provide their personal cell phone numbers to further widen attack surface to infect consumer mobile devices leverage exploits (e.g. Stagefright (Android) or an iOS 0-day).
Although, simple exploitation (alert popup) of the vulnerability requires very minimal effort. However, such exploitation does not allow a full delivery of the stated phishing campaign to the victims, thus diminishing the success rate. Upon further research and analysis of the web application HTML source code, in order to fully deliver the payload, the following series of events must take place:
- Allow legitimate content to be completely loaded
- Deliver externally hosted payload
- Victims are required to provide cell phone number before able to dismiss such dialog (via floating DIV)
Evasion #1: Regular Expression Bypass
The regular expression above tests for numeric values of the first 7 characters which can be easily bypassed as trailing characters (starting at 8th position) will not be validated. Hence, the payload executed during our Initial Test.
Evasion #2: The equal sign (=) breaks trailing payloads
The application obtains the name and value of the promo code data parameter via the "getUrlParameter" (snippet below).
With current script implementation, given the payload:
The trailing external URL will be nullified because the script detected the equal (=) sign and treated as another set of parameter/value pair. Thus yields the output:
To defeat this logic, the payload must not contain the equal (=) sign.
Evasion #3: The Working Payload
Upon further review, the application employs Google JQuery technologies to dynamically render contents. Furthermore, JQuery allows loading of external script (acting as src) via its .getScript(?url') method which does not require an equal sign (=). Example of using JQuery to reference external scripts below.
Putting it altogether
Once evasions had been fully deployed, the remaining payload is trivial, thus the following payload will allow rendering of phishing content as shown below.
As you can see from the screenshot below, the form is injected into the page and asks the user for their phone number:
Then, pressing submit results in the the phone number being sent to the evil site:
As we have seen many times before, XSS vulnerabilities can be fixed using a combination of output encoding and input validation. Some simple mitigations are as follows:
- This a classic DOM-based XSS vulnerability. OWASP provides a DOM-based XSS Prevention Cheat Sheet for fixing this. Short story - using an encoding library (e.g. jQuery Encoder) to HTML encode the promo code before writing it to the page
- Fix the validation routine to check the entire input value
For more information on defending applications, check out the awesome courses available in SANS Application Security curriculum.
About the Author
Phillip Pham is a security engineer with a strong passion for Information Security. Phillip has worked in various sectors and for organizations of various sizes, ranging from small start-ups to Fortune 500 companies. Prior to transitioning into an Information Security career, Phillip spent ten years in software engineering. His last five years of Information Security experience have been focused on Application Security. Some of his application security assessment strengths (both onpremise and cloudbased) include web applications, web services, APIs, Windows client applications, and mobile applications. He currently holds a GCIH certification and is cofounder of APT Security Solutions. Follow Phillip on Twitter @philaptsec.