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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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/
