31–35 of 35 posts
So the article title could be changed to "Peach API has replay vulnerability"? I haven't actually tried this yet but can someone confirm the app has pinning? If so, thoughts on how he sniffed the original traffic and ran the replay?
[0] https://github.com/nabla-c0d3/ssl-kill-switch2 [1] http://mitmproxy.org/
Earlier quoted context omitted.
> While I agree that the tokens must be expired on logout Is there really that much additional security over deleting tokens locally when logging out, but expiring all existing tokens (using a timestamp) on password change? Blacklisting individual tokens requires storing them in the db and then looking them up each time a user logs in. It seems like given the app already uses TLS, the tiny security gain isn't big eno…
I agree although I think about it more in terms of development and maintenance effort. There's plenty of other relatively computationally and IO intensive activity happening during login so I can't see an extra select having a tangible impact to performance.
What tool does one use to inspect requests?
While 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'…
Another commenter mentioned certificate pinning, and it Peach does this, and refuses non-secure API requests, I'd agree it's overblown. It is a vulnerability, yes, but where's the exploit?
An honest query to add on: wouldn't a nonce-style expiration digest be sufficient to prevent this hypothetical reply attack from being effective once the nonce expired?