Date: Wed, 12 Dec 2007 12:01:31 -0800
From: "Andrew A" <gluttony@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Google / GMail bug, all accounts vulnerable

Actually, the suggested prevention tactic is to create a post variable in
your form of type "hidden" with a securely generated one-time ticket that an
attacker would not be able to scrape without performing an xmlhttp call,
therefore signalling a (real) security problem with the app in question.
Requiring the user to re-input their login credentials for every database
write would be absolutely ridiculous from both a design and security
perspective.

But then again, you must know all this with your extensive experience in web
app security and development.

On Dec 12, 2007 9:31 AM, Kristian Erik Hermansen <
kristian.hermansen@...il.com> wrote:

> On Dec 12, 2007 3:20 AM, ad@...poverflow.com <ad@...poverflow.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > ridiculous advisories are generating ridiculous replies that's well
> > known and you figured it out.
>
> The data is all there.  So, the trick is how to utilize CSRF to
> influence a large number of users to make requests which disrupt,
> taint, or modify their accounts on popular services.  In the example,
> I point the favicon.ico object as a 301 redirect to a GMail URI.
> Since the favicon.ico object, for some reason, influences the account
> even without revisiting the website again, the GMail account is again
> influenced any time you click a tab.  It is an interesting finding,
> and not one that I have heard ever publicly stated.  Correct me if I
> am wrong here, but why would the favicon.ico object be requested every
> time you merely click on a tab?  And does this only happen in FF, or
> IE as well?   What other browser's exhibit this behavior and/or is it
> supposed to be this way?
>
> However, in addition to all this, CSRF is getting to be more
> dangerous.  Major sites are not protecting against a wide range of
> attacks.  The suggested prevention tactic is to ask for a password
> upon any account modifications.  However, this does not always seem to
> be implemented.  Too, many requests can cause distress to a user which
> do not necessarily modify their accounts.  For instance, it is
> possible to taint the credibility of a remote user as well.  Say you
> could inject searches on Youtube for 'kiddie porn', or make Google
> requests for 'how to murder your wife'.  All of these are possible
> attacks, frightening, and how would they be prevented?  This is
> becoming a large issue, and why I wrote up the PoC for the specific
> Google / GMail case.  It is possible that these type of attacks could
> perhaps be used to incriminate someone in court based on secondary
> evidence, if they were suspected of say, murdering their wife.  The
> user's search history on Google have been subpoenaed before, and
> injecting requests into someone's search history is frightening and
> definitely needs to be addressed, don't you think?  The worst part
> about all of this is that there doesn't seem to be a viable solution
> at the moment, which is why everyone should start thinking about the
> problems now.  There are some great papers which describe a few
> methods, but one demonstrating the implications is still missing...
> --
> Kristian Erik Hermansen
> "I have no special talent. I am only passionately curious."
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists