Web NFC

[beaufortfrancois]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Web NFC
• Specification or proposal URL: https://w3c.github.io/web-nfc/
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):

Other information

Web NFC aims to provide sites the ability to read and write to nearby NFC devices. The current scope is limited to NDEF, a lightweight binary message format. Low-level I/O operations with the ISO-DEP protocol and Host-based Card Emulation (HCE) are not supported.

• TAG Review: Web NFC w3ctag/design-reviews#461
• Chromestatus URL: https://www.chromestatus.com/features/6261030015467520

cc @zolkis @kenchris @reillyeon

[othermaciej]

Mozillians, FYI, Apple has stated our opposition here: https://lists.webkit.org/pipermail/webkit-dev/2020-January/031007.html

[ekr]

Maciej, Thanks, this is helpful. Could you provide more insight on the security issues you see? We have looked at WebUSB and WebBT, but not so much at this,

…

On Mon, Jan 6, 2020 at 1:53 PM Maciej Stachowiak ***@***.***> wrote: Mozillians, FYI, Apple has stated our opposition here: https://lists.webkit.org/pipermail/webkit-dev/2020-January/031007.html — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#238?email_source=notifications&email_token=AAIPLIOVJU56EWJ23EZJG3LQ4OR37A5CNFSM4KDAKCUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIG5FWI#issuecomment-571331289>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIPLIKS5I7BL3PXSP2VLCLQ4OR37ANCNFSM4KDAKCUA> .

[othermaciej]

We also have not reviewed this in as much detail as WebUSB or WebBluetooth.

On cursory review though, many items from the Threats section of the spec do not seem adequately mitigated by permission prompts (the only security mitigation defined for implementations).

For example:

Fingerprinting and data collection - spec says "The user SHOULD be able to be aware of what data can be shared using NFC from the given web page", but how is that possible, since the data is in a binary format and possibly encrypted by code running in the page?

NFC tag modification - prompting doesn't seem like an adequate mitigation.

Active attack via malicious NFC tag - prompting doesn't seem like an adequate mitigation.

[dbaron]

Active attack via malicious NFC tag - prompting doesn't seem like an adequate mitigation.

I don't think this is different from existing web technologies; this threat appears to just be about applications failing to validate application-specific data sufficiently. It doesn't appear any different from a web application failing to sufficiently validate "malicious JSON" or a browser having a vulnerability in an image decoder.

[zolkis]

NFC tags are like a piece of paper. Anyone can write anything on them (unless read-only) and anyone can read. It's also evident where the "paper" is (there is location context) and it's not impossible to move it (unless protected). Unlike paper, tags could be concealed, though, and still be able to be written/read.

NFC peer-to-peer ("beaming") is like other wireless technologies, only much more limited in physical space, i.e. the user sees and could touch the other communicating end. There is an awareness context and also a shared location context.

Other NFC tech than NDEF is not currently supported (e.g. handovers, payments, or special comms).

Security-wise NFC is about similar category as Web USB or a storage API, even though there are peculiarities, as outlined above.

The security threats outlined in Web NFC are not more serious than with other similar tech, they are just thoroughly explained.

Mitigations don't rely only on permission prompts.

We could take the concerns case by case.

[zolkis]

Fingerprinting and data collection - spec says "The user SHOULD be able to be aware of what data can be shared using NFC from the given web page", but how is that possible, since the data is in a binary format and possibly encrypted by code running in the page?

The text intends to say the user should be aware about what data is about to be shared before the communication happens. This is orthogonal to how the data is transmitted or in what format is it written. It has to do with how data is shared with a web page in general (i.e. other permissions than NFC).

NFC tag modification - prompting doesn't seem like an adequate mitigation.

NFC tags that are not read-only are meant to be modified. The text intends to say that a solution provider should not expect the data is not overwritten unless the tag is made read-only. However, Web NFC implementations should prevent unintended writes to tags by raising user awareness and requiring consent.

Active attack via malicious NFC tag - prompting doesn't seem like an adequate mitigation.

There are more mitigations described there than prompting. Prompting prevents NFC data being read without the user knowing about it. Implementations could choose the details shown in the prompt (including the kind of records there are). In addition, all automatic content handling should be disabled, which is the main measure against this threat. FWIW this is arguably more secure (or not more insecure) than possible malicious data injection from web sites in general, as the data is more constrained in format and nothing is (should not be) interpreted automatically - though applications could do that if the user acks.

