Date: Sun, 17 Jan 2010 00:07:55 +0100
From: Christian Sciberras <uuf6429@...il.com>
To: Ronen Z <ronen@...ji.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Cross Site Identification (CSID) attack.
	Description and demonstration.

Sounds like "automated" vs "manual" approach. But in the end, I think
they are interchangeable. You can do an automated XSID via writing GET
from inside an iframe/image.
It may be correct by OWASP definition, but it's the same end result -
a request sent from a different sender then expected, whether
automated or not.
In my humble opinion, all these definitions complicate security (and
we all know security<complexity).
My 2 cents.

Regards,
Christian Sciberras.

On Sat, Jan 16, 2010 at 10:49 PM, Ronen Z <ronen@...ji.com> wrote:
> Hi Chris,
>
> I feel that while the two are similar, they are not the same.
> CSRF by OWASP definition is "...an attack which forces an end user to
> execute unwanted actions on a web application in which he/she is
> currently authenticated."
> In contrast, the exploits described in the paper require the end user
> to merely *view* a page on the vulnerable website. No action is taking
> place.
>
> An action in my mind, is a two-step process: First the user requests
> the pre-action page, which contains the action button (and usually a
> form too). The click on the button preforms the action and sends the
> user to the post-action page.
> CSRF is thus a way to skip the pre-action page, and send the user
> directly to the post-action page. (Via an email link, hidden iframe,
> image etc).
>
> CSRF prevention is done with CSRF tokens: unique "challenge" tokens
> that are added as hidden values to the form in the pre-action page.
> When the form is submitted, the token is verified. Because the token's
> value is unknown in advance, construction of a malicious, direct
> post-action URL is not possible. While this method stops CSRF, it will
> not help with CSID.
>
> In all the examples given (and in the general case), the victim's
> information that is being uncovered is added to the first landing page
> (the pre-action page). No action is forged. Consider for example
> Orkut's "Recently Visited" feature. How would you use  CSRF tokens (or
> anything else for that matter) to prevent it being used for CSID (i.e
> clandestinely sending the victim's browser to visit the attacker's
> profile), and still retain the current functionality (allowing direct
> URL to users' profiles)?
>
> I also considered my first find a CSRF, but thinking more about the
> general case of this attack I thought it might actually be it's own
> attack type.
>
> What do you think?
>
> Ronen
>
>
> On Wed, Jan 13, 2010 at 6:45 PM, Christian Sciberras <uuf6429@...il.com> wrote:
>> I'm confused, isn't this just like XSRF (cross-site request forgery)?
>>
>> Regards,
>> Chris.
>>
>>
>> On Wed, Jan 13, 2010 at 4:33 PM, Ronen Z <ronen@...ji.com> wrote:
>>> Hi,
>>>
>>> A new type of vulnerability is described in which publicly available
>>> information from social network sites obtained out of context, can be used
>>> to identify a user in cases where anonymity is taken for granted.
>>>
>>> This attack (dubbed Cross Site Identification, or CSID) assumes the
>>> following scenario: A user that is currently logged on to her social network
>>> account visits a 3rd party site, supposedly anonymously, in another browser
>>> tab. The 3rd party site causes her browser to contact the social network
>>> site and exploit the vulnerability resulting in her identity being disclosed
>>> to the attacker. The 3rd party target site is not necessarily controlled by
>>> the attacker. It could also be, for example, any site allowing user provided
>>> content that includes an image link (basically any forum or blog site).
>>> Other possibilities exist.
>>>
>>> While the information that is received by the attacker is technically
>>> publicly available, obtaining it in this manner effectively lifts the veil
>>> of anonymity from the user when interacting with the 3rd party site.
>>>
>>> Three social networks were tested and all were found to contain the
>>> vulnerability. These are Facebook, Orkut and Bebo. Some of the
>>> vulnerabilities were design flaws. The vulnerabilities are described and
>>> demonstrated. The sites were contacted in advance yet some of the
>>> vulnerabilities are still open.
>>>
>>> CSID is not bound only to social network sites but might be found on any
>>> site that authenticates its users. Various flavors of the attack are
>>> discussed.
>>>
>>>
>>> The post below contains a detailed description of the attack and its
>>> implications. It also includes details about the live vulnerabilities found.
>>>
>>> Post/White Paper:
>>> http://blog.quaji.com/2009/12/out-of-context-information-disclosure.html
>>>
>>>
>>>
>>>
>>> Ronen Zilberman
>>> http://quaji.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>
>>
>

_______________________________________________
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