<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1919858758278392&amp;ev=PageView&amp;noscript=1">

Business Logic Flaws: Pusher in a Coinbase Cookie

Jun 10, 2019 10:00:00 AM By Chetan Conikee

cookie pusher

Editor's note: This is the fifth article in a seven-part series by Chetan Conikee.

 

In my previous post we witnessed how a bidding process can be abused in an online auction marketplace.

All of us use 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

  1. Consumer logs in to Coinbase portal using her/his device
  2. Coinbase conducts credentials and device verification
  3. After (2), Coinbase conducts Pusher authentication
  4. Upon successful authentication, Coinbase receives session information from Pusher
  5. Coinbase persists Pusher’s session information in it’s cookie
  6. Consumer is now allowed to transact
  7. 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

  1. At step 7, the Pusher session remained active despite logout.
  2. 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?

  1. Storing of 3rd party vendor’s session information in cookie
  2. Applying necessary rigor to de-auth all active sessions with 3rd party vendors upon logout or timeout action related to a consumer.

This is another type of flaw that’s all but impossible for an automated web application vulnerability scanner to find.