come from untrusted sources. For example, when a user
stores a bookmark, Firefox records the un-sanitized title of
the bookmarked page, which is controlled by the Web page,
in an RDF file. Extensions can also access un-sanitized bookmark URLs using the nsILivemarkService interface and
the BookmarksUtils object.
Extensions access Firefox preferences through the
nsIPrefService interface. Any extension can set values in
the preferences, and extensions have unchecked access to all
preference settings. Some extensions use this service to store
untrusted strings obtained from Web page content; hence
using this service is also treated as an untrusted source.
In summary, the Vex treats the following as untrusted
popupNode,BookmarksUtils, and access to the new
instances of the objects nsIRDFService,nsILivemark
Service, and nsIPrefService.
3. 2. executable sinks
Now we describe the set of executable sinks, which are
which it executes dynamically. This flexible mechanism can
However, this flexibility can lead to code injection vulnerabilities in extensions. If extensions execute eval functions on un-sanitized strings that come from untrusted sources, an attacker
Each HTML element in a page has an innerHTML
property that defines the text that occurs between that element’s opening and closing tags. Extensions can change
the innerHTML property to alter existing DOM elements, or
to add new DOM elements, because the browser parses the
Thus, passing specially crafted strings (e.g., <img> tags with
lead to code injection attacks.
Extensions can add a new DOM element to a content page
or chrome page by using the appendChild method. This
method causes the browser to parse and process the data within
the element, similar to the innerHTML property. Therefore,
this feature can also be used to execute injected code.
In summary, the executable sinks that we consider in
Vex are calls to the functions eval and appendChild, and
assignments to innerHTML property.
4. statiC infoRmation fLo W anaLYsis
The core component of Vex is a static analysis tool for
detecting explicit information flows in browser exten-
different sources and sinks, including all those described
in Section 3. To support fine-grained information-flow
analysis, Vex tracks the flows from source objects to the
taint-based analysis. Motivated by the fact that every flow
reported needs to be checked manually for attacks, which
can take considerable human effort, we aim for an analysis
that admits as few false positives as possible, where false
positives are flows reported by Vex that cannot actually
occur at run time.
In this section, the abstract heap is described in detail,
followed by a description of the data structures used for
the static analysis. The high-level ideas behind Vex’s static
analysis are also described.
using the notion of an abstract heap. Every object is stored
on the heap. The heap is modeled as a set of (location, object)
pairs. A location is an arbitrarily generated name created
whenever a new object is created in the program. An object
is a set of (property name, value) pairs. The property names
could either be identifiers or strings. An abstract value could