Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: webapp

Detecting probes through client-side filtering

In security terms, client-side filtering is often laughed at as trivial to bypass and not helpful in security terms. On the flip-side, many websites still implement client-side checks to help improve the customer experience. After all, there’s no need to send a form through to the server just to check if the client filled out the email field correctly! Client-side validation is here to stay, so why not use it to make sites more secure?

I can almost hear the screams from here…. yes I said it… use client-side filtering to make websites more secure from attackers. Give me a minute and I’ll explain my thoughts!

Everybody knows that bypassing client-side filters is as easy as taking candy from an asthmatic baby! So, given that attackers can easily bypass the filter and send whatever they want to send to the server, how can we use the act of bypassing these filters to improve the level of security of our websites.

To illustrate the point I’m going to use this simple example.

<script type="text/javascript" >
       function sanitizeForm() {
               var name = document.getElementById('name');
               var comment = document.getElementById('comment');

               # Filter unwanted characters ' and " from input
               name.value = name.value.replace("'", "");
               name.value = name.value.replace('"', "");
               comment.value = comment.value.replace("'", "");
               comment.value = comment.value.replace('"', "");

<form id="form1" name="form1" method="post" action="" onsubmit='sanitizeForm()'>
     <input type="text" name="name" id="name" />
   <br />
     <textarea name="comment" id="comment" cols="45" rows="5"></textarea>
     <input type="submit" name="submit" id="submit" value="Submit" />

For those looking at the above code blindly, all this example does is take input from a user and filter out any ‘ or ” characters before submitting it to the server-side. Now any security tester worth his salt is going to see that and start rubbing his hands together in glee. This sort of filtering is a simple (and rather ineffective) protection from SQL injection attacks. Now, we all know this can be bypassed, and that’s what we’re counting on here.

The key here is to make traffic from a penetration tester or attacker stand out from that of a normal web user. Where any normal user would simply fill in the form and allow the client-side filtering to strip out any ‘ or ” characters, an attacker would purposefully ensure that those characters were sent to the server using a transparent proxy or any other solution to hand (scripting, etc…). At this point it becomes obvious at the server-side that traffic submitted through this form containing characters that should have been stripped, is indicative of an attacker (or somebody just playing about with the application). As long as you’re doing suitable filtering on the server-side, this bypass of client-side protections is incidental to the security of the website as a whole, and only serves as an early warning system of sorts.

What you do with that information is up to you. The choices range from logging and alerting on the attempt, through to blocking the IP address or forwarding the session to a honeypot system for detailed analysis. The possibilities are limited only by your imagination, and just how evil you want to be. Blocking a users session is obvious and a determined attacker is going to come back from a new source IP and a whole load of new tricks. Forwarding them to a specially controlled honeypot version of your application sounds like a lot more fun however. With some limited functionality, some tasty false positives and a few endless loops! I’m sure you could keep them spinning their wheels till they get bored and move on! After all, sometimes that’s all be can hope for!


This solution comes with its fair share of issues, the main one being how we deal with users who have either purposely or accidentally disabled JavaScript support on the client. This could be the case for users of NoScript, or some mobile / outdated browsers that don’t correctly support JavaScript in all instances. Working in solutions for these users is something I’ll leave to as an exercise to the reader. However this isn’t the first time application developers have had to work around these issues, so I’m sure there’s a range of solutions in place.


UAtester now in Backtrack 5!

Just a quick one to say that those interested in testing out the UAtester script can find the latest version in the newly released Backtrack 5. It’s a real honor to get UAtester accepted to a distribution like Backtrack, so I hope you guys enjoy and make use of it!

Menu Location ::

Backtrack | Information Gathering | Web Application Analysis | IDS IPS Identification


UATester Alpha

Well I’ve held out long enough tweaking and playing, it’s time to hang my head in shame and release my UA-Tester Script for the world to laugh at and play with.

A few things before I run through what the tool does and why I thought it was worth writing.

  • This is only my second attempt at Python scripting, so don’t expect quality smooth code (yet)
  • It’s an Alpha release…. i.e. it will probably suck and never work.
  • I wrote this because I want to improve my Python fu.
    • I’d love constructive criticism
    • Hints and requests are always well received… but may be ignored 😉
    • If you hate it, fail to see the point in it, or are just generally negative –> rm UAtester.py

So with that out of the way, what is UA-Tester?

UA-Tester was something I’ve been thinking of for a while due to the increase in mobile technology. A number of high-profile sites (twitter, facebook, google, and even Microsoft) offer mobile versions of their sites and functionality. Normally this wouldn’t be something you’d care about, but as a penetration tester or security researcher, you need to make sure you’re covering all the bases and getting full coverage when looking at web applications. I’ll give some examples in the following sections that should help clarify things I hope.

As you can see in the screenshot, UA-Tester will begin by connecting to the URL provided to it through the command line and returning some information about what response it receives. It does this initial connection using a standard (non-specific) user-agent string (in this case Mozilla/5.0). As you can see in the screenshot, the tool returns the final URL (in this case different from the one entered through the command line), as well as the initial response code (302 Found) and information such as Content-Type, Server header (if present) and the length/MD5 of the data portion of the response. I’m currently looking to expand this to also check and return headers such as X-XSS-Protection, cookie names and others that might be useful (cache, etc…).

The tool will then re-run the same request 3 times to ensure that the response are stable (to prevent false-positives in the event of advertising, rotating content, or general connection issues). Without stable responses, it’s hard to tell if the site is responding differently depending on the user-agent string used.

With the foundations completed, the tool will then check the URL provided using either a list provided by the user (-u at the command line, example .: -u ./useragents.lst) or a collection of default user-agent strings (and by default I mean, a random and interesting selection I’ve been using for testing) if no filename is given. It is also possible to pass the -s option and provide a single user-agent string to test (example .: -s googlebot/2.1).

A connection is made using each of the supplied/default user-agent strings in turn, and the differences between the original reference connection, and the new user-agent string are returned to the user. It is also possible to use verbose mode to see the entire dataset returned for use in manual data gathering or correlation.

The results of this are then returned to the user showing the User-Agent string being checked and any responses that differ from the reference connection (the one used to check the stability of the connection).

As you can see by the screenshot, using the user-agent string “jBrowser-WAP” the remote server (in this case http://www.microsoft.com) responds with a different final URL (forwarding the user to a mobile version of the site) and also shows that the version of IIS in use is now 7.0 instead of the originally reported IIS 7.5. This could offer a number of advantages for penetration testers as you can imagine. Not only are mobile versions of web applications commonly less secure (missing protections against things like click-jacking for example), but as can be seen here, may also offer a completely new Infrastructure that could be vulnerable when the main site isn’t.

Now, what this script does is nothing new. I’m sure most readers here are already aware that this can be achieved through the use of something like Burp Intruder. Hope fully though, you’ll find this tool at least mildly useful for initial checks and scoping. I know it’s something I’ll be using to make sure I’m covering 100% of the application and functionality and not just limiting myself to the homepage as seen from Internet Explorer or Firefox.

./UATester.py -h

This tool is designed to automatically check a given URL using a list of standard

and non-standard User Agent strings provided by the user (1 per line).

The results of these checks are then reported to the user for further manual

analysis where required. Gathered data includes response codes, resulting URL in

the case of a 30x response, MD5 and length of response body, and select Server headers

Usage .:

-u / –url Complete URL

-f / –file <Path to User Agent file> / If no file is provided, defaults will be used

-s / –single provide a single user-agent string (may need to be contained in quotes in specific circumstances)

-v / –verbose results

–debug See debug messages

Example .:

./UATester.py -u http://www.example.com -f ./useragentlist.txt -v

./UATester.py -u https://www.yourserver.com

./UATester.py -u http://www.defaultserver.com -v –debug

./UATester.py -u https://www.google.com -s “MySpecialUserAgent”

I’d like to thank all the Alpha testers who helped with the fine tuning and comments so far… @Digininja, @Markofu, @DaleaPearson@Acanthephyra, and others. Much appreciated!


  • Sort the output… not happy with the current way data is returned to the user (confusing, too much data for a table)
  • Output to a logfile for offline correlation (XML ?)
  • Add proxy support
  • Check and return information on additional headers, cookies and cache directives
  • Possibly work on integration with W3AF (Already Python based)