Hacker News Reader

Comment by jdnier | Hacker News Reader

I see an interesting application for the Validity, Expiry, Enforcement, Fingerprint sections.

Many web apps generate HTML forms but submit form values via an API endpoint. With browser web tools and standard options like "copy-as-curl", it's very easy to run a "replay attack", where an adversary submits the form manually once, does a copy-as-curl (or similar) on that POST, then replays the POST repeatedly, updating particular values in the generated curl output for each subsequent POST.

This gets around form protections like captcha and allows for rapid abuse via the API that backs the form. Enforcing that an idempotency key/token be generated on the server side or that it match the submitted content or be valid for a short timespan could make replay attacks less convenient.

View on HN

This is not related to replay. This is just a rate limiting issue. Throwing arbitrary auth mechanisms between the server and the client like that just means they need to make more requests per fulfilled request.

The client is authorised to make the request – it would only be a replay attack if the client were not authorised to make the request and that limitation was bypassed by capturing and then replaying it.

if you can replay the same captcha challenge over and over your captcha is broken.

With that scheme, I imagine the server would need to maintain a per-client timestamp of when a token was last generated for them, so as not to generate them too often.

But at that point, why not use that timestamp directly, to rate-limit each client's form submissions? What's the benefit of also issuing tokens? (Do you mean to thwart copy-as-curl script kiddies? Parsing a token out of a previous message to add it to a new one is a pretty low bar.)

> Do you mean to thwart copy-as-curl script kiddies?

Yes, that's what I had in mind.

Is this protection not already baked into the CSRF token?

That and also, most captcha I've used so far require a server-side validation that is not replayable with Curl (as the token has been used during the first submission).

Yes, but captcha is on the form. I'm thinking more about a single-page app that submits form data via an API. That API call can generally be replayed.

No, a CSRF token only introduces information that is not part of the ambient authority of the HTTP client (i.e. an attacker cannot implicitly use it) – it is not uncommon to have deterministic or relatively constant CSRF tokens (e.g. the double-send cookie method). An n-once would fulfil your criteria but is importantly not a valid CSRF token unless it is also correlated or derived from something the attacker can’t know like a session; otherwise the attacker can use their own n-once to submit a victim request.

Reply on news.ycombinator.com