Firefox3.1/Security/ViewSource
Overview
Introduction
This page documents security issues in the "View Source" feature. In particular it covers the View Source "Linkification", a new feature in Firefox 3.1. The View Source QA TestPlan provides the most complete current documentation, including bugs.
Linkification
Linkification turns URLs in HREF and SRC attributes into hyperlinks which link to the source URL. The current approach is simple to the point of being crude, but it was chosen as a way to get a lot of "bang for the buck", if you will.
When a URL is "linkified", the source URL is first converted into an absolute URL (if it's not already), using the URL to the source file being used. If the source file specifies one or more BASE elements, then the base URL specified by the last BASE element is used.
Once an absolute URL has been constructed, it is turned into a "view-source:" URL. For example the URL http://www.mozilla.org/projects/minefield/ will be turned into view-source:http://www.mozilla.org/projects/minefield/. So clicking a link to an HTML page in page source will bring up the source for the new page, not the rendered HTML for that page.
Note that if a URL points to a text file (as determined by MIME type), then both the source URL and the view-source URL constructed from it have the same effect. So CSS and JS files linked from page source work as expected.
Currently images linked from page source do not work correctly (see [https://bugzilla.mozilla.org/show_bug.cgi?id=464339 Bug 464339). The "mailto:" and "view-source:mailto:" schemes work the same way, although that's by accident.
Describe the goals and objectives of the feature here.
- Background links
- feature-tracking bug links
- specs or design docs
- View Source QA TestPlan -- includes bug links.
Security and Privacy
- What security issues do you address in your project?
None.
- Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
No. (Are there any prefs that affect View Source?)
- Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
???
- How are transitions in/out of Private Browsing mode handled?
Not relevant
Exported APIs
- Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
None
- Does it interoperate with a web service? How will it do so?
No
- Explain the significant file formats, names, syntax, and semantics.
???
- Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
N/A
- Does it change any existing interfaces?
No
Module interactions
- What other modules are used (REQUIRES in the makefile, interfaces)
No changes
Data
- What data is read or parsed by this feature
- Document Base URLs
- URLs in SRC and HREF attributes
- What is the output of this feature
Same View Source as always, but now with hyperlinks
- What storage formats are used
No storage formats
Reliability
- What failure modes or decision points are presented to the user?
Click a link or don't click a link
- Can its files be corrupted by failures? Does it clean up any locks/files after crashes?
Files may be read from disk, but no files are written. Note that the feature is designed to pull files from cache if at all possible, but I'm not sure if there are any security issues to this.
Configuration
- Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
Linkification isn't affected by prefs; I'm not sure about view source in general.
- Are there build options for developers? [#ifdefs, ac_add_options, etc.]
No.
- What ranges for the tunable are appropriate? How are they determined?
tunable?
- What are its on-going maintenance requirements (e.g. Web links, perishable data files)?
None.
Relationships to other projects
Are there related projects in the community?
No
- If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?
N/A
- Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?
No.