|Main Archive Page > Month Archives > full-disclosure-uk archives|
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.
On Sat, Jan 16, 2010 at 10:49 PM, Ronen Z <email@example.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
> 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?
> On Wed, Jan 13, 2010 at 6:45 PM, Christian Sciberras <firstname.lastname@example.org> wrote:
>> I'm confused, isn't this just like XSRF (cross-site request forgery)?
>> On Wed, Jan 13, 2010 at 4:33 PM, Ronen Z <email@example.com> wrote:
>>> 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
>>> 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:
>>> Ronen Zilberman
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/