Series — Discovering Business Logic Flaws
Act 5— Pusher in Coinbase cookie
In my previous post we witnessed how a bidding process can be abused in an online auction marketplace.
All of us are guilty of using SaaS services in this cloud era. Our systems use services like Okta for uniauth, Stripe for payments, Sendgrid for email notifications, HubSpot for customer success and Pusher for real time push based notifications.
The actors in this story are CoinBase (the popular Bitcoin wallet) and its use of Pusher to dispatch transactional notifications, directed by Amir. Like a typical SaaS vendor, a Pusher account is created by Coinbase leading to the allotment of a API SDK with an auth token. This auth token enabled the API consumer to create/view/export notification (perhaps each with a unique ID).
A normal workflow initiated by a consumer on such a platform would entail
- Consumer logs in to Coinbase portal using her/his device
- Coinbase conducts credentials and device verification
- After (2), Coinbase conducts Pusher authentication
- Upon successful authentication, Coinbase receives session information from Pusher
- Coinbase persists Pusher’s session information in it’s cookie
- Consumer is now allowed to transact
- Consumer finally logs out
This workflow was abused using the following technique
The normal process was not followed when the session was terminated and device unconfirmed
- At step 7, the Pusher session remained active despite logout.
- If two tabs were open and logout was initiated from one tab, allowing the malicious user to switch tabs and view notifications of other users.
What are these conditions that led for this flaw to be exploited?
- Storing of 3rd party vendor’s session information in cookie
- Applying necessary rigor to de-auth all active sessions with 3rd party vendors upon logout or timeout action related to a consumer.
Ironically, this is one of those types of flaws that’s all but impossible for an automated web application vulnerability scanner to find.
How can such flaws be identified and thereafter avoided?
Is there a human assisted expert system available to check your specific application in a specific business line for design flaws that can be exploited?
Yes, such a system does exist. At the series finale I will reveal how this expert system can be utilized to identify such flaws.
Until then, onto my next installment in this series.
This post is one of a seven part series on finding business logic vulnerabilities in your code. To learn more, please read the full series here:
Act 1 — What is a business logic flaw?
Act 2 — Attack like its 1999
Act 3 — The dynamic duo Andrew and Allen exploit Nordstorm with their FatWallet
Act 4 — Outbidding
Act 5 — Pusher in Coinbase cookie
Act 6 — Your data has been breached, now what?
Act 7 — One (Bug)Mac please!
