ProxySG/ASG/SGVA returning hexadecimal encoded escape characters under exception page
Article ID: 175198
Updated On:
Products
Issue/Introduction
When ProxySG/ASG/SGVA returns an exception page as a result of exception policy match, HTML ASCII characters are being replaced by hexadecimal encoded escape characters. For example, when SG returning a policy deny exception with "Your request url $(url)", exception page looks like below:
<html>
<head>
<title>Denied Access Policy </title>
<meta name="author" content="Example Company">
<meta name="description" content="Denied Access Policy">
</head>
<body>
<center>
<p>
<font face="Arial, Helvetica, sans-serif" size="3" color="Black"><b> Your IP address: x.x.x.x
<br>Your request url http://www.example.com/</b><br>Your request url category Technology&#x 2F;Internet</b></font>
</center>
</body>
</html>
Instead of returning 'Your request url http://www.example.com/' it returns 'Your request url http://www.example.com/'. Here SG is replacing unsafe character '/' with escape charecters '/'
Resolution
This is expected behavior starting from SGOS 6.7.4.2 and higher versions. As part of security tightening to prevent XSS (cross site scripting) attack, starting with SGOS 6.7.4.2 unsafe (sensitive) HTML characters such as “<“, “>”, “&” , "/" ,whitespace etc will be replaced with hexadecimal encoded escape characters. SG will modify unsafe HTML character when it's retuning its own HTML resources such as exception pages. By default this does not apply when SG returning a HTML response from OCS (Origin content server). Most modern browser are capable of converting this escape characters back to the original ASCII charecters, hence when above exception page is returned back to the browser it will be rendered with original ASCII charecter i.e 'Your request url http://www.example.com/'.
In above example if $(url) would hold an integer value, there would be no risk. The problem arises when $(url) holds a string (in this case it holds request URL) that contains HTML sensitive characters which are vulnerable to XSS attacks.
More information related to XSS (Cross Site Scripting) Prevention techniques can be found on Open Web Application Security Project (OWASP) Website.
Feedback
