Circumventing Chrome and Firefox's Third-Party Cookie Block
by Armando Pantoja
Many web browsers, including Chrome and Firefox, make a strict distinction between first- party and third-party cookies.
First-party cookies are created by the web server identified by the address shown in the browser's address bar. Third-party cookies are created when content is loaded from domains other than the one shown in the address bar, by <iframe>, for example.
By default, these websites will not allow third-party cookies, even if you have specifically allowed them in your settings, without you first visiting the originating site. This means clicking an inbound link or typing the URL in your address bar. This allows you to "opt in" to receiving cookies.
This policy is meant to increase security, but much like most "pseudo security" engagements, this can be easily circumvented.
I ran across this issue while developing an ASP.NET application for a client that required us to create a separate widget that would be installed on an existing WordPress site.
This widget was basically an <iframe> that showed a form from the ASP.NET application that we created. Our client needed the widget to integrate into this existing site, and allow the user to input a username and password, and forward them to the application that we had written in .NET seamlessly.
ASP.NET form authentication writes a token cookie to validate each user, and during testing we found that Chrome and Firefox were blocking this cookie from being written, resulting in errors that would not let the user login to the application.
By default both Chrome and Firefox have a setting that blocks and allows first- and third-party cookies.
By default, first-party cookies are allowed, and third-party cookies are blocked. This was a huge issue because both of those browsers make up a significant percentage of the marketplace. At this point we had two options:
1.) Start from scratch and recreate the application to handle the third-party issue.
2.) Find a way to circumvent the third-party issue.
Of course, we choose the second option.
The most surprising, and actually scary, thing about the solution was that we figured it out in less than ten minutes. It was very simple.
After a user logged in, we created server-side logic to test to see if the cookie was written.
If indeed the cookie was not written, we redirected the parent page to the secondary URL by using JavaScript:
window.top.location.href = "http://www.ourwebapplication.com/noCookies.html"; |
Once the secondary page was loaded, we used a <meta> tag refresh to redirect back to the original login page on the primary site, to create an instant client-side redirect:
<html> <head> <meta http-equiv="refresh" content="0;URL='http://LoginPage.com/'" /> </head> </html> |
Using this redirect scheme, the third-party cookie opt-in was completely satisfied as the browser now sees the user has visited the secondary URL and the user is then allowed to login, and the cookie is allowed to be written.
From the user side, they simply see the page they are on refresh, as the redirect happens faster than they can perceive it.
The reason this has been implemented is not for real security, but simply a marketing scheme to win the "browser wars" by casting themselves as a more secure option.
This was easily circumvented with a little bit of thought and creativity.
This type of "pseudo security" only hurts and slows down those doing real work, and does nothing to stop hackers or malicious attacks.