IMHO content-related threats are not more aggravated than with the Web platform in general. User location related threats are specific to NFC (e.g involuntarily revealing user location by reading a tag and acting on that information in a way that can be traced back to reading that particular tag), but prompting and disabling automatic actions (such as opening URLs) mitigate those.

Probably it is possible to improve security on Web NFC and the editors value all feedback and proposals. Thank you all for taking the time.

[othermaciej]

Security-wise NFC is about similar category as Web USB or a storage API, even though there are peculiarities, as outlined above.

Mozilla has judged Web USB to be harmful based in large part on security considerations. (For the records, Apple’s WebKit team also opposes it for similar reasons.)

So if the security category is similar to Web USB, that’s not a good sign.

[zolkis]

Mozilla has judged Web USB to be harmful based in large part on security considerations.
So if the security category is similar to Web USB, that’s not a good sign.

I have checked the comments leading to that assessment and IMHO those either have mitigations in Web NFC, or don't apply. In order to verify this, Web NFC could be scrutinized by the same people and I am happy to discuss the details.

[slightlyoff]

A quick note that, per usual, the UI for any permissioning is left as an exercise for the implementer. If someone would like to add extra constraints (beyond proximity), the API is designed correctly to support this thanks to Promises:

https://github.com/w3c/web-nfc/blob/gh-pages/EXPLAINER.md#integration-with-permissions-api

[micolous]

Security-wise NFC is about similar category as Web USB or a storage API, even though there are peculiarities, as outlined above.

Mozilla has judged Web USB to be harmful based in large part on security considerations. (For the records, Apple’s WebKit team also opposes it for similar reasons.)

From the looks of it, the API specification currently restricts users only to NDEF tags, but the specification "leaves itself open" to future non-NDEF use. Both paths have problems:

• As NDEF is a lowest common denominator for NFC support on many mobile devices, it's not reasonable for browser vendors to anticipate how the protocol is used or what security assumptions have been made.

  As an example, the Yubikey has an "NDEF compatibility mode", where the device will pass back OTPs in text form (to be pasted into an app/browser on the phone).

• A future non-NDEF (with arbitrary APDUs) would also allow a web page to send arbitrary U2F APDUs to a security token, leading to a similar problem experienced because of WebUSB.

  One could also send EMV APDUs to a credit card, which allows unauthenticated access to the PAN (credit card number), CVV and magnetic-stripe data. In some cards it also includes basic information about past transactions (date, time, currency, value) and/or the cardholder's name.

  It is very difficult to sanitise APDUs (eg: read-only access), as there are many proprietary APDUs used by different cards, as well as subtleties around the way ISO 7816-4 (and other protocols) have been implemented.

As a developer of NFC software, a WebNFC API (that enabled non-NDEF uses) would allow me to target the web, instead of requiring an app. However, I believe that WebNFC has similar problems to WebUSB, even in its NDEF-only form.

[martinthomson]

Thanks @micolous, that is very helpful. Information about actual NDEF usage does clarify things a lot.

[zolkis]

Thanks @micolous for looking into the spec.

As NDEF is a lowest common denominator for NFC support on many mobile devices, it's not reasonable for browser vendors to anticipate how the protocol is used or what security assumptions have been made. As an example, the Yubikey has an "NDEF compatibility mode", where the device will pass back OTPs in text form (to be pasted into an app/browser on the phone).

I am not sure if I understand the point correctly. Yubikey returns text NDEF content that is exposed by the app. Is there a threat that is not listed in the Threats section that browser vendors are allegedly supposed to mitigate? I think it falls under this. But do you think browser vendors are liable for protecting credentials listed in text form in web pages (and tell whether that was against the intent of the data owner)?

EDIT: looks like it's a URL that is shared.

A future non-NDEF (with arbitrary APDUs) would also allow a web page to send arbitrary U2F APDUs to a security token

Future API is not yet covered in the Security section, indeed :). I agree those will have more security concerns. Depending on future analysis, we could decide later to place the eventual future non-NDEF APIs into a difference conformance class, or a different spec altogether. However, it is out of scope of this issue.

As a developer of NFC software, a WebNFC API (that enabled non-NDEF uses) would allow me to target the web, instead of requiring an app. However, I believe that WebNFC has similar problems to WebUSB, even in its NDEF-only form.

