Scalable Vector Graphics Browser Evaluation

In this section we will compare the current policies regarding SVG in three of the most used modern browsers. The versions discussed here will be Mozilla Firefox 28, Google Chrome 34 and Internet Explorer 11. We will try to be complete in our testing and present a full evaluation of the various ways SVG files can be embedded in the HTML document. The reader should note that the SVG files used in these experiments are hosted on the same domain as the HTML document. We present some test files in appendix B.4 for those interested.

5.5.1 Mozilla Firefox

The Mozilla Foundation Developer network reports that Gecko1_{places some restrictions} on SVG content when it is being used as an image [145]. The following restrictions are active in the current implementation of Firefox:

• JavaScript is disabled.

• External resources (e.g. images, stylesheets) cannot be loaded, though they can be used if inlined through BlobBuilder object URLs or data: URIs.

• :visited-link styles aren’t rendered.

• Platform-native widget styling (based on OS theme) is disabled.

They also note that these restrictions are specific to image contexts; they do not apply when SVG content is viewed directly, or when it is embedded as a document using the <iframe>, <object>, or <embed> elements.

In table 5.1 we present the results of the policy tests run in Firefox.

When analysing the results, it can be seen that the Firefox policy prevents SVG files from executing script code in the scenarios where it is used in an image context, both when using a normal SVG files or a chameleon. The <img> element and the use of SVG in CSS backgrounds are the uses inside an image context. In all other cases Firefox allows SVG to execute script code, but seems to keep the SVG DOM strictly separate from the DOM of the HTML document, except when using inline SVG.

Embed Method Chameleon? Scripting Enabled DOM Access

Not Embedded No Yes Restricted

Not Embedded Yes Yes Not Restricted

Inline No Yes Not Restricted

<img> No No /

<img> Yes No /

CSS Background No No /

CSS Background Yes No /

Table 5.1: Firefox scripting and DOM access policies when using SVG.

Upon further investigation, we discovered that DOM access is never intentionally prohibited by Firefox in SVG files. One example to do so is to create an XHTML context in an SVG file by using the <foreignObject> element. Our earlier observations about cookie access restriction were thus not the result of a safety policy. This results in the new table 5.2 for SVG files.

Embed Method Chameleon? Scripting Enabled DOM Access

Not Embedded No Yes Not Restricted

<img> No No /

Table 5.2: Firefox scripting and DOM access policies when using SVG.

It is important to know that script execution is possible when SVG files are viewed directly through the “view image” button. This button is offered by Firefox to view the original SVG file when the SVG file is embedded through <img> tags. Lastly, we note that script code embedded inside of SVG files is executed without warning when opening the files on the local system.

5.5.2 Google Chrome

We conducted the same experiments on Google Chrome as in the previous section on Firefox. Table 5.3 shows the gathered information from these tests.

Embed Method Chameleon? Scripting Enabled DOM Access

Not Embedded No Yes Not Restricted

Not Embedded Yes Yes Not Restricted

Inline No Yes Not Restricted

<img> No No /

<img> Yes No /

CSS Background No No /

CSS Background Yes No /

Table 5.3: Chrome scripting and DOM access policies when using SVG.

Chrome employs the same policy as Firefox that makes sure in all the image context cases (so <img> and CSS background) script execution is prevented. Another observation we can immediately make is that Chrome does not have any DOM restriction in the other situations, this means local storage information can be freely accessed from SVG files at all times and could be abused easily by user uploaded SVGs. The security implementations are left to the developers of the HTML document in question, and would largely be determined by the SVG scanning mechanism that was used. Using chameleon SVG files instead yields the same results, although we must note that when using these inside an image element does not properly show the image, a broken link is shown instead. Chrome also allows right clicking an image inside <img> tags and either saving the image to the local system or viewing it in another tab, even if the image is a chameleon file that failed to load properly. Again, as was the case with Firefox, if an SVG file is opened from the local system, script code will automatically be executed.

5.5.3 Internet Explorer

As with the previous two browsers, we performed the same security tests on Internet Explorer 11 to determine its SVG security policies. Table 5.4 shows the results of these tests.

Embed Method Chameleon? Scripting Enabled DOM Access

Not Embedded No Yes Not Restricted

Not Embedded Yes Yes Restricted

Inline No Yes Not Restricted

<img> No No /

<img> Yes No /

CSS Background No No /

CSS Background Yes No /

Table 5.4: Internet Explorer scripting and DOM access policies when using SVG.

The no scripts in the image context policy seems to be a cross browser policy, as also in Internet Explorer script execution is prevented when the SVG file in embedded through <img> tags or used inside CSS backgrounds. Another similarity with the other browsers is that SVG files embedded in other ways do not seem to have a separate DOM or no-script policy either and can thus, also in IE, freely access the source document object model. This means Internet Explorer also puts most of the user uploaded SVG security in the hands of the developers.

Internet Explorer also has some additional security implementations, unlike Firefox and Chrome, it does not allow for SVG images being viewed directly by right clicking them when embedded in HTML content, but does allow to save them. This prevents users, that are unaware of the possible dangers of viewing SVG files outside of an image context, of putting themselves in harms way. An additional security policy is that when SVG files are opened from the local system, possibly after saving them by right clicking, script execution is prevented unless the user manually approves it.

One observation that struck us as weird was that the SVG chameleon seemed to have restricted cookie access, the explanation for this would probably have to do with the implementation of our test SVG. We reran the tests with another chameleon, the code of which can also be found in appendix B.4. The new results are presented in table 5.5.

The results of the new SVG chameleon show that no DOM restrictions were active on chameleon SVG files either. From this we can conclude that Internet Explorer 11 has a security policy that immediately makes a new DOM for every iframe element that

Embed Method Chameleon? Scripting Enabled DOM Access

Not Embedded Yes Yes Not Restricted

<img> Yes No /

CSS Background Yes No /

Table 5.5: Internet Explorer scripting and DOM access policies when using SVG, modified chameleon.

was created inside an XML context, thus making sure every code execution triggered inside <iframe> tags was unable to access the local storage of the source document. We modified the test code in the appendix to embed the line shown in listing 5.3.

1 <iframe s r c=” j a v a s c r i p t : a l e r t ( document . c o o k i e ) ” />

Listing 5.3: Modified line to test iframe DOM change.

This showed us that we were correct in expecting that Internet Explorer made a bogus fully qualified domain name when executing JavaScript inside the “src” attribute of an iframe. When repeating the test on both Firefox and Chrome, we observed that this security feature is not active on either of them. Further testing revealed that the same policies applied to the other methods of embedding on IE, such as <embed> and <object>. Neither one of these had the same restrictions on Firefox or Chrome.

We also made an additional observation. Internet Explorer throws security exceptions when the HTML document and SVG files are opened through HTTPS connec- tions, but the XHTML specification was linked through HTTP. If the link is altered to HTTPS, the code would simply not run. The other browsers do not throw security exceptions for this reason. The XSLT processing will fail in Internet Explorer, because it is considered active content. Unlike in Firefox and Chrome, the embedding of the chameleon file in Internet Explorer will display the visible part of the circle. Although the XSLT processing will not execute, it will still parse the elements in the chameleon file. The parsing of the <script> element in the second attack vector will switch the context to an executable one, and this is why the execution is possible.

In document Dutch Summary. Inleiding (Page 106-110)