Loading HuntDB...

WAF bypass via double encoded non standard ASCII chars permitted a reflected XSS on response page not found pages - (629745 bypass)

Low
S
Starbucks
Submitted None

Team Summary

Official summary from Starbucks

laszaro uncovered a bypass for report 629745 whereby the range of hex values %80-%FF was breaking the WAF filter which had not been accounted for in the original report. @laszaro — thank you for reporting this vulnerability and confirming the resolution.

Reported by laszaro

Vulnerability Details

Technical details and impact analysis

Cross-site Scripting (XSS) - Reflected
**Summary:** Report [629745](https://hackerone.com/reports/629745) not properly resolved: "Many Starbucks websites are vulnerable to cross-site scripting on 404 pages because double quotes lack sanitizing in hidden input tags, which leads to JavaScript execution". **Description:** Report 629745 caught my attention, so I began testing the WAF to see if I could find any other issues. After a while I found out that the previously reported issue was not properly resolved as I was able to bypass the double encoding filter. The original payload on the report was something like this: ``` https://www.starbucks.com.br/testing%2522%2520accesskey='x'%2520onclick='confirm%601%60' ``` and it got resolved. But you can bypass the filter with this: ``` https://www.starbucks.com.br/testing%2522%80%2520accesskey='x'%2520onclick='confirm%601%60' ``` Notice the `%80` between `%2522` and `%2520`. In fact, you can replace the `%80` with any hex value __beyond `%7f`__ and the payload still works (there's a couple of exceptions throwing "Bad Request" errors: `%81`, `%8d`, `%8f`, `%90`, and `%9d`), but values in the range `%00-%7f` get properly filtered out (throwing custom "Server Error" pages and 404 pages, 301 and 302 redirect pages, and default 400 Bad Request errors, depending on the value) So, this payload works: ``` https://www.starbucks.com.br/testing%2522%FF%2520accesskey='x'%2520onclick='confirm%601%60' ``` but this one doesn't: ``` https://www.starbucks.com.br/testing%2522%7F%2520accesskey='x'%2520onclick='confirm%601%60' ``` There is a similar behaviour if you put the double-hex digit first. This payload breaks the filter: ``` https://www.starbucks.com.br/testing%80%2522%2520accesskey='x'%2520onclick='confirm%601%60' ``` but this one doesn't: ``` https://www.starbucks.com.br/testing%7F%2522%2520accesskey='x'%2520onclick='confirm%601%60' ``` **Platform(s) Affected:** Firefox 69.0.3 ## Steps To Reproduce: 1. Visit this link on Firefox: ``` https://www.starbucks.com.br/testing%2522%80%2520accesskey='x'%2520onclick='confirm%601%60' ``` 2. Press CONTROL+ALT+X on Mac, or ALT+SHIFT+X on Windows ## Recommendations for fix The range of hex values `%80-%FF` is breaking the WAF filter, those values need to be filtered out just like the range `%00-%7F` is being filtered out. ## Impact As the original report said: "JavaScript is against Starbucks users on multiple critical domains. JavaScript execution results in information theft and an attacker can perform unwanted actions on a victim's behalf".

Report Details

Additional information and metadata

State

Closed

Substate

Resolved

Submitted

Weakness

Cross-site Scripting (XSS) - Reflected