Summary
Generally, vulnerability scanning work is done by having a large database of vulnerabilities and checking them against a single host. However, picking one vulnerability and searching for indicators across many sites can be just as, if not more effective.
Methodology
While browsing Hackerone hacktivity, a stream of public vulnerability submissions by bug bounty hunters to participating companies, I found a public Reddit bounty for reflected cross site scripting, or XSS, on a URL redirect. The researcher set the URL parameter, “dest” to the payload:
javascript:alert(document.domain)
I was later able to exploit the same vulnerability on another company while manually testing.
Not wanting to stop at just one, I figured I’d search for it elsewhere, and set up a Google dork for the vulnerability. A dork is a search query, usually on Google, searching for specific attributes of a result. In this case, using “inurl” to find parameters referencing a URL was the plan. A Google search for:
inurl:”?dest=”
Returned very few relevant results. Many had Dest as the last name of an athlete, and many more had other uses of the word dest. Trying other URL redirect parameter names and filtering out unwanted results with negative searches yielded various endpoints which automatically take the browser to a page referenced in the URL, also called open redirects. Some of these redirects were only completed after an action such as a login, making automated testing much trickier than manual. The easiest way to test for an open redirect is to visit a page with a modified redirect parameter and see if the browser is redirected, but with login pages, credentials are first required. By prepending a minus (-) to a search query, Google will exclude results containing that query from the search.
Of the functioning redirects, at least three were vulnerable to replacing the destination URL with the XSS payload. Many more may have also been vulnerable, but lots of available pages were login pages, and many of those didn’t have a signup endpoint.
Impact
XSS can result in a wide variety of malicious activity, including html injection, session hijacking and cookie theft, keylogging, and even browser-based cryptocurrency mining. Any of these can impact the safety and trust of a website, and some specialized attacks can even create worms on a site or take it down. All an attacker would have to do in this scenario is convince a user to click on a company owned link.
Open redirects, while somewhat lower priority, can still diminish trust in a domain. A user may click a link, recognizing the domain associated with the business, and be redirected to objectionable content or a phishing page controlled by an attacker. They’re also a fantastic way to rickroll your friends.
Mitigation
There are multiple ways to mitigate this vulnerability. Having an open redirect can already be a security risk, so limiting the redirect to only approved sites, or creating a lookup table of keys to sites can solve the problem. As always, sanitizing all user inputs against XSS, including all URL parameters, is recommended. This means angle brackets, but also other XSS indicators like parentheses and backticks. Prebuilt sanitization functions exist in many languages and setups. Setting a restrictive Content Security Policy, or CSP, is also recommended. This means configuring your server to only allow the browser to load and execute scripts from an allowlist of trusted sources. If a script manages to make its way to the browser maliciously, it will still be blocked if it doesn’t come from an approved source in the CSP.
