Comments on Quaji: Cross Site Identification - or - How your social n...

oh..i though it hard to do it..thanksfor this shar...

2011-05-20T06:32:28.532+03:00

oh..i though it hard to do it..thanksfor this sharing..really appreciate it

Seems like this fits under a Cross Site Request Fo...

2010-01-19T04:30:37.364+02:00

Seems like this fits under a Cross Site Request Forgery, although maybe I'm not looking closely enough.

The issue of the similarity with CSRF has also bee...

2010-01-17T14:47:10.486+02:00

The issue of the similarity with CSRF has also been raised a couple of times in the mailing lists. I've added my thoughts to this document as an appendix.
I would appreciate anyone's further comments about this.

As Luca says... In theory its still a CSRF attack....

2010-01-17T10:14:43.570+02:00

As Luca says...
In theory its still a CSRF attack...
"Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data."
(I don't know why everyone is quoting the overview description but the actual description covers exactly the points you made)

IMHO, you are focusing a lot in "what you get" rather than "how you obtain that data".
Because in order to first obtain the login information (or anything like a user id for website x) you will need to broke the Same-origin policy of "victim" browser then retrieve the information you need to do "your bad things".

OK now you will come explaining that the same-origin policy doesn't apply here because the actual request comes from the 3rd-party site were your "bad application" is being hosted so it can always access that data.
But you are not seeing the actual way you do it... you are tricking or waiting that the user/victim actually load your page that contains the _malicious request_ were you access the "site X" information via the public/developer api and send it to the "attacker site".

However even that i don't believe this is a new attack for the "Cross-site family", i see this as a new privacy issue added by the "social networks sites" public/developer apis.
But remember that previously we have referers and the css-history attacks which exposes a lot information about what the user was doing therefore this just comes in handy for knowing who is exactly visiting our website (spammers/phishers may be already using it to deliver more personalized ads/scams).

Regards
PS: Leave out the term CSID and add the terms spoofing and identity theft and then you may have good paper about "new ways to obtain users real identity"

I don't agree with the following sentence: &qu...

2010-01-15T14:05:54.494+02:00

I don't agree with the following sentence:
"It's not exactly a CSRF because the victim's browser isn't tricked into performing any action apart from visiting a page (a CSRF token won't help here)".

In my humble opinion, it is a twisted CSRF - as other guys suggested.

First of all, anti-CSRF tokens can help here (see Paul Johnston's reply in the web security mailing list).

According to OWASP, "CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated".

During normal CSRF attacks, the semantic of the action depends on the vulnerable web application. Within your attack (e.g. against Facebook), you are still abusing the same things whereas the semantic of the action (expose information) is chose by the attacker via his/her malicious Facebook app (as illustrated here: http://www.zilby.com/images/attack-anatomy.png)

Anyway, nice attack flow!
Cheers

This has already a name: CSRF.

2010-01-13T21:37:20.780+02:00

This has already a name: CSRF.

Seems like a good idea as Facebook are actually do...

2010-01-13T17:50:34.611+02:00

Seems like a good idea as Facebook are actually doing as you suggested with their "Facebook Connect" API. Doing quite well it seems.

Hey Ronen, you already know my thoughts about it.....

2009-12-30T23:11:38.844+02:00

Hey Ronen,
you already know my thoughts about it... :)

But I was thinking, and wanted to make my thoughts public - on the one hand, this IS huge, just the impact of identifying (almost) all Facebook users, considering how ubiquitous it is - Lets just consider it a majority of Internet users can be easily identified wherever they go.

Of course, that's bad...

But maybe Facebook could turn that around, and present themselves as *the* Identity Service of the Internet? Many have tried this before, all have failed... but now, I think maybe theyre already poised to turn this huge flaw into a whitehat feature? Offer it as a service, yknow kinda like an SSO for the entire Internet. Maybe even expose themselves as an OpenId provider...
What do you think? Not that *I* would like it, but on the other hand it does seem right up Facebook's alley - turning a privacy flaw into a feature :)