The AVANTSSAR team informed Google of the vulnerability before they publicized it, and Google has already implemented a fix, and changed their online documentation.
The flaw involves the way in which Google used SAML for single sign-on (SSO). It doesn't mean SAML itself is flawed. However, Google implemented it in such a way that if a user was granted access to a Service Provider (e.g. a Website), then that Service Provider could use the SAML Assertion (a kind of security token) to access Google applications (such as GMail) as that user. If that sounds complex, go and look at the video from the AVI link above, since the AVANTSSAR people use a concrete healthcare example which makes it simple to understand.
Now, the vulnerability involves a rogue Service Provider. And, as Kim Cameron from Microsoft points out, "The problem is that if you have a huge site like Google, which brings together many hundreds (thousands?) of services, then with this approach, if even ONE of them “goes bad”, the penetrated service can use any tokens it gets to impersonate those users at any other Google relying party service. It is a red carpet for insider attacks. "
An interesting reaction to this story, from Jackson Shaw (also from Microsoft) is that the youth of Google's SAML engineers may have contributed to the problem. He asks "Could Google's predilection for those who have just emerged from the fountain of youth have contributed to this SSO "disaster"? " He may be on to something there. The "more mature, industry (and customer) schooled professional who has been around the block more than once" (as Jackson Shaw puts it) may have thought "back during Project Athena in MIT, I remember that Kerberos was designed so that session tickets are only valid for a particular resource", and thought about whether a rogue Service Provider could impersonate the user to access different services.
Google has always published all the information about their usage of SAML, including sample code. This is good. It meant that the AVANTSSAR people were able to use this public information to analyze the Google SSO implementation. Because, believe me, there are many organizations using home-made implementations of SAML that are not publicized and which are vulnerable to replay attacks, do not used signed assertions, and (as in this case) allow assertions to be "hijacked" to impersonate a user. That is the truly scary part of this story. XML Gateway vendors can help, by ensuring that their customers are using policies which ensure that SAML assertions include the appropriate Recipient attribute in the SubjectConfirmationData element, which indicate that the SAML Assertion is in fact intended for their service (and not hijacked by another service provider).
Here is an example policy I've set up on a Vordel XML Gateway which performs a series of steps to validate and verify SAML assertions. This includes validating the signature over the SAML assertion, validating its structure, ensuring it has not expired, etc.
In the Policy Studio, if you double-click on the policy element called "Validate that the recipient specified in the SAML Assertion is appropriate", you see the configuration which is ensuring that the Service Provider mentioned in the SAML assertion is appropriate (i.e. that the SAML assertion is not a hijacked assertion which was intended for a different service provider):
