3.6 Scalable Vector Graphics
4.1.3 Attack Vectors
Here, a number of XSS attack vectors that work in the current versions of most pop- ular browsers will be provided. For a large list of HTML5 attack vectors, we refer the reader to [94]. Many of the attack vectors explained below can be found on this list, we re-tested them in the latest browser versions. In section 4.6 some SVG XSS vectors will be discussed as well. This is not meant to be a complete list of attack vectors by
any means, we just wish to demonstrate the wide range of XSS possibilities. In our examples we will use the typical “alert(1)” function to demonstrate the script injection. In real life scenarios this would be replaced with a more malicious script. To check if access to local storage was possible, usually an alert of the document cookies was used (sometimes in combination with inserting a dummy cookie for the domain into the browser manually).
Listing 4.1 gives three typical attack vectors that exploit the “onerror” attribute that can be used in many elements. The combination with the <img > element is an old HTLM4 vector, while the <audio> and <video> elements are new HTML5 vectors. The <source> element has to be used to use the “onerror” attribute in the latter case.
1 <img s r c=” n u l l ” o n e r r o r=” j a v a s c r i p t : a l e r t ( 2 ) ” /> 2 <a u d i o><s o u r c e o n e r r o r=” a l e r t ( 1 ) ”>
3 <v i d e o><s o u r c e o n e r r o r=” a l e r t ( 1 ) ”>
Listing 4.1: Typical onerror attack vectors.
Other events can also be connected to script code, listing 4.2 shows the scroll event invoking a script. Note that this attack vector also does not require any user interaction if the <input> element is down far enough on the page so the “autofocus” attribute will trigger a scroll event. This means the “...” in the code would have to be changed to elements that cause the <input> element to be outside of the display screen. The <br> element is ideal for this, the attack can just insert a large number of these elements to create as many newlines. The vector still works if the “autofocus” attribute is not used, but then the user has to manually scroll. The vector can not work, however, if the page is not large enough for any scrolling to occur.
1 <body o n s c r o l l=a l e r t ( 1 )> . . . <input a u t o f o c u s>
Listing 4.2: The onscroll event gets used to inject script code.
There are also attack vectors that always require user interaction, usually these are less desired by attackers but can still be potent in some cases. Listing 4.3 shows an example of an obvious XSS attack vector that requires the user to press a button.
1 <form><button f o r m a c t i o n=” j a v a s c r i p t : a l e r t ( 1 ) ”>C l i c k Me</button>
Listing 4.3: XSS vector that requires the user to click a button.
Some HTML elements that have onload events, will fire the event even without a “src” attribute being specified. In listing 4.4 three examples of these elements are shown, including the old <frameset> element. This element is in the process of being dropped,
but many browsers still support it. Tags like these are often missed by blacklist filters, because they are often forgotten about. When an iframe onload event is used to execute a script, it is executed in the context of the main document, and not in in the context of the iframe. This means it (rightfully so) does not have access to the client-side storage of the iframe domain, cookies of the iframe domain can not by accessed in this manner.
1 <iframe onload=a l e r t ( 1 )> 2 <body onload=a l e r t ( 1 )> 3 <frameset onload=a l e r t ( 1 )>
Listing 4.4: XSS attack vectors that do not require src attributes to launch onload events.
The previous examples were all written in plain characters, but we can also encode the script payload. This can be done to bypass certain filters that a website might have in place. The first attack vector in listing vector in listing 4.5 uses HTML codes to represent the ascii characters; it exploits the “src” attribute to invoke execution. The second one makes use of a base64 encoded payload; it exploits the “data” attribute of the <object> element to do this. The support of data URIs in most browsers allows this attack to be successful.
1 <iframe s r c=”
javascript: 2 alert(1)”></ iframe>
3
4 <object data=” d a t a : t e x t / html ; b a s e 6 4 , PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==”> </ object>
Listing 4.5: An XSS object attack vector, using base64 encoded data.
The “srcdoc” attribute of iframes is similar to data URIs and can be used to render HTML code inside the iframe. It essentially creates a pseudo-document inside the iframe. Whenever the “srcdoc” attribute is specified in an <iframe> element, it will overwrite the “src” attribute (if it is included). The script injected with the use of “srcdoc” will run inside an iframe with an artificial (dummy) origin, and as such will run in this context. The local storage of the main domain can not be accessed. The example in listing 4.6 uses a onerror iframe injection inside the iframe that is HTML entity encoded (in a different way than in the previous example).
1 <iframe s r c d o c=”& l t ; img s r c&e q u a l s ; x : x o n e r r o r&e q u a l s ; a l e r t&l p a r ;1& r p a r ;& g t ; ” />
Listing 4.6: Encoded attack vector exploiting the iframe srcdoc attribute. Also special HTML tags can be used to do script injection; these tags start with characters such as !, ?, / and %. The special tags are used for various purposes, among which DTD, XML-declaration, comments and closing tags. These tags seem to inherit
certain properties from the standard models [94]. Listing 4.7 shows three attack vectors that exploit these special tags and work in the current versions of the browsers. The tags can be used for obfuscation and filter bypassing .
1 <? f o o=”><s c r i p t >a l e r t ( 1 ) </ s c r i p t >”> 2 < ! f o o=”><s c r i p t >a l e r t ( 1 ) </ s c r i p t >”> 3 </ f o o=”><s c r i p t >a l e r t ( 1 ) </ s c r i p t >”>
Listing 4.7: Example of three attack vectors exploiting special tags.
The OWASP filter evasion cheat sheet [95] can be consulted for methods of evading filters. It offers an extended list of obfuscation mechanisms for various types of input and is aimed at helping application security testing professions with a guide to assist in cross site scripting testing. The code fragment in listing 4.8 demonstrates how an embedded newline character can be used to break up the XSS vector; it will still invoke the alert function because the browser will automatically remove the newline character within the attribute. Many of these filter evasion techniques exist; their workings are, however, dependent on the filtering technique that is used by the hosting server and the browser that the user accessing the document uses. Discussing more obfuscation techniques is beyond the scope of this thesis, as we wish to make recommendations about best practices and not go into detail about all the possibilities.
1 <IMG SRC=” j a v
 ; a s c r i p t : a l e r t ( ’ 1 ’ ) ; ”>
Listing 4.8: XSS obfuscation by using an embedded newline.
One last attack vector that we discuss is referred to as auto-XSS. If a website’s URL is vulnerable to XSS attacks and the website allows being loaded into an iframe, an auto-XSS attack vector can be created. On another website that the user visits an iframe can be opened with the XSS payload already injected into the URL; which could be used for many malicious purposes, such as data theft.