Google has silently implemented cross-site request forgery protection for Gmail authentication. The new feature comes in the form of a unique token stored in a browser cookie and checked when the login request is submitted.
Cross-site request forgery (CSRF) attacks involve tricking a browser to perform a request that was not authorized by its owner and the targeted website to accept it. In this context, CSRF exploits the inherent trust that websites have put in their clients.
In order to track logged in users and not require that they input their credentials for every action they perform, a website stores a session cookie in their browsers. This cookie is cleared when its expiration time is reached or when the user hits the sign out button.
As long as this cookie is still active, users are at risk if they visit a maliciously crafted page that silently instructs their browser to access a link defining an action on the original website. The request will be performed because the user’s session is still active.
In order to protect against such attacks, the websites can implement another layer of validation for all requests in the form of unique random tokens, which the attacker doesn’t know. CSRF vulnerabilities were discovered in various Google services, including Gmail, before and even though all of them have been patched, the authentication page was left unprotected due to concerns that a token-based implementation might break the login experience for some users.
According to The Register, a Google spokesperson confirmed that CSRF protection was added to the login pages of Gmail and other services. “The security of our users’ accounts is very important to us, and we’re always looking for ways to make improvements,” they noted.
Additional Information On CSRF:
What is Cross Site Request Forgery?
Cross Site Request Forgery (also known as XSRF, CSRF, and Cross Site Reference Forgery) works by exploiting the trust that a site has for the user. Site tasks are usually linked to specific urls (Example: http://site/stocks?buy=100&stock=ebay) allowing specific actions to be performed when requested. If a user is logged into the site and an attacker tricks their browser into making a request to one of these task urls, then the task is performed and logged as the logged in user. Typically an attacker will embed malicious HTML or JavaScript code into an email or website to request a specific ‘task url’ which executes without the users knowledge, either directly or by utilizing a Cross-site Scripting Flaw. Injection via light markup languages such as BBCode is also entirely possible. These sorts of attacks are fairly difficult to detect potentially leaving a user debating with the website/company as to whether or not the stocks bought the day before was initiated by the user after the price plummeted.
What can be done with CSRF?
Most of the functionality allowed by the website can be performed by an attacker utilizing CSRF. This could include posting content to a message board, subscribing to an online newsletter, performing stock trades, using an shopping cart, or even sending an e-card. CSRF can also be used as a vector to exploit existing Cross-site Scripting flaws in a given application. For example imagine an XSS issue on an online forum or blog, where an attacker could force the user through CSRF to post a copy of the next big website worm. An attacker could also utilize CSRF to relay an attack against a site of their choosing, as we
References:
Gmail Login Gets CSRF Protection
The Cross-Site Request Forgery (CSRF/XSRF) FAQ
