- From: Nathan Parker via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 May 2015 17:25:33 +0000
- To: public-web-nfc@w3.org
ngparker has just created a new issue for https://github.com/w3c/web-nfc: == Security review == _[Intro: I am Nathan Parker of the Google Chrome Security Team]_ I have some question and comments on the spec, and one general concern which is described in the first security scenario below. I look forward to your responses. ### Questions * Will service workers get access and how will that persist? * How and why is “URL scope” different from a exact origin match? The API permission should be based on exact origin match. * When asking for permission, will it be always for general Web NFC access or for a subset of features (read vs read/write)? ### Comments * Non HTTPS sites should get no access the API. I think the _NOTE_ about it should be a requirement in the spec. * Should only allow API access on top-level frames * Should always require permission before reading arbitrary tags. * For Bluetooth and Wifi handover, the user should have to grant access to the secondary API and must be able to properly understand what they’re granting. * A tag containing JSON shouldn’t be eval()’d. It wasn't clear to me how that was parsed. * Send() method: The “platform specific timeout” should be bounded so the user doesn’t accidentally write to the wrong device many minutes later, potentially leaking data. ### Security scenarios to address 1. A malicious Web NFC tag could send an arbitrary payload to a website via a user’s device, along with a user’s existing web credentials. The webapp and server would need to treat that payload as completely untrusted. The spec should address this in some way. My concern is that developers will make mistakes here and end up exposed to attacks similar to persistent XSS. Some potential directions to take this: Suggest rules for handling that payload safely, provide best-practice methods for doing so, provide a sanitization/validation function. The webapp’s server could even cryptographically sign a payload before writing it to a tag so the contents could later be verified. 1. A Web NFC tag (say, embedded in restaurant table) should not ever trigger a user’s device to navigate to a website without asking permission, unless the site is in the foreground and has been granted permission. Otherwise, this would leak the user’s location unexpectedly. See https://github.com/w3c/web-nfc/issues/22
Received on Friday, 15 May 2015 17:25:34 UTC