Hacking — Tamper with the URL Parameters, especially if they modify the page
Concise tip: If you run into a page with interesting URL parameters, always tamper with them and see what you can do, especially if they modify an iframe within the page. Depending on what type of integration it is you may be able to inject content into that iframe.
My report: https://hackerone.com/reports/367589
Another one to reference is https://hackerone.com/reports/298265; I have found this same vulnerability in many different programs but unfortunately none of my reports are disclosed yet.
Full story: Many websites use different third-party services throughout their sites for things such as review forms, job applications, search functionalities, and more. Sometimes these services are integrated into pages via iframes and if this is the case, the parent URL oftentimes contains parameters that modify this iframe. These can vary from stylistic modifiers to identifiers, but if they modify the iframe, there is a great opportunity to tamper with them.
That explanation is a bit vague and confusing, so let’s dive into my Starbucks report for a more specific example. In their case, they were using a PowerReviews iframe integration and when you clicked to write a review for a product, various URL parameters were appended to the parent URL that all began with “pr”, giving away that they were PowerReviews parameters. The “pr_merchant_id” parameter stood out to me in particular because every PowerReviews form has a unique merchant ID tied to the creator. By modifying this URL parameter to a different ID, I could load any PowerReviews form on a page within athome.starbucks.com.
In most of these URL parameter pollution scenarios when you can load your own content within the iframe, the impact is similar to Stored XSS. An attacker could design a phishing form on one of these services that looks like a page prompting a victim to log in, for example, and upon sending the victim that link on the trusted website they would see the phishing form prompting them for their login information. The only issue is that in many cases such as PowerReviews or Greenhouse, it requires a bit of social engineering to acquire an account to make these job/review forms. I did not perform this step because that would be illegal, but it adds a level of difficulty in execution versus XSS that may lower the impact.
Overall, URL parameter pollution into iframes, especially third-party integration iframes, can lead to content injection similar to Stored XSS and can be a serious vulnerability. Every third-party service will be different in how it operates though, so the work comes in figuring out which URL parameters can be modified and how one could inject their own content into the page.
Starbucks seems to continue to use PowerReviews on athome.starbucks.com but without iframes anymore to avoid the whole parameter situation in the first place, and Greenhouse appears to be avoid iframes entirely now (See Github’s Greenhouse job integration, for example). Thank you to the Starbucks team for helping with categorization and thank you to Hackerone for disclosing that Greenhouse vulnerability.