- From: =JeffH via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Oct 2018 21:19:20 +0000
- To: public-webauthn@w3.org
@milesstoetzner commented: > Since he can replace PublicKeyCredential.response.attestationObject, he can also replace PublicKeyCredential.rawId. Yes, the attacker can and probably should/would (in order to be successful) -- that's what I was getting at in footnote [1]. @emlun commented: > what I was considering is mainly the MitB case, by the RP inadvertently including malicious script (whether via XSS or explicitly loading script from another domain) on their page for example. Yep. If we're going into details then I'm thinking we'd want to be explicit about the threat model (discrete MITM vs MITB) > I would like to mention something like Content Security Policy [**CSP**], and perhaps Token Binding, as an example protection instead of just "TLS and related technologies", agreed. > I'm not sure which of these technologies are applicable and mature. CSP can mitigate XSS but one's webapp needs to be structured to take advantage of CSP. [CSP L1 is well-supported, CSP L2 is fairly-well-supported](https://caniuse.com/#search=content%20s). So CSP would seem to be a mitigation against MITB injection. Token Binding is emergent, and its use is expressly to cyptographically bind protocol artifacts such as cookies or webauthn responses to the TLS layer, thus is a mitigation for discrete MITM's replay of protocol artifacts. -- GitHub Notification of comment by equalsJeffH Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1088#issuecomment-428735802 using your GitHub account
Received on Wednesday, 10 October 2018 21:19:21 UTC