3 ms·

At least in OAuth 1.0a, the access token is only useful if you also know the consumer secret (provided the PLAINTEXT signature method is not in use). Of course

by sk5t 15y ago

At least in OAuth 1.0a, the access token is only useful if you also know the consumer secret (provided the PLAINTEXT signature method is not in use). Of course, the consumer secret probably isn't difficult to fish out, and besides, this 'attack' relies on the user typing his password into an untrusted device... so, yeah.

ajross 15y ago
What? It relies on the user typing his password into a personal smartphone that just happens to have a trojan app installed. How much more "trusted" can you get? Relying on users never to install malicious software is not a valid security model (as witnessed by decades of experience in the PC market), and I'm shocked that you think so.
- sk5t 15y ago
  Err... so you're okay with typing your username and password into a personal computer running software configured under another person's control? That's about as far away from "trusted" as possible. The author describes getting into other folks' FB accounts by having them log in on his own device. Not their own devices.
  - ajross 15y ago
    You've misunderstood the exploit. Logging into someone else's phone is an artifact of the test (because clearly he's not going to push a malicious app to the market!), not a requirement for the exploit. Any app with the log reading capability can do that. And any app can request that capability. As pointed out elsewhere there's a Bible app that does it.
    - sk5t 15y ago
      I follow the issue of defeating the purpose of the sandbox -- the token is sent to a log where other apps can read it, so an app that has "read sensitive log files" and "access network" rights could run amok over the user's FB. The article goes on to describe getting access to other folks' accounts, but only after convincing them to enter credentials. But there are already plenty of drawbacks to installing malicious apps on your own smartphone, and lots of reasons not to enter credentials on some random device.
      - darklajid 15y ago
        I still cannot follow your line of thought. If a user had FourSquare (or Parse) installed during the time of the vulnerability, that exploit would've worked. Maybe hidden in an obscure (partly useful? Wallpapers of a hot movie at that time?) and simple app. Although the user 'just' logged in to known apps and services on his very own device. So your argument about not entering credentials on random devices seems off to me. The one about not installing each and any application out there is correct and spot on, of course.

by sk5t 15y ago

ajross 15y ago

What? It relies on the user typing his password into a personal smartphone that just happens to have a trojan app installed. How much more "trusted" can you get? Relying on users never to install malicious software is not a valid security model (as witnessed by decades of experience in the PC market), and I'm shocked that you think so.

sk5t 15y ago
Err... so you're okay with typing your username and password into a personal computer running software configured under another person's control? That's about as far away from "trusted" as possible. The author describes getting into other folks' FB accounts by having them log in on his own device. Not their own devices.
- ajross 15y ago
  You've misunderstood the exploit. Logging into someone else's phone is an artifact of the test (because clearly he's not going to push a malicious app to the market!), not a requirement for the exploit. Any app with the log reading capability can do that. And any app can request that capability. As pointed out elsewhere there's a Bible app that does it.
  - sk5t 15y ago
    I follow the issue of defeating the purpose of the sandbox -- the token is sent to a log where other apps can read it, so an app that has "read sensitive log files" and "access network" rights could run amok over the user's FB. The article goes on to describe getting access to other folks' accounts, but only after convincing them to enter credentials. But there are already plenty of drawbacks to installing malicious apps on your own smartphone, and lots of reasons not to enter credentials on some random device.
    - darklajid 15y ago
      I still cannot follow your line of thought. If a user had FourSquare (or Parse) installed during the time of the vulnerability, that exploit would've worked. Maybe hidden in an obscure (partly useful? Wallpapers of a hot movie at that time?) and simple app. Although the user 'just' logged in to known apps and services on his very own device. So your argument about not entering credentials on random devices seems off to me. The one about not installing each and any application out there is correct and spot on, of course.