I agree on the assessment about non-NDEF use (which is not supported, but in scope) having similar security concerns as WebUSB - but that is not part of this specification. However, I need more specific explanation on that point for NDEF-only usage, i.e. what threat or liability or mitigation is currently missed from the Security section. Suggestions and contributions are very much needed and welcome, especially from developers! Thank you.

[annevk]

But do you think browser vendors are liable for protecting credentials listed in text form in web pages (and tell whether that was against the intent of the data owner)?

Maybe not in the legal sense, but it's definitely something to take into account. If a user grants NFC access to example.com in order to play with a gadget and then later example.com could inadvertently end up with the user's Yubikey data that's a serious problem and a reason to not offer the API.

And I suppose this is clear, but it's worth reiterating from time-to-time: it's not enough to enumerate threats and give user agents flexibility in the UI they use for a given feature. What's important is a holistic end-to-end evaluation of features (end user, developers, attackers, …) and being reasonably confident that UI X coupled with API limitations Y would not expose users to harm.

[zolkis]

If a user grants NFC access to example.com in order to play with a gadget and then later example.com could inadvertently end up with the user's Yubikey data that's a serious problem and a reason to not offer the API.

No, that is not possible with Web NFC (unless Yubikey expose that data).
[And even if it was, not offering the API is not the only possible solution: one could also mitigate the threat, for instance.]
In order to use Web NFC, a page has to be in foreground, the user needs to be in physical proximity of a tag and make a conscious gesture to interact with the tag. Moreover, the user has to give permission from the UI. Permissions can be revoked and may be time-limited or session-limited. Currently no page with former permission to use Web NFC can access NFC data of the top page which is currently using Web NFC.

The problem you quote could be valid for all communication features already implemented n the browser. Except that NFC has one more security barrier: the user must physically interact for a communication happens.

it's not enough to enumerate threats and give user agents flexibility in the UI they use for a given feature. What's important is a holistic end-to-end evaluation of features (end user, developers, attackers, …) and being reasonably confident that UI X coupled with API limitations Y would not expose users to harm.

I agree that is important and that exactly has been the aim in the Security section of Web NFC. Also, it is not enough to have a holistic evaluation, but we need to continuously update it, since new threats may appear all the time. It is known that security is not a job done once and we're done. Because of that, security always gives good pretext to stop doing things, but then it is also possible to mitigate the threats. That choice is not related to security, but to willingness to deal with it or not.

Thanks for the feedback anyway, it's good to check things from new perspectives. We are re-evaluating the security section with this thread in mind and see if there are things to include/improve.

[hsivonen]

No, that is not possible with Web NFC (unless Yubikey expose that data).

By default, a Yubikey does not require an NFC host to present a password in order to read a list of the user's TOTP-protected accounts and the valid-for-30-seconds codes.

the user needs to be in physical proximity of a tag and make a conscious gesture to interact with the tag

I've had cases where I've had a Yubikey in my jeans pocket and a phone in the pocket of a winter coat that overlaps the jeans such that my phone has accidentally communicated with the Yubikey.

[beaufortfrancois]

I've had cases where I've had a Yubikey in my jeans pocket and a phone in the pocket of a winter coat that overlaps the jeans such that my phone has accidentally communicated with the Yubikey.

Thankfully, with Web NFC, it won't happen as access to the NFC radio is blocked if the display is off or the device is locked.

[zolkis]

@kenchris created an issue (analysis) for the Yubikey case. Any suggestions are welcome.
w3c/web-nfc#543

[dbaron]

If a browser wanted to prompt the user before allowing NFC interactions, what information would it have that it could tell the user about what device it is interacting with? And what information would it have that would allow it to distinguish between different NFC tags or NFC devices?

(One of the analogies I've been thinking about in my head is how the question of what a browser should let a web page be able to do to/with an NFC tag relates to the question of what a browser should let a web page be able to do with interactions with a server on a different domain (e.g., submitting an HTTP POST, etc.). I'm not sure how good an analogy that is, but I think the quality may depend on the extent to which the browser can identify distinct NFC devices and (if needed) describe them to the user.)

[martinthomson]

I think that there is a different analogy that might be a better fit here. This is like giving access to a camera. That camera can be used to take deliberate (but limited) images of the local environment. That might convey the right level of gravitas to the privacy question.

The other potential analogy is as a keyboard. Activation is deliberate: you shove the reader at a thing and it buzzes. The action itself conveys intent.

I think that the camera is a better model, but I see two ways in which these analogies break down:

• in the potential for accidental triggering of capture, something that is generally not available with either; cameras rarely activate, capture, and send by accident and an accidental keypress rarely conveys anything meaningful; and

