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

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('"', "");
       }
</script>

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

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!

Problems

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.