Idle Tracking for Login Request Forgery
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.
COPYRIGHT_WI: Published on https://washingtonindependent.com/w/idle-tracking-for-login-request-forgery/ by William Willis on 2021-03-12T08:23:40.146Z
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.
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.
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.
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.