• in the ability for people to understand the binary information that this captures, especially since it is very difficult to render arbitrary data in a comprehensible form.

[JeremiePat]

Hi!

Sorry for the silly question, but I'm fare from a security expert: what is the difference in term of security between the following scenario:

1. "As a web user, I'm prompt to read an unknown NFC Tag" versus "As a web user, I'm prompt to share my camera to read an unknown QRCode"

2. "As a web user, I'm prompt to write on an NFC Tag" versus "As a web user, I'm asked to print a generated QRCode"

If only NDEF is allowed, It looks the same to me and the QRCode scenario are currently doable with all browsers.

[annevk]

The comment above you goes into it, and also, as mentioned in #238 (comment), there might be multiple tags in the vicinity.

[zolkis]

That comment goes blind on the point (made earlier in this thread) that there is no accidental tap with Web NFC: it only happens if the screen is on, device unlocked, web page on top and in focus, the user has given permission AND made a gesture to tap.

About "the ability for people to understand the binary information that this captures": when a tag is read (but before presenting to the app), the user could already know what kind of data is on it: URL, text, media (with given MIME type). It should be feasible to build that into the permission system as well.

IMHO analogies are not really helping to build a solid case for NFC security/privacy: one just needs to understand how this tech works in particular and then investigate the relevant security issues, instead of making an analogy and investigate that (metaphoric) security.

[flaki]

* in the ability for people to understand the binary information that this captures, especially since it is very difficult to render arbitrary data in a comprehensible form.

I wonder if there are any expressed (and existing) use cases where exposing private information this way is a possibility? If it would be possible to trick someone into exposing e.g. their contactless payment card details or such this way, this would be awful of course, but my understanding is that the NDEF limitation with the above explained mitigations from the spec side (unlocked phone, display on) should be enough to prevent misuse?

(a note of clarification: avoiding exposing contactless payment details do not require mitigations of any sort as they are not using the NDEF protocol, they were just used above as an example of a widely deployed contactless technology that would be attractive to attackers)

[beaufortfrancois]

For info, a blocklist containing vulnerable YubiKeys devices has been added to the spec. See w3c/web-nfc#550 and https://w3c.github.io/web-nfc/#blocklist for details.

[dbaron]

A blocklist of known-vulnerable devices has pretty different security characteristics from a mechanism for devices that are known to be safe to mark themselves as such (e.g., something CORS-like). Given that we know of one common device where this isn't safe, it seems likely that there are others.

[mseddon]

But do you think browser vendors are liable for protecting credentials listed in text form in web pages (and tell whether that was against the intent of the data owner)?

Maybe not in the legal sense, but it's definitely something to take into account. If a user grants NFC access to example.com in order to play with a gadget and then later example.com could inadvertently end up with the user's Yubikey data that's a serious problem and a reason to not offer the API.

And I suppose this is clear, but it's worth reiterating from time-to-time: it's not enough to enumerate threats and give user agents flexibility in the UI they use for a given feature. What's important is a holistic end-to-end evaluation of features (end user, developers, attackers, …) and being reasonably confident that UI X coupled with API limitations Y would not expose users to harm.

To be brutally honest, sounds more to me like Yubico device security is generally crap and shouldn't be deployed in the real world since I can clearly just tap my phone against your pocket using an app and steal your Yubikey NEO or FIPS data as an attacker. Encrypting NDEF data asymmetrically, or requiring activation of the NFC on the device itself with a physical button is pretty basic stuff that should have been built into anything posing as an authentication solution from the outset. I'm still not clear why this is a vulnerability in the web specification.

Binning NFC into the same vulnerability class as USB, with it's incredibly complex protocols and capabilities, or Bluetooth with it's potentially ranged attack possibilities feels artificial to me. Some websites are also vulnerable via CORS requests, should we disable fetch too, or just accept that sometimes people release terrible security products and it is the job of the security industry (and the offending company itself) to bring attention to these issues if they are not capable of designing in security correctly?

[sam-ka]

I agree with @mseddon's assessment. The risk being associated here with Web NFC (as currently proposed) is exaggerated. NFC is not comparable to USB. I'd go further and say that Web NFC posses far less risk than camera and mic access, both of which Mozilla doesn't seem take issue with having available behind a measly permission bubble.

I will, as have many before me, write my app for chromium-based browsers exclusively and instruct interested users with other browsers to switch. What a shame.