Multi Reflection XSS

When finding XSS in websites usually we see more than one reflection of our input in source code which can be very useful to bypass several types of filters.

Let’s start with a very simple way to know how many reflections we may have with the same payload:

<svg onload=write(1)>

Example: French Wikipedia Website => 11111111 (8 times).



To make use of these occurrences with tag based injections, we have the following (with the input and the resulting parsing of the vector):

Double Reflection – Single Input

1) p=’onload=alert(1)><svg/1=’

The <svg/1=’ part of the 1st reflection will start the tag and open a fake attribute until it finds another single quote to close it, in our second reflection, with ‘onload=alert(1)>. Of course, there can’t be a single quote between the 2 occurrences (usually the pure HTML part of the source employs only double quotes).


… [code] …



Double Reflection – Single Input (script-based)

1) p=’>alert(1)</script><script/1=’
2) p=*/alert(1)</script><script>/*

The same is valid for injections with script tags, but to avoid the equal sign we have an additional construction that makes use of javascript comments. Unfortunately, this does not work when there’s a native script block between the 2 reflections because the native </script> will break our concatenation.


… [code] …



Triple Reflection – Single Input

1) p=*/alert(1)”>’onload=”/*<svg/1=’
2) p=`-alert(1)”>’onload=”`<svg/1=’

Triple reflections are way more complicated, because having the right conditions between these 3 parts in source code requires a little bit of luck. Also we have to rely on the newly introduced backticks (`) for string delimiting in javascript, which may pose an issue in some cases.


… [code] …


… [code] …



Triple Reflection – Single Input (script-based)

1) p=*/</script>’>alert(1)/*<script/1=’

Also complicated because we have the double possibility of an existing </script> breaking our syntax, although we don’t have to deal with the possibility of double quotes (usually everywhere in the source) breaking our injection like in the previous case.


… [code] …


… [code] …



Multi Reflection – Multi Input

We may also have the reflection appearing via 2, 3 or more different inputs. This is the best scenario, making it very easy to bypass even the anti-XSS solutions of the major browsers.

2 inputs:


3 inputs:

p=<svg 1=’&q=’onload=’/*&r=*/alert(1)’>


Multi Reflection in Javascript Code

Usually, when we have a reflection directly in a javascript piece of code, exploitation is very straightforward and doesn’t require the use of another reflection.

Nevertheless, there is at least one case where it may be useful.

Take the following single lines of code:

var n = {a: “$p”, b: “$p”};
(double reflection, single input $p)

var n = {a: “$p”, b: “$q”};
(double reflection, double input $p and $q)

Even having double quotes being correctly encoded or escaped as well as the less than sign (to prevent breaking the javascript block with </script>), these 2 examples can be exploited:


var n = {a: “-alert(1)}//\”, b:-alert(1)}//\”};



var n = {a: “\”, b:-alert(1)}//”};

* blue is the value of “a”, red is the “out-of-value” area.

See it working here.

The backslash (\) escapes the double quotes that close the first named value “a” and then the value will only end on the next double quote, the first one of the second named value “b”. In this way, what was supposed to be a value, actually becomes code to be executed (“alert(1)”), concatenated to the named value “a”. Finally, to avoid syntax error, we close the variable “n” with “}” and comment the rest of the native code.


There are also mixed cases, with reflections occurring in HTML and inside javascript at the same time with single or multiple inputs. In my private twitter account @brutalsecrets there’s a curious case regarding this last kind of exploitation which may be the difference between a withdrawal and an alert pop-up.


Leave a Reply