From MozillaWiki
< Security‎ | Reviews‎ | B2G
Jump to: navigation, search


    This review is the old version of NFC. For a more recent review, see

Gecko API Review Details

  • API: Web NFC
  • Review Date: September 2013
  • Review Lead: Paul Theriault

This is a design review of the Web NFC API as currently designed, as of Sept 2, 2013. The API is not finalised but the Mozilla security team has been working with developers involved to provide security feedback to inform the finalization of this API, and guide future direction. While this review did cover some level of code review, final security code will be required once the implementation is stable, and there are apps planning to actually use this API.


The following system components were reviewed:

  • Gaia
    • System Application changes
    • Web Activities
    • System messages
    • Communication between system app and NFC demo app
  • Gecko
    • mozNfc APIs
    • Gecko Permissions
    • Messaging (NFC:* messages, system messages)
    • NFC System worker
    • Interface to nfcd on IPC socket (JSON-based communication protocol)
  • Gonk
    • NFC Daemon (nfcd)
    • Interface

There was also some discussion on the following topics, however these were are not included in the formal review below:

  • NFC Wallet
  • Transit applications (e.g. miFare)
  • Secure Element (GSMA)


The diagram below shows the current interactions between the major components of Web NFC.

NFC diagram 0.1.png


From order of lowest layer to highest, the main system components are described below.


Receives NFC events & messages from hardware. Communicates these messages to Gecko via a JSON based protocol (see bug 897312 for a description of this protocol. Currently this is a JSON based protocol, but an upcoming change will likely convert this to be a binary-based protocol instead.

NFC Worker

NFC worker runs only in the parent b2g process, and connects to the '/dev/socket/nfcd' socket to send and receive messages from NFCd. Messages from NFCd are then posted to the the main thread (nfc.js) via DOM messages.


This component in the main process converts messages into NFC:* messages to be sent to the NfcContentHelper.js. When receiving messages it doesn't do any more than just check the type, and then create the appropriate message. In the reverse direction (when the web page is using the navigator.mozNfc API) some security checks are performed here to make sure the connecting child has the appropriate permission.

MozNfc API

This is the API exposed to web content which allows for listening for NFC events, and writing and reading to/from NFC tags.

System App

A critical part of the model with NFC is that there only one app which performs the role of manager, and this is a system app currently. It listens for when tags are discovered and lost ('nfc-manager-tech-discovered'& 'nfc-manager-tech-lost' system messages). This requires the 'nfc-manager' permission.

NFC Client App

This app demonstrates how an app might communicate with NFC tags

Other Gaia App

Other gaia (and third party) apps are potentially involed in NFC. For example, when a contact record is received over NFC, the nfc-ndef-discovered web activity is fired by the system app, with the expectation that it is handled by a contact manager app (though this is up to the user to decide).

Relevant Source Code

Key Bugs


  • 860907: NFC Daemon for B2G (daemon for supporting lib-nxp)
  • 906579: B2G NFC: NFC Daemon for supporting libnfc-nci (daemon for supporting lib-nci)
  • 897312: B2G NFC: Define protocol to communicate between nfcd and b2g


  • 674741: WebNFC (near-field communication)


  • 860910: B2G Gaia Integration for NFC

Secure Element Support

  • 879861: NFC Secure Element Support
  • 884594: Support Nfc Access Control for Secure Element Access

N.B. Code in development can currently be accessed at and

Permission Model


  • Ability to listen to tech discovered and tech lost system message. Only the system app would generally have this permission.


  • Any app wanting to read or write a tag needs the nfc permission
  • nfc permission can be read or write. nfc-read does not have access to write data to a tag

Checks in the parent (nfc.js) are performed to ensure that DOM functions require permission to access:

 receiveMessage: function receiveMessage(message) {
   debug("Received '" + + "' message from content process");
   if (!"nfc-read")) {
     if (DEBUG) {
       debug("Nfc message " + +
             " from a content process with no 'nfc-read' privileges.");
     return null;

Note that an addition check is performed for the write case:

   // Enforce NFC Write permissions.
   switch ( {
     case "NFC:NdefWrite":
     case "NFC:NdefPush":
     case "NFC:NfcATagTransceive":
       if (!"nfc-write")) {
         if (DEBUG) {
           debug("Nfc message " + +
                 " from a content process with no 'nfc-write' privileges.");
         return null;

Parent/Child Communication IPC NFC:* messages Parent listens to

 const NFC_IPC_MSG_NAMES = [

Review Notes

Note that this is only a preliminary design review since the code is still a work in progress.

1. Content/Chrome Segregation

2. Process Segregation

NFS.js largely just passes values it recieves striaght down to NFCd. Maybe we want to do more validation here, but not sure what the implication of not doing this is.

* "NFC:SendToNfcd" : debug method only
 * "NFC:NdefDetails": sessionid is the only interesting parameter here. Probably should be validated by NFC.js? 
 "NFC:NdefRead": same comment as NdefDetails
 "NFC:NdefWrite": same comment as NdefDetails
 "NFC:NdefPush": Should message.records be validated? What is impact if it isn't?
 "NFC:NfcATagDetails": message.params assigned but not used
 "NFC:NfcATagTransceive": again, should message.params be sanitized?
 "NFC:Connect": compromised app could fake message.techType?
 "NFC:Close": any app could just continuely call close dossing NFC ? (since session is automatically sent?)

3. Data validation & Sanitization

No issues apart from others raised

4. Denial of Service

App with permission can call close repeatedly to DoS NFC?

Security Risks & Mitigating Controls

Malicious NFC Tag

  • Mainly concern of firmware & drivers
  • Could possibly pass up a malformed message to nfcd or even gecko
  • Mitigated by validation of input, fuzz testing

Attack against chrome worker

Can a process connect directly to chrome worker? Can a process kill nfcd and put itself in its place?

  • validate nfcd<-> gecko protocol (JSON based?)

Attack from compromised child process (no permission)

  • Can compromised child process talk directly to NFC without parent?
  • Possible to spoof message, or escalate privilege, DoS other apps etc
  • Mitigation: review messages

Malicious app with NFC permissions

  • malicious app could be granted nfc (failure in review process) or vulnerability in legitimate app
  • What damage could a rogue app with NFC permissions do to the system

Malicious NFC NDEF message

  • Is it possible to attacks through ndef messages?
  • Treat all input as untrusted as usual.
  • Require user interaction before performing actions

Spoofing Web Activities

Any web page could initiate any NFC web activity. Probably would only be confusing to the user since it wouldnt work. Do we need to prevent this though? Likewise, any app could register to handle nfc activities without the permission. It wouldn't work (ie the app wont have NFC access without your permission, but may lead to issues). Maybe investigate alternatives to Web Activities, possibly put more UI into system app (similar to mozpay API or similar )

Actions & Recommendations

  • Ensure data from content is validated (wrappers can help with this) (bug 913336)
  • Use webIDL (as per
  • Ignore messages from apps which aren't currently chosen for using NFC API (bug 913340)
  • Further analysis required in future. Especially final gecko code, and also of web activities that will be used by final production NFC app