Why a safer open redirect is the best way forward for advertisers.

Masq31 - Benjamin Giordano
6 min readApr 5, 2021

--

Hello everyone. For the month of April I want to touch on a focused topic of cybersecurity related to advertising networks and partners. If you’re a curious software engineer for a marketing firm looking for what a security researcher is trying to find in your code, you’ve come to the right post.

This particular issue occurs both locally and on bug bounty programs. As the additive goes, one man’s trash is another man’s treasure. If I learned anything in my youth from the TLC show Junkyard Wars, you can make gold out of any scrap lying around. The same idea goes for data driven cyberspace.

[1]

The problem was discovered due to browsing without proper scope filtering on. (Filtering for your security program of choice is very important, so make sure you try and keep this focused as to not overshoot the scope accidentally. There can be legal consequences for failing to do so.)

In collecting data, a request went from 12 connections up to 800 in about 10 seconds. This is a lot of data to sift through. Taking the time to look at data like this is no stranger to me and my past work of copying and auditing lines of text by hand. While making a script would be useful, the potential for software bugs are hidden inside each request that a script would miss is quite high, making hand sifted data ripe for the picking.

The key piece of what I found comes from the advertising networks themselves. To describe this industry in a basic nutshell, when you visit a website an advertiser assigns an ID based off your metadata. From there, they can sell their partners a banner or text through a split second automated auction to the highest bidder. After a confirmation this ad is delivered digitally to the page, through the screen and right into to your eyeballs. A more detailed breakdown can be found through Sendpulse[2].

Some advertising agencies are hiding open redirects in the software’s logic, hardcoding features of their AI on dashboard kept under lock-and-key. A hacker with criminal intent would need a good deal of access or luck to leverage systems such as these. Unfortunately, many advertising networks have not taken this approach. Many are relying on Javascript and API based redirects to handle the handoffs. If not secured, these redirects are wide open to send a user to someone’s evil website, teeming with malicious intent.

Open redirect is an app security issue covered by the Open Web Application Security Project (OWASP) for over half a decade. Openbugbounty and other software bug bounty programs aim to empower researchers to provide intelligence to site owners on the perils of this well known vulnerability [3].

____

My mind jumped to abuse cases, how this impacts the field is not only by security, but also from clickfraud. It’s a losing game for these advertising industries. Firm Geoedge puts out a yearly report on how fake and forged identities, clickfarms, and various other techniques aim to part agencies with their money illegitimately [4].

Clickfraud is one of the biggest issue facing the internet advertising industry. Let’s not sugar coat this, clickfraud constitutes a crime if one intends maliciously abuse a system in this manner. Reports covering clickfraud paint a picture of mobile devices rigged to send bots and views, clicks and taps, to services [5]. This, I fear is only the tip of the iceberg of this problem plaguing the web based advertising industry. To secure these services, software design and patching is necessary, and awareness is key.

____

Lets look at how open redirects from advertisers might be abused by a hacker or be used in clickfraud instances. These techniques are known and have been in use for a number of years. Each of them are covered with mitigation under the current OWASP open redirects [6].

DISCLAIMER: The following section describes theory. This is all for demonstration purposes only. Do not try this without prior authorization for software testing. I DO NOT CONDONE USE OF SUCH TECHNIQUES AND SHALL TAKE ACTION TO REMOVE THIS SECTION IF I AM MADE AWARE OF ISSUES RELATED TO REPORTING ON THIS TOPIC.

Open redirect from URL, Open redirect from JS Object header. [?url=] — Some of the simplest redirects are possible through these means. The former may also be vulnerable to Javascript based Cross site scripting (XSS) injection, another OWASP top 10 issue [7]. While the latter use is arguably safer, both are questionable. The former needs to be parsed against a list of ad network partners as to not send a user to parts unknown.

Open redirect stealing keys & UID values [&UID=sEcrET-UsEr-kEy] — Somewhere down the pipeline, if a user breaks out of the stream, they can sometimes carry their script or cookie data with them. Grabbing this identifier may be enough to add another member of a theoretical click botnet army. Encryption should occur at rest, in transit, and at use with user data.

Open redirect via path traversal and bypassing content checks. [example.com/..//https://evilsite.net/?siteCheck=OK] — This one is interesting. Even if you as an advertiser think you’ve implemented the right check, bypasses are still possible with a classic dot dot slash attack (../). These can be seen on troves in disclosures posted to hackerone and other platforms. Impacts range from positioning a malicious hacker in the middle of a legitimate ad webpage to exposing content from private systems. For those afraid of a cyber boogeyman under your code, appropriate defenses might include external software testing, fuzzing via scripted tools such as fuzzdb, or a security product with the means to halt such attacks.

Open redirect bypassing, resetting or mitigating GDPR settings. [&GDPR=#OptOut] — This one is tricky as well. Occasionally a semicolon or pound symbol (;, #) may mess up some of a header’s content. While this isn’t typically a problem, if that data is protected under the EU GDPR doctrine, an advertiser may default allow data collection to occur. Defaulting to deny these requests and checking for specific flags is the way to go for better security.

Cross Site Request Forgery [redacted] — And in the case of fraud, how about winning a bid and getting a wrong redirect anyway? Where does your money go in these instances? If a script on a webpage executed maliciously or taken over by an attacker intends to interfere with this bidding process, things may go astray quickly.

There are numerous use cases which I’ve not covered here, but I hope these have shown you how software security should be in your risk analysis process.

____

Of course this topic is debated heavily in the cyber threat landscape. Google inc. made a clear stance to say open redirects aren’t an issue to the company. As one of the net’s biggest advertising agencies, such a statement is certainly worth consideration [8]. Then again, their service tends to be one of the more secure by comparison, given their approach to best practices around web software security.

Adblockers are another example. Touted by individuals, organizations and security researchers alike, these tools prevent access to ad networks via deny policy. A plugin drives the software, and the magic happens there. Use of these resources make personal privacy from ad networks attainable, and reduce the threat of the end user even seeing one of these malicious techniques tested on their PC.

And of course, there’s good software use cases by design. CSRF prevention tools, checksums, encryption, validation methods, and well placed honeypots await those who attempt to manipulate some advertiser data, making the bad guys visible and stopping attacks before they happen.

If you ask me, secure by design this would be the best of the three approaches. Is it shocking to think that advertising online should work as intended for the collective benefit of everyone? Well, I certainly believe every party here can agree on the benefits and get along with a safer, more secure ad networks. So long as amazon figures out how to stop recommending me another wallet after I’ve already ordered one.

Stay safe.

(note this blog is not affiliated with any of the links within. I make no money from links and as of right now write these monthly as a passion project.)

____

[1] https://entertainment.howstuffworks.com/junkyard-wars.htm

[2] https://sendpulse.com/support/glossary/advertising

[3] https://www.openbugbounty.org/open-bug-bounty/

[4] https://site.geoedge.com/downloads/documents/Auto_Redirects.pdf

[5]https://finance.yahoo.com/news/click-farms-internet-china-154440209.html

[6] https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/11-Client_Side_Testing/04-Testing_for_Client_Side_URL_Redirect

[7] https://owasp.org/www-project-top-ten/

[8] https://sites.google.com/site/bughunteruniversity/nonvuln/open-redirect

--

--

Masq31 - Benjamin Giordano
Masq31 - Benjamin Giordano

Written by Masq31 - Benjamin Giordano

Web security blogger, Lifelong IT learner, Community first

No responses yet