HTML entity encoding . Is it enough?

Recently I was doing  a security assessment for a client. I observed an XSS in the page. The attacker vector was like this

“;confirm(1);//

The attack vector was obviously being embedded in a script tag generated by the application itself.

The script tag went something like this:

<script>user supplied input……some javascript code</script>

I cannot recall exactly the input was embedded but it went something like this

<script> var userinput=”user supplied input”</script>

When the attack vector is input the script tag looks something like this

<script> var userinput=””;confirm(1);//</script>

Note the   // (double forward slash) in the attack vector is used to comment out anything after the attack vector.  

Let’s use the browser’s javascript console to try to understand how the attack vector works.

 

1. Execution of the script

Now if HTML entity  encoding were to be used then the script tag in the response should look like this

<script> var userinput=”&quot;;confirm(1);//</script>

Note the ending double quote(“) i.e. the one supplied by the user was converted to &quot; by HTML entity encoding. Since the syntax of the script is now incorrect,  the script does not run.

2. HTML encoding converted the double quote to ” . This makes the syntax of the script incorrect and the script does not run

However if the input was an integer input then the script tag would look like this

<script> var userinput=123</script>

Notice how there is no double quotes as the variable is an integer.

Adding the following attack vector

1;confirm(1);//

would make the javascript look like this

<script>  var userinput=1;confirm(1);//some javascript </script>

The script will execute as is

3. The script executes. The variable in the script tag is an integer and is thus immune to any HTML encoding

HTML entity encoding will have no effect on the attack vector.

Hence, html entity encoding can not be used as a solution to mitigate XSS in the following scenario.