Message-ID: <36fe92c91001161349h1119f288k3e14f54fcfee8ff@mail.gmail.com>
Date: Sat, 16 Jan 2010 23:49:00 +0200
From: Ronen Z <ronen@...ji.com>
To: Christian Sciberras <uuf6429@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Cross Site Identification (CSID) attack.
	Description and demonstration.

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