Security Considerations: Writing first round of threats and mitigatio… #277
Conversation
…ns (Web API level) A first draft of the identified threats and potential mitigations (some already applied), particularly at the Web API level. *Threats* - SOP Violation - Fingerprinting and Cross-Device Tracking - Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF) - Clickjacking & UI redressing - Reply Attack - Quishing - Phishing/Harvesting *Mitigations (already implemented or to be considered)* - Data Minimization - Secure contexts - Limit API usage - Informing the user - Transient activation Things to consider: - What else could go wrong (if there are other threats) - What can we do about the threats we have identified - Do we like the countermeasures we already have in place - Are there other mitigations to consider or write down [cc'ing @Sh-Amir and @ZAnsaroudi]
simoneonofri
added
security-tracker
|
This still feel overly broad and not necessarily related to the API. |
|
|
||
| </ul> | ||
| <h4 id='quishing'>Quishing</h4> | ||
| <p>Quishing occurs when a malicious site tricks the user into replacing a legitimate QR code, tricking it into |
There was a problem hiding this comment.
I don't understand "replacing" here. It seems like the attack is presenting the user with a maliciously-crafted QR code which when followed, will lead to a credential presentation request that will deliver the results to an unexpected party (either the attacker, or as a confused deputy confirming the user's identity for a request that the attacker made to some other verifier). Maybe the attacker is inserting it in a place where it looks to the user like a legitimate request from a different verifier, and that's a kind of replacement?
There was a problem hiding this comment.
For the framing I was giving it, the QR code is managed directly by the API and displayed securely and not via an (controlled by an adversary).
Does that make sense to you, or do you think we should frame it differently?
Co-authored-by: Marcos Cáceres <marcosc@apple.com>
Co-authored-by: Nick Doty <npdoty@ischool.berkeley.edu>
removed Permission API, added Permission policy
update transient activation
(Web API level)
A first draft of the identified threats and potential mitigations (some already applied), particularly at the Web API level.
Threats
Mitigations (already implemented or to be considered)
Things to consider:
[cc'ing @Sh-Amir and @ZAnsaroudi]
Preview | Diff