AttackFlow Findings Dictionary

Finding A Way To Try AttackFlow Enterprise Edition?

If so, click to download 15 days full version for free!

Potential Unsafe Decoding

The double decoding or unnecessary decoding process may increase the likelihood of an attacker bypassing the web application firewalls or security filters

Severity

Medium

Fix Cost

Medium

Trust Level

Low

Generally web application firewalls or security filters are utilized to secure web applications providing zero-touch to the source code for actually securing it. These are obviously weak and unfortunately insecure mechanisms. Since there ise always a strong possibility to bypass rule/dictionary based security filters as the history shows.

Although security filters generally employ blacklisting behaviours and as such insecure, we, developers, like to use them since they seem to be centralized and easy to implement.

One more reason to bypass security filter rules is to pass encoded attack strings to the target application that the filter will not understand. It has to decode first, which is usually underestimated because of mainly performance issues and existence of different ways of encodings.

                                     
HttpCookie aCookie = Request.Cookies["corss"];
string corss = Server.UrlDecode(aCookie.Value);
processCookieValue(corss);
Uri uri = new Uri("http://www.vulnerable.com/check3w?id=" + corss);
WebRequest webRequest = WebRequest.Create(uri);
                   
            

The above code takes a user input from the cookie and URL decodes it before sending to an external URL. Here by sending a double encoded cookie value to this code, such security filters may be bypassed since they will not double decode it before analyzing.

However, the framework will URL decode the value implicitly once when the developer fetches it with aCookie.Value. And again when Server.UrlDecode method is called getting the original value just before the attacker send it before double encoding.

Generally web application firewalls or security filters are utilized to secure web applications providing zero-touch to the source code for actually securing it. These are obviously weak and unfortunately insecure mechanisms. Since there ise always a strong possibility to bypass rule/dictionary based security filters as the history shows.

Although security filters generally employ blacklisting behaviours and as such insecure, we, developers, like to use them since they seem to be centralized and easy to implement.

One more reason to bypass security filter rules is to pass encoded attack strings to the target application that the filter will not understand. It has to decode first, which is usually underestimated because of mainly performance issues and existence of different ways of encodings.


public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException  {
 
Cookie[] cookies = request.getCookies();
Cookie corssCookie = GetCookie(cookies, "corss");  
String corss = URLDecoder.decode(corssCookie.getValue());
 
ProcessCookieValue(corss);
 
URL url = new URL("http://www.vulnerable.com/check3w?id=" + corss);
HttpsURLConnection con = (HttpsURLConnection)url.openConnection();
 
...
}
    

The above code takes a user input from the cookie and URL decodes it before sending to an external URL. Here by sending a double encoded cookie value to this code, such security filters may be bypassed since they will not double decode it before analyzing.

Same style of coding is also present in controllers’ action method parameters in Spring MVC if the type of the HTTP request is not restricted.

However, the framework will URL decode the value implicitly once when the developer fetches it with corssCookie.getValue(). And again when java.net.URLDecoder.decode method is called getting the original value just before the attacker send it before double encoding.

Finding A Way To Purchase AttackFlow Enterprise Edition?

If so, click to buy now for yearly subscriptions!