If You Can’t See the Mess Then There is No Mess!?

For those who know me well, it is not a secret, that I am a little disorganized. Not with extreme level but as I call it: “I have my own (messy) way to organize my stuff”. Things get complicated when my wife gets into the picture, well… she is very organized and not always appreciate my special organization techniques. One of my techniques includes the philosophy of “if you can’t see the mess then there is no mess”, the problem with such an approach is that over time it tends to fail, the mess tends to be revealed  sooner or later and results with me getting the hit (gracefully).

This leads me to some web application security examples I got across lately.

In the first example, I noticed a Cross-Site Scripting vulnerability that was badly patched (see more details below), while mitigation clearly solves injection for some XSS attack payloads, other attack payloads are still exploitable leaving the vulnerability not fully mitigated.
   

On an entirely different case, I was able to see an HTTP parameter that looks like it contains encoded value, when looking into that HTTP parameter I could see that it was double hidden with the same easy-to-decode encoding technique (encoded twice). In other words, 2 blanks full of holes were used to cover a Cross-Site Scripting vulnerability in this parameter assuming that way no one will find it.

While my personal “organization” techniques can (in some cases) be accepted in forgiveness, uncompleted patching of security vulnerabilities or the usage of obfuscation techniques is an unnecessary risk that may result with real damage to application’s users and application administrator.       

At this point a cheap gesture is essential so…

Honey, the love of my life this blog is far from truly expressing my love and respect for you!

      

XSS example

When trying to inject several attack vectors (for example: <script>alert(1)</script>) the request is being blocked, but when trying to send attack vector that looks like <img src= onmouseover="alert(1)"> the request is not being blocked. From my experience in many cases this kind of mistakes are done when the process of mitigation vulnerabilities is performed in a limited time frame when the goal of passing the security audit.

Base64 example

When looking into that HTTP parameter I could see that it was double encoded in base64 and as you know based64 encoding can be easily decoded. When sending XSS attack vector double encoded in that parameter I can see that it is vulnerable to XSS. As far as I understand, the mitigation was done that way since application developer wanted to avoid detection of the vulnerability in his code, therefore he used a security by obscurity approach.
While one level of encoding vulnerability can be found easily by almost any given web application scanner, double encoding requires special configuration to scanner and therefore most likely won’t be found.