Idle Tracking for Login Request Forgery
In contrast to the U.S. Constitution which included its Bill of Rights only as an addendum in the first ten amendments, the Texas Constitution puts the Bill of Rights at the beginning in Article I.
Author:Paolo ReynaReviewer:Hajra ShannonMar 12, 2021674.8K Shares8.9M Views
Cross Site Request Forgery (CSRF / XSRF) vulnerabilities are nothing new. First allegedly documented in 2001, they’ve been around for almost 15 years now, and they aren’t going anywhere. Unfortunately, although some web frameworks (eg, Python-Django) automatically mitigate the possible issues of CSRF, many developers either are not using such a framework or opt not to use the automatic CSRF protection for various reasons.
However, despite this, as the threat is relatively well-publicized, most developers are now used to following good practices while dealing with any form of client-side form submitting data to the server. This means that it’s, hopefully, fairly rare to find CSRF exploits in user settings scripts, ‘posting’ scripts, etc.
One area which is often overlooked, however, is the simple login form.
Why Is That A Problem?
Actually, it can potentially be a pretty huge problem. And one which scales to be more problematic the more popular your website.
I’m currently writing this article near the end of 2014, a year in which the news and tech community discussion has been perpetually plagued with discussions of privacy violations, spying governments, mass-scale data collection and people generally snooping around where they shouldn’t be. It would be fantastic to presume that nobody is ever going to want to covertly collect data about you, be they government agencies, criminals or suspicious partners. Unfortunately however, that isn’t the world we live in.
Pretty much every big website out there makes an obscene amount of advertising or eCommerce revenue by collecting data about it’s users. They’re more than happy to do this while you’re browsing anonymously, but once you’re logged in, you can sure bet that all of this information is going to be tied directly to your user account.
So now that we bear that in mind, the hypothetical sarcastic developer from a few paragraphs back is now looking pretty foolish. Although it may seem original that there is little that can be compromised by leveraging a CSRF attack to log a user into your service, if you log any data about your user while they’re logged in which they can access (directly, or potentially indirectly due to Section 7 Data Protection Act 1998 or country-specific equivalents), then login request forgery vulnerabilities can allow a malicious user to massively compromise user privacy.
Is This Really A Privacy Problem?
Obviously, the amount of data obtainable will vary depending on the website with the vulnerability, but this can include everything from search queries, viewed pages and history even to include actions relating to and captured by third-party websites and applications which make use of publicly accessible services provided by the exploited web service. A login request forgery vulnerability on Google, for instance, would allow the malicious user to snoop on search queries, watched YouTube videos, location lookups and more.
This can potentially be a critical issue, especially as this monitoring would bypass snooping mitigation techniques such as end-to-end encryption – if you search something on Google using an SSL connection then it’s not possible for an adversary to easily discern what you searched, but if they have access to the Google account which has made the search then it’s as easy as browsing to the account search history.
How Common Are These Vulnerabilities?
As this does not seem an obvious vulnerability, I would suggest that it is a fairly common issue with many large web services vulnerable to passive monitoring login request forgery vulnerabilities. At the time of writing, I have recently reported a (now fixed) PMLRF vulnerability to Yahoo and another Alexa Global Top 10 web service, and I am quite sure that numerous other high traffic web properties would be vulnerable to the same form of attack.
How Can The Problem Be Mitigated?
Fortunately, the solution is simple as the attack can be mitigated using any of the techniques traditionally used to prevent CSRF such as synchronizer token patterns, CAPTCHA requirements, two-factor authentication or cookie-to-header tokens. The issue here lies not in the vulnerability being complex to patch but rather that it is hard to understand specifically why login request forgery is an issue so many developers chose not to require STP verification for login forms – occasionally even if tokens are provided by the login form.
Paolo Reyna
Author
Paolo Reyna is a writer and storyteller with a wide range of interests. He graduated from New York University with a Bachelor of Arts in Journalism and Media Studies.
Paolo enjoys writing about celebrity culture, gaming, visual arts, and events. He has a keen eye for trends in popular culture and an enthusiasm for exploring new ideas. Paolo's writing aims to inform and entertain while providing fresh perspectives on the topics that interest him most.
In his free time, he loves to travel, watch films, read books, and socialize with friends.
Hajra Shannon
Reviewer
Hajra Shannona is a highly experienced journalist with over 9 years of expertise in news writing, investigative reporting, and political analysis.
She holds a Bachelor's degree in Journalism from Columbia University and has contributed to reputable publications focusing on global affairs, human rights, and environmental sustainability.
Hajra's authoritative voice and trustworthy reporting reflect her commitment to delivering insightful news content.
Beyond journalism, she enjoys exploring new cultures through travel and pursuing outdoor photography
Latest Articles
Popular Articles