What tool does one use to inspect requests?
Peach App Token Reuse Flaw
11–20 of 35 posts
Re: Peach App Token Reuse Flaw
#12What tool does one use to inspect requests?
Charles proxy is pretty good https://www.charlesproxy.com
Re: Peach App Token Reuse Flaw
#13Re: Peach App Token Reuse Flaw
#14Complete aside: I tried changing the text size and the site dynamically restored the text size to their preference.
Highly annoying!
Re: Peach App Token Reuse Flaw
#15Am I misunderstanding something, or wouldn't this just be solved if they simply used SSL for all communications?
The official Peach app uses SSL and they also do certificate pinning in the requests, that's not a problem. The problem is that Peach's server side authorisation token does not expire when you 'log out' and you can reuse the token.
The issue is mainly got to do with third party apps + this flaw in Peach's API. There is already one[0] which has reversed the Peach API, and the flaw is still present. What happens when another third-party Peach app comes out and does not use SSL, you can still use Peach's API without SSL and it does not default to HTTPS.
This sort of flaw would lead to a similar issue to the Snapsaved leak[1].
[0] http://techcrunch.com/2016/01/14/peach-gets-an-unofficial-we...
[1] http://techcrunch.com/2014/10/13/snapsaved-takes-responsibil...
Re: Peach App Token Reuse Flaw
#16Earlier quoted context omitted.
Charles proxy is pretty good https://www.charlesproxy.com
Fantastic. Is this the defacto tool? Can this be done without a tool?
On windows? Try fiddler: http://www.telerik.com/fiddler
Re: Peach App Token Reuse Flaw
#17While I agree that the tokens must be expired on logout, it's hard to gain access to the token via MITM because the API requests are performed over TLS [0]! This point seems glossed over in the post. You would need access to a client app directly to be able to inspect its storage or sniff the traffic yourself to determine the token being used. Access to an unencrypted client device is usually game over for most apps'…
Sounds like a storm in a teacup if indeed the endpoint is served over TLS.
Well, no. Rather it's a threat vs vulnerability case.
There exists a vulnerability, because the Peach tokens (seemingly) never expire, and thus are vulnerable to replay attacks.
However, because authorization uses TLS, it's very unlikely it will be exploited, because TLS mitigates MITM attacks.
Re: Peach App Token Reuse Flaw
#18Complete aside: I tried changing the text size and the site dynamically restored the text size to their preference. Highly annoying!
Indeed! I can't even read it without resizing my browser window.
Re: Peach App Token Reuse Flaw
#19I get that non-expiring tokens are a Bad Idea™, but it's complete bullshit that this is a groundbreaking security flaw. Any service that uses Bearer tokens for request authorization is "vulnerable" under these terms -- regardless of whether or not tokens are invalidated on "logout." What's to say a malicious MITM isn't going to hijack your account while you're still logged in?
Secure infrastructure isn't the one and only solution, but it certainly means that "vulnerabilities" like this are pointless unless your malicious attacker either has the remote server certs or has cracked TLS.
Re: Peach App Token Reuse Flaw
#20So thoughts on an actual solution? Invalidating tokens means you have to maintain an infinite growing list of invalidated tokens and perform a lookup on every login - somewhat defeating the purpose of 'stateless' tokens like JWTs (ie why not just implement a traditional session store then).
Furthermore, if sniping someone's token like this was doable over MITM, what's to prevent someone from grabbing a live token and then infinitely refreshing it (provided there's a /refresh endpoint).
I'm really wondering if anyone has best practices around this because I have not seen anything.