1393851 - [lift] Existence of Private Collections Leaked Via HTTP Status Code

Status: RESOLVED WONTFIX

(addons.mozilla.org :: Security, defect)

Description

[u600423]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36

Steps to reproduce:

## Overview:
It is possible to determine the existence of a private collection based on the HTTP status code that is returned. 

TODO: We should talk about this and see if there are any other areas of the application in which we should try and leak existence of things.
- maybe abuse reports for a specific user or add-on?

Steps to reproduce:
1. Create a collection with Account A
2. Copy the URL to view collection
3. Logout of Account A and log back in with Account B
4. As Account B visit the URL of the collection

Collection exists but user does not have access
![](https://cldup.com/wEoRQY41T0.png)

If you change the collection URL to a collection that does not exist the response changes.
![](https://cldup.com/c6mTWkhf9j-3000x3000.png)

## Recommendations:
We recommend returning a 404 response for private collections, whether the collection exists or not.

Comment 1

[Andrew Williamson [:eviljeff]]

The existing collection pages above are being replaced with pages on addons-frontend, that are retrieved via the API.  Though the API would return the same status codes, afaik.  Private collections are being deprecated along the way, but existing collections will stay private for now.  cc'ing jorge to decide if we need to worry about exposing private collections in the meantime.

Comment 2

[Jorge Villalobos [:jorgev] (he/him)]

I don't think this is worth worrying about before the new front-end lands. But maybe this should be filed as a front-end bug to make sure we show the 404 in both cases?

Comment 3

[Andrew Williamson [:eviljeff]]

Hmm, but private collections aren't staying around long term - you dropped the property in favour of random slugs in the PRD.  We just re-implemented it in the API for now because it was a complicated migration process for existing private collections and didn't want to block on it.  Does a deprecated feature need to be fully secured?

Comment 4

[Jorge Villalobos [:jorgev] (he/him)]

It doesn't need to be fully secured, but I'm not sure for how long we'll keep the old private collections, and I think it wouldn't be too hard to show the right error message in the new front-end. If I'm wrong about that, then we can just drop it and maintain the bug until we drop all private collections.

Comment 5

[Stuart Colville [:muffinresearch]]

Adding Kumar to CC for this one to make sure we don't leak the presence of private collections via status code in the new frontend as it's implemented there.

Comment 6

[Kumar McMillan [:kumar]]

> ...make sure we don't leak the presence of private collections via status code in the new frontend as it's implemented there.

We are not implementing private collections: https://docs.google.com/document/d/1DutmS8yco-hNiKJ1-0MrkAkze7Ue88xpA4b-MWx6MLI/edit

So I guess this bug is just about fixing the API.

Comment 7

[Stuart Colville [:muffinresearch]]

> So I guess this bug is just about fixing the API.

Yes good point, it wouldn't make sense to special case something in the frontend if the API is always revealing the presence of private collections via status code. 

Whilst we're not implementing the option of private collections they will still need to be available to collection owners until we offer some kind of one-directional migration.

Comment 8

[Stuart Colville [:muffinresearch]]

Wont-fixing on the basis this is considered a minor issue.