Indistinguishable from Jesse

AutoLink turns plain text URLs, email addresses, bug numbers, ISBNs, and US phone numbers into links. For example, it turns all of these into links:

• http://www.squarefree.com/userscripts/
• jruderman@gmail.com
• Bug 162020
• Bug 162020 comment 0
• ISBN 0-340-82899-4
• (555) 555-5555

You can add new filters if you know how to use JavaScript regular expressions. Here is an example filter, rewrapped to fit in my blog:

  {
    name: "Bug number",
    regexp: /bug \#?(\d+)/ig,
    href: function(match) {
      return
        "https://bugzilla.mozilla.org/show_bug.cgi?id=" + 
          match[1];
    }
  }

To install a user script into Firefox, install Greasemonkey, restart Firefox, open the user script, and select "Install User Script..." from the Tools menu.

Bookmarklets to User Scripts is a Greasemonkey script that lets you turn any bookmarklet into a Greasemonkey script. The bookmarklet will then run every time a page in the included-sites list is loaded. If you find yourself using certain bookmarklets every time you go to certain pages, this script is for you.

JavaScript Development Environment 2.0 can run as a bookmarklet and lets you create Greasemonkey scripts in four clicks. I used it to make the Valid XHTML Greasemonkey script and I loved the shortened edit-test cycle.

The Valid XHTML user script is an adaptation of the blogidate XML well-formedness bookmarklet. It shows a line of text under each textarea indicating whether the text is well-formed XHTML. When the text is not well-formed XHTML, it displays Gecko's error message and gives you a link that selects the location of the error in the textarea. When the text is well-formed XHTML, it displays links that let you check whether the XHTML is valid in addition to being well-formed.

By default, it only runs on admin posting pages for Movable Type and WordPress and on archive pages for Simon Willison's blog. You can use Greasemonkey's interface to make it run on the sites on which you edit XHTML.

Screenshots

Demo for Firefox and other Gecko browsers

Asa pointed me to a new Firefox extension called Platypus. Platypus lets you remove or isolate parts of a page a similar manner to Aardvark and lets you save sequences of page-modifying actions as Greasemonkey scripts. Platypus tries to identify elements by IDs in the scripts it generates and falls back on using XPath expressions such as /HTML[1]/BODY[1]/FORM[1].

I used Platypus on Bonsai CVS query form to remove useless parts of the page. I modified the script it generated to move Bonsai's menu to the bottom of the page instead of removing it from the page entirely. The resulting script is Bonsai Isolate Form. To use the script, you must have both Greasemonkey and Platypus installed.

Inspired, I made two other Greasemonkey scripts for the Bonsai form. Bonsai Date Option makes the "date" radio group selection change when you click a textbox associated with one of the radio buttons, and Bonsai Nightly Range makes the "date" section default to the range between the previous two nightly builds rather than the last two hours.

Paul and Michael Krax found a few security holes in Firefox and put them together to form an arbitrary-code-execution exploit. Links: Paul's notes, private bug, public bug, Secunia advisory, MozillaZine article.

To protect yourself against all of these holes, disable JavaScript. (Some people have suggested only disabling software installation. If you only disable software installation, you will still be vulnerable to the XSS hole used in the exploit. XSS is sufficient for stealing cookies, saved passwords, intranet web pages, etc.)

Two of the security holes involve javascript: URLs, which have been the source of many security holes in Firefox and other web browsers. Brendan suggested tracking where javascript: URLs came from so they run with the correct privileges as a way of reducing the number of these holes in the future. Meanwhile, Hixie suggested disallowing chrome: code from using javascript: URLs.

Paul's exploit was leaked on Saturday. After the leak, I noticed that http://greyhatsecurity.org/vulntests/ was publicly listable (fixed as of Sunday). My guess as to how it was leaked is that someone else had noticed that the directory was listable and checked the directory every few days for new exploits. It is ironic that a security researcher's site had this kind of hole, but then again I have horrible habits with passwords and use Windows.

Jeff Walden tried to ask:

How do you find security holes?

This isn't a very coherent answer, and I don't know which parts are the most correct or most useful.

I'm good at ad-hoc testing, where I try to find and report as many bugs as I can. From this perspective, a security hole is just a bug that can be abused by an attacker in a way that hurts the user.

I frequently ask myself "What might the author of this code not have considered?". Sometimes I ask myself "How can I prove that this code is correct and secure?" instead.

I spent a lot of time triaging and testcasing Mozilla bugs, so I know a little about many Gecko and Firefox features. I know of many JavaScript and DOM features that tend to hurt security: getters and setters, eval and the version of setTimeout that takes a string, the with statement, prototype chains, and dynamic typing with implicit coercions. I know of several other Mozilla features that tend to lead to security holes: javascript: and data: protocols, synthetic events, security dialogs. I know of some security checks that are scattered and frequently missing: same-origin checks, CheckLoadURI calls.

I take note of places in Gecko where user data interacts with pages: visited link coloring, file upload controls, pasting from the clipboard. These exceptions often interact with other features to create security holes.

Even though I usually have access to source code, I rarely use it. Using Mozilla source is slow for me because lxr is slow, Google Desktop Search refuses to index my Mozilla source tree, and I'm not good at reading Mozilla source. Testing Mozilla like a black box is fast for me because I have tools like the JavaScript Shell.

I have compiled a list of security holes I have found in Mozilla and Google products. Most of the holes I've found in web sites could be found without much thinking by anyone who has read my security tips for web developers. The security holes I find in Mozilla tend to be more interesting and clever.