search

duo-labs / webauthn.io

The source code for webauthn.io, a demonstration of WebAuthn.
https://webauthn.io
BSD 3-Clause "New" or "Revised" License
647 stars 120 forks source link

Replay attack vulnerability due to CookieStore #28

Closed Blobonat closed 1 year ago

Blobonat commented 4 years ago

According to the WebAuthn spec §13.1 the RP should verify that the challenge in the clients response matches the originally generated challenge.

[...] the returned challenge value in the client’s response MUST match what was generated. This SHOULD be done in a fashion that does not rely upon a client’s behavior, e.g., the Relying Party SHOULD store the challenge temporarily until the operation is complete. Tolerating a mismatch will compromise the security of the protocol.

Does using the gorilla/session CookieStore for session management make the implementation vulnerable for replay attacks? If an attacker has recorded an old authentication response of another client this could be used to gain access to his/her account, because the RP can't detect the reuse of the challenge?

Maybe I have misunderstood/missed something...

Blobonat commented 4 years ago

I suggest to use the FilesystemStore instead.

arianvp commented 2 years ago

Found this vulnerability last week only to discover a ticket is already open! Here is what I wanted to write:

Problem

The problem lies in that the webauthn challenge is stored inside a cookie, instead of in a server-side session store.

One can replay a webauthn assertion without having access to the original webauthn device by recording the cookie value (which contains the challenge) and the the result of the webauthn assertion corresponding to that challenge. To replay a log in; simply reset the cookie to the previous known value and repeat the webauthn assertion result. The server will accept the webauthn handshake as valid eventhough no proof of presence of the device was needed. This weakens the security model of the handshake to the possession of a cookie instead of the possession of a webauthn device.

Though it is hard/impossible to exploit as a third-party (as the Cookie is stored as HtttpOnly;Secure) it does still weaken the security model in the first-party scenario. Namely the challenge-response mechanism is what proves the possession of the key and that key is connected to the original attestation challenge. One might have a policy that the user logs in with the attested device at moment of registration; but this weakness allows a malicious user to bypass that as a first party as no access to the device is needed to solve a challenge.

Mitigation

Store the actual challenge server-side and merely store a session id in the cookie that points to the challenge. That way you can ensure that the challenge is invalidated once it has been used. This way replay attacks are not possible and the client must answer with a fresh assertion that signs the fresh challenge; guaranteeing that the client is in possession of said webauthn device.

Similar mitigations in other projects

arianvp commented 2 years ago

This issue seems to be fixed by https://github.com/duo-labs/webauthn.io/pull/58 which stores the challenge in redis

MasterKale commented 1 year ago

The challenges are indeed persisted in Redis now (#58), and a session cookie is used to store and retrieve options by a "session key". Challenges are also deleted upon first use both during registration and authentication.