Hidden Treasures: Not So Hidden
For years now, I have run into developers that believe that just because a request can’t be seen, it is not vulnerable to flaws. Wait, what are we talking about here? What do you mean by a request that can’t be seen? There are a few different ways that the user would not see a request. For example, Ajax requests are invisible to users. What about framed pages? Except for the main parent, all of the other pages are hidden from the user’s view. These are what I would call hidden requests.
Lets use a framed site as an example. Lets say that a page has multiple frames embedded in it, each leading to a different page of content. From a user perspective, I would normally only see the URL in the Address Bar of the parent page that contains the other frames. Although each frame has its own URL, I don’t see it natively. This type of out-of-site out-of-mind thought process often leads us to over look the security of these pages.
There are all sorts of vulnerabilities that can be present in the scenario above. I have seen SQL injection, Direct Object Reference and Authorization issues. BUT THEY ARE HIDDEN??
To the naked eye, yes, they are hidden. Unfortunately, there are numerous tools available to see these requests. Web Proxies are the most popular, although there are some browser add-ins that also may do the trick. The two proxies I used the most are Burp and Fiddler. Both of these tools are used to intercept and record all of the HTTP/HTTPS traffic between your browser and the server. This means that even though I might not see the URL or the request in the browser, I will see it in the proxy.
Many years ago, I came across this exact scenario. We had a website that used frames and one of the framed pages used parameters on the querystring. This parameter just happened to be vulnerable to SQL Injection. The developer didn’t think anything of this because you never saw the parameters. All it took was just breaking the page out of the frame and directly modifying the value in the address bar, or using a proxy to capture and manipulate the request to successfully exploit the flaw.
It was easy to fix the problem, as the developer updated his SQL to use parameterized queries instead of dynamic SQL, but this just shows how easy it is to overlook issues that can’t be seen.
In another instance, I saw a page that allowed downloading files based on a querystring value. During normal use of the application you might never see that request, just the file downloading. Using a proxy, it was easy to not only identify the request, but identify that it was a great candidate for finding a security flaw. When we reported the flaw, I was asked multiple times about how I found the flaw. It was another case where the developer thought that because the request wasn’t displayed anywhere, no one would find it.
There are many requests that go unseen in the address bar of the web browser. We must remember that as developers, it is our responsibility to properly secure all of our code, whether or not they appear in the address bar. I encourage all developers to use web proxies while testing and developing their applications so they can be aware of all the transactions that are actually made.
Comments
Follow Us
