Last week a security researcher, Randy Westergren, pointed out in a blog post a vulnerability from cross-site scripting (XSS) that was common across our industry and impacted AppNexus. We’ve since rolled out a patch to the immediate issue and encourage you to read Brian’s blogpost addressing this and publisher security in the broader context.
To begin, let’s start with hash marks ( # ), which in a URL or HTML code are called “anchors” and they serve as a placeholder in the content or application, allowing for easy navigation to preset points in the page. They’re also common in single page web applications to call new content. When a URL containing the hash mark character is requested from the website, it’s common for the entire page to be loaded normally with no reference or record of the hash mark sent to the web server.
The particular style of attack in the blogpost is called a cross-site vulnerability because it can often traverse multiple websites. In the context of ad-serving, a majority of advertisements are served from different web servers than those that serve the content of the site itself. In a technical sense, these ads are “cross-site” advertisements. If the advertisements are replaced with malicious objects, they become “cross-site scripting attacks”, or “XSS attacks”.
Bad actors who use the internet for criminal activity are often looking for ways to get their code onto a legitimate website. One way to potentially do this would be leveraging a weakness in the use of hash marks and how common adserving is done. A bad actor could create a URL such as the following and then try to get users to click to this location:
When clicked, the user would be taken to the real
example.com homepage and everything after the hash mark would not be sent to the website’s server, which would prevent server-side protections from functioning.
This approach gave us an immediate patch with minimal breakage to our current integrations.
We have rolled out this fix to truncate these special characters that may break the string being written to page.
This customization of the referrer URL will prevent this
Here’s an example that shows the change in a live environment.
The first ad on this page asks AppNexus for the referrer URL unencoded, which we modify to return a truncated version. The second ad asks for the referrer URL encoded.
Another technique to prevent this escaping is to always encode the referrer URL that’s returned. We actually offer this option to our clients today (as the second ad in the example above shows), but some clients elect to have the un-encoded version returned for certain use cases. Looking forward, we plan to fully deprecate the un-encoded version of our macro and ask that our clients and partners convert to supporting a referrer URL that’s always encoded. This change should help further drive adoption of other companies and further minimize risk to users across the Internet.