Learn why first party cookies can be read by third parties and how cross site scripting can be a security risk in that scenario.
Episode #9-29 released on March 3, 2019
Here is some context, I am a web developer, in fact, the TQA Weekly web-site is completely built by me in my own free time. I am always trying to build out web-sites that balance user functionality, security and, of course, provide me with the details I need to know to figure out which topics are most important to people going to my own sites.
Now, last year GDPR was made a requirement by law for anyone providing content to the EU, and only recently was I able to reliably obtain the statistics I needed, keep my advertising that generates revenue and provide services users would like. The thing is, I couldn't do this until I learned how to use Google Tag Manager properly.
Google Tag Manager is a really powerful tool that allows me to deploy code on my web-sites without constantly having to edit them all the time. I get to have a multitude of variables that are used to determine how my site is going to react under various circumstances. And, that is besides how all the other tools I use work at the same time, too. Like for example, for anyone who has ever used Google Adsense, you might be aware that you can run experiments to see if specific circumstances work better than others. I have found that auto ads of various types make my sites look horrible, so you may see the advertisements change a lot. I'm even working on specific placements because in the past those have worked better than automatic advertising. The issue is certain advertisements are not GDPR compliant by default. So, I end up having to edit the code to comply, but when the user does consent, I can move over to normal advertisement code.
The issue is when the user consents and how Google Tag Manager knows that. Now, while I doubt that Google is recording the results of all cookies on every users' computer, it is certainly able to read them, specifically cookies that are not given the httponly designation. If the httponly designation is not set to true, then any script on a page can read the cookie and send it back to another server. Optionally, there is a secure designation, that should, also, be enabled to prevent leaking information of non-secure http connections.
Now, this is not a bug, but merely a feature, I know, seems scary, but this is where web-site developers have to take notice. I coded the sessions controller of my own web-sites to require secure and httponly by default. The Silktide cookie consent bar doesn't use those designations, and this is why Google Tag Manager and any other web-site could read the contents of that particular cookie, just by being present on the page, and that means if some could inject code into the page, then malicious code could grab the content of unsecured cookies.
Is there a solution? Yes, there is. Cookie consent tools don't need to be protected in the same way, but by locking the more sensitive session cookies, and any other cookie containing personally identifiable information to httponly, you prevent any malicious set of code from using cross site scripting to grab the contents of the cookie. It is, also, important for anyone to make sure that their web-site is hard coded against that particular attack vector. Generally speaking, if you are coding your own web-site from the ground up, and nothing of what the user enters into the page or forms is ever shown on the screen, then you are generally safe, but make sure you are up to par by using cross site scripting testing tools just in case.
This is merely a warning to all users to push developers to make the proper adjustments to their code to prevent cross site scripting attacks from being able to extract the contents of unsecured first party cookies.
Host : Steve Smith | Music : | Editor : Steve Smith | Producer : Zed Axis Dot Net