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?
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