Posted by: Anshuman Singh, Product ManagerMost of us are used to seeing HTTP parameters in a URL of a Web page and usually think nothing about the name value pairs. Consider a request coming in from the client
http://www.example.com/cgi-bin/test.cgi?par1=val1&par2=val2For the above example, the web servers will parse the query string part of the request and break them down into name/value pairs for the web application to consume. So application will receive two parameters par1 and par2 with values val1 and val2 respectively. What happens if we were to overload a parameter with multiple values? Consider the following case:
http://www.example.com/cgi-bin/test.cgi?par1=val1&par1=val2The only change in this case is that parameter par1 appears twice, once with value val1 and again with value as val2. Now in this case what does the application see? The answer depends on the platform used on the Web server. Refer the table below:
[Reference: https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf]Because of the lack of standardization on how to handle overloaded parameters, hackers can leverage the different ways of handling the multiple parameter instance to evade security systems and attack the application. For example, in case of ASP.Net /IIS setting a hacker can send a request like:
http://www.example.com/cgi-bin/test.cgi?par1=<script&par1=src=”...”> …The application will see parameter par1 with the value of <script src=”….”> this can be further customized to create a full-fledged XSS attack. If a Web Application Firewall was installed in front of this application it will normally check each instance of the parameter individually for injection attacks. In this case, it will be looking at ‘<script’ and say “No – this is not an attack and then look again at ‘src=”…”’ Value and consider that safe as well. However, when the request is received by the ASP.Net/IIS servers, it is concatenated to form a <Script src=”…”> block that can then inject an XSS attack command into the application. Solution To protect against these types of attack the Barracuda Web Application Firewall has mechanisms to enforce ‘Parameter instance count’. By default, this should be set to 1. With this setting, the Barracuda Web Application Firewall will monitor the various HTTP parameters to ensure that there is only one instance of any given parameter such as par1 or par2, thereby preventing any HTTP Parameter Poluttion attempts. We think this is a small but a very important feature that will help the administrators to secure their Web applications against the HTTP Parameter Pollution attacks. To find out more, go to www.barracuda.com/webapplicationfirewall or talk to one of our product specialists at 1 408 342 5400.