5 ms·

https://github.com/codebutler/firesheep https://github.com/codebutler/firesheep

EGreg 16y ago
no no, I don't mean stealing someone's cookie through some kind of Man-In-The-Middle attack. I mean impersonating someone else simply by logging in and then changing some javascript variables before posting to the server.
- deleted 16y ago
  [deleted]
- geovedi 16y ago
  it's possible. iff the target sites are stupid enough by not doing proper input validation and/or origin check.
  - sdsdfvsdf 16y ago
    What is meant by "target" sites? Do you mean a site that uses a third party authentication? If we need every website out there to code security checks for these third party systems, I doubt we can rely on that
    - EGreg 16y ago
      So how do these third party authentication systems protect against this pretty straightforward javascript way of circumventing the authentication? Anyone know?
- maushu 16y ago
  If the service is well implemented this should be very hard. Basically when you login you receive a session/ticket (usually by cookie), using that session you post as yourself. To post as somebody else you would need to get their session which is difficult since it expires after some time and it should very hard to guess (usually an hash with 32 characters or more). What firesheep does is steal those sessions during transaction. No guessing there.
  - EGreg 16y ago
    fine, but if I am making a third-party authentication service, how do I prevent the users of that service from being bamboozled by simple javascript? How does facebook prevent a website from being bamboozled? Is there any technique that facebook can recommend (such as signing the uid and sending the signature along with the id on all server requests) so that the website isn't fooled?
    - Swannie 16y ago
      I'm not sure I understand your question. If you mean: I have an authentication service, Auth.com, and I would like the users to be able to enter their user name and password on AnotherSite.com, how do I stop javascript on AnotherSite.com hijacking their submission to Auth.com? Then the short answer is, you can't. That is why all services redirect you to their own login page, where they control the HTML (and can audit to be sure that no one has injected code into their site). What Facebook does is usually in an iFrame, which accesses the user information relatively securely. Any interaction more complex than a "like" is generally redirected via facebook.com (e.g. any permission grants). iFrame's used to be riddled with flaws, but I believe they are considered fairly safe these days. Go educate yourself on the protection of XSS and CSRF/XSRF, and you'll be able to answer all of your own questions.
      - EGreg 16y ago
        No, that's not what I am asking. And I am very familiar with how to combat XSS and CSRF, having written a PHP framework that does it for you out of the box, among other things (http://phponpie.com http://phponpie.com) I am asking another question. If I am operating an OpenID provider, say Auth.com, and CoolStuff.com uses me to authenticate a user, then they can use that session. Great. But now let's say I operate an OAuth provider, and it releases this user's uid, first_name and last_name. What measures does facebook and other OAuth providers take to prevent the uid, first_name, last_name and other data from just being changed by the user in javascript, before being posted to the CoolStuff.com servers, after they have been obtained using Javascript ... such as FB.api('fql.query', ...)

EGreg 16y ago

no no, I don't mean stealing someone's cookie through some kind of Man-In-The-Middle attack. I mean impersonating someone else simply by logging in and then changing some javascript variables before posting to the server.

deleted 16y ago
[deleted]
geovedi 16y ago
it's possible. iff the target sites are stupid enough by not doing proper input validation and/or origin check.
- sdsdfvsdf 16y ago
  What is meant by "target" sites? Do you mean a site that uses a third party authentication? If we need every website out there to code security checks for these third party systems, I doubt we can rely on that
  - EGreg 16y ago
    So how do these third party authentication systems protect against this pretty straightforward javascript way of circumventing the authentication? Anyone know?
maushu 16y ago
If the service is well implemented this should be very hard. Basically when you login you receive a session/ticket (usually by cookie), using that session you post as yourself. To post as somebody else you would need to get their session which is difficult since it expires after some time and it should very hard to guess (usually an hash with 32 characters or more). What firesheep does is steal those sessions during transaction. No guessing there.
- EGreg 16y ago
  fine, but if I am making a third-party authentication service, how do I prevent the users of that service from being bamboozled by simple javascript? How does facebook prevent a website from being bamboozled? Is there any technique that facebook can recommend (such as signing the uid and sending the signature along with the id on all server requests) so that the website isn't fooled?
  - Swannie 16y ago
    I'm not sure I understand your question. If you mean: I have an authentication service, Auth.com, and I would like the users to be able to enter their user name and password on AnotherSite.com, how do I stop javascript on AnotherSite.com hijacking their submission to Auth.com? Then the short answer is, you can't. That is why all services redirect you to their own login page, where they control the HTML (and can audit to be sure that no one has injected code into their site). What Facebook does is usually in an iFrame, which accesses the user information relatively securely. Any interaction more complex than a "like" is generally redirected via facebook.com (e.g. any permission grants). iFrame's used to be riddled with flaws, but I believe they are considered fairly safe these days. Go educate yourself on the protection of XSS and CSRF/XSRF, and you'll be able to answer all of your own questions.
    - EGreg 16y ago
      No, that's not what I am asking. And I am very familiar with how to combat XSS and CSRF, having written a PHP framework that does it for you out of the box, among other things (http://phponpie.com http://phponpie.com) I am asking another question. If I am operating an OpenID provider, say Auth.com, and CoolStuff.com uses me to authenticate a user, then they can use that session. Great. But now let's say I operate an OAuth provider, and it releases this user's uid, first_name and last_name. What measures does facebook and other OAuth providers take to prevent the uid, first_name, last_name and other data from just being changed by the user in javascript, before being posted to the CoolStuff.com servers, after they have been obtained using Javascript ... such as FB.api('fql.query', ...)