Marketplace/API/CSRF
CSRF
The Marketplace (and AMO) in 2012 had a standard flow for CSRF protection. Client GETs the page from the server. Page includes a CSRF token which is tied to the users session on the server. Client POSTs a form with a CSRF token in it, we check the two match and process the request.
However, The Marketplace is being re-written as a packaged app. This means that there may never be that original get to the server to request a CSRF token in the form. The user will browse the app and POST a comment or the rating to the API and never send a CSRF token. How do we prevent abuse of these APIs? This might not matter as much for ratings and comments, but will when the API is extended to include reviewer tools, management tools and so on.
OTP
One suggestion is OTP: http://tools.ietf.org/html/rfc6238
Persona clients
- When persona authentication is performed both the client and server keep a hash of the assertion
- That hash is then used as seed for a HOTP or TOTP, a different token is sent on each request.
- Clients will send the correct HOTP, the server will compare its token using the seed.
What to do about anonymous?
None persona clients
(e.g. Python servers)
- Can use a hash of the oAuth token for its seed, since we'll assume they'll have to use oAuth anyway.
- That hash is then used as seed for a HOTP or TOTP, a different token is sent on each request.
- Clients will send the correct HOTP, the server will compare its token using the seed.
Assume no anonymous access.
HOTP or TOTP
To do.
Different security zones
We also have to realise that different APIs might have different security requirements. As mentioned comments and ratings are of lower concern than reviewer and admin APIs. Perhaps we need to have a set of zones or rules to evaluate APIs and ensure that different APIs have different requirements. For example:
- DRAFT**
| API | Auth | OTP | CORs |
| Comments | No | Yes | Yes |
| Reviewing | Yes | Yes | No |