Skip to content
This repository has been archived by the owner on Nov 18, 2021. It is now read-only.

Security in interaction with server side applications

bard edited this page Sep 13, 2010 · 3 revisions

When a web page is connected to a conversation (and consequently to a contact), it is effectively granted right to use a subset of a local XMPP session. This has to be done carefully in order to avoid security issues.

The following measures are taken:

  • Just like a page is only allowed to communicate with its serving host via XMLHttpRequest, a page will only be allowed to send messages to the contact it has been connected to. If it produces a stanza that includes a “to” attribute, the “to” attribute is ignored.
  • All data produced by the page is received by xmpp4moz via a DOMInsertedNode mutation event, that carries the data as plain text. Text is assumed to be XML and is used to initialize an E4X object. If text is not valid XML, reading will simply fail. Nowhere within xmpp4moz is text coming from a page assumed to be Javascript code and passed to eval(), as this would evaluate untrusted code in a trusted context. The text might indeed contain Javascript code as the payload of a stanza, but it will only get a chance to be evaluated in the untrusted context of the page loaded in the contact’s browser.
  • When a stanza is received from contact and it has to be forwarded to page, only DOM functions are called in the page from chrome, specifically getElementById() and textContent. Since XPCNativeWrappers are enabled, these functions are guaranteed to be true DOM functions and not page author’s overrides.

Behaviour not conforming to the above rules is to be considered a bug.

The following additional measures are being considered or are already
scheduled for upcoming versions:

  • When user connects a page to a contact, an informational dialog should be presented to the user, explaining that from that point on until page disconnection, or until he navigates away from the page, stanzas belonging to the conversation with that contact are being forwarded to the page, thus possibly to its server, therefore the user should only continue if he trusts the page provider.
  • User might be given the option of downloading the page to his machine, so that it is then executed from a file:// URL and can no longer communicate with the serving host. (Of course, this would also prevent legitimate uses of page to host communication, such as saving a shared document.):