Fiddler - Never Trust the Client
It never ceases to amaze me how many developers make the fatal mistake of trusting security to code which is run on the client side (our own computers). The most obvious example of this would be something like web form validation, which should only be implemented on the browser for usability purposes - whereas server validation should always be in place (since client side code can be tampered with).
Aside from form validation, many websites/Flash, and other applications also communicate with remote servers, and the security of such applications presumes that we are unable to see and tamper with this communication. Not the case!
One method we can use to illustrate/highlight and exploit such vulnerabilities is to examine HTTP(S) traffic between our computer and the Internet, so we can see how client-side code running on our machine is interacting with remote servers.
Let me introduce you to Fiddler (www.fiddler2.com). Fiddler is a web debugging proxy, which allows you to examine all HTTP(S) traffic from your machine. Fiddler also allows you to "fiddle" and tamper with such communications, so that you can spoof requests and responses to and from remote machines, thus tricking code which is run locally on your machine, or indeed the server. It's one of the best tools you can have for spotting this type of vulnerability. Using Fiddler, I have previously been able to do all sorts of things like intercept and modify requests from Windows applications to remote servers to authenticate serial numbers (server says invalid, I intercept and change to valid), spoofing high score submissions from Flash games to be significantly higher than I actually achieved and more.
O.K., now for an example, I'm sure some of you (whilst mindlessly browsing the Internet) would have come across a rather scammy page which asks you to "complete one of our amazing offers to continue." No? Well, these things are out there, and I found such a URL after some Googling and will be using it for my example.
I'm going to make this an introduction to what you can do with Fiddler, rather than a complete tutorial (I'm sure you are all capable of researching it further!). So upon loading Fiddler, and then loading this scam URL in my browser, I can see that it is periodically making a remote server call (/?a=check&session_id=84036). Pretty obvious what's going on here! You could spot these using Chrome's InspectElement feature or Firebug, also.
I can also see that the response from the server is:
{"complete":false,"leads":"0"}
|
Could they have made it any easier?
This is a clear example of poor security awareness on their part, as they are trusting my browser to check with the server on my progress completing one of their offers, and then allowing the server response to trigger their site (as loaded on my browser) to continue.
Note: I'm sure there are multiple ways of hacking/tricking this site, but I will stick with this method to illustrate what you can do with Fiddler.
Using Fiddler, I enable the "Auto Responder" feature, which allows you to return your own content based on a certain type of request (you can target specific requests or set REGEX filters). It's as easy as enabling this feature and then pressing "Add" with the request above highlighted. It will then set up an auto response based on this server call from the scam site.
You can then choose what response will be returned once this request is intercepted. I created a TXT file containing just this:
{"complete":true,"leads":"1"}
|
and set this as the content to be sent back when this request was next made. I then immediately got this result in my browser:
I can then continue to press "Get Password" and it miraculously displays it to me, despite having every opportunity for the server itself to validate the fact that I had completed an offer before returning the password.
I hope then that I have made a couple of things clear: firstly, that Fiddler is a very useful tool; and secondly, that you should never trust client side code with your security!