Marketplace/API/CSRF

The Marketplace has been placed into maintenance mode. It is no longer under active development. You can read complete details here.

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
  • [dchan] - Is a hash of the assertion needed? Is this an implementation detail to make sure the assertion is the proper size for keying the algorithm?
• That hash is then used as seed for a HOTP or TOTP, a different token is sent on each request.
  • [dchan] - Should we add in some additional random / session data to prevent two identical assertions from generating the same HTOP sequence? I don't think it matters in practice since the expiration time /should/ be different for each generated assertion. The concern being if some bad implementation always set the assertion expiration time to the same e.g end of year.
• Clients will send the correct HOTP, the server will compare its token using the seed.

What to do about anonymous?

• • [dchan] - Captcha may be sufficient. The UX likely isn't ideal in this case.

Non-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

The difference between HOTP and TOTP lies in synchronization strategy. HOTP relies on the server and client maintaining counters that stay synchronized. TOTP uses time instead of a counter, and thus relies on clients and servers being synchronized in time.

Both protocols provide a way to handle desynchronization; the RFC's recommendation is to allow a resynchronization window of fixed size, beyond which repeating the authorization step would be necessary. The difference is that desynchronization in HOTP is based on number of messages the client sends that the server misses, and in TOTP is based on clock skew between client and server.

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