step 8: Bypassing the client side validation
Welcome to the 8th post of the 6M Challenge of Bug Bounty edition where you are going to learn about client side validation and how to bypass it with a lot of examples. I am sure you will love this post and will bookmark it. I hope that you have finished the tasks given in the previous post, i.e.:
- Read up and try commands of Nmap on several websites.
- Try usage of Nikto.
- Use Burp Suite spider, see what kind of files you can find on your favorite websites.
As you must remember from Part 5, that the biggest reason which causes most vulnerabilities in web applications is that they take input from us. And developers know about this, that’s why there are several layers of security validation in every web application. Client-side validation, firewalls, and server-side validation are broad terms used to describe these.
NOTE: Follow this series in order of articles and move to next only after you’ve understood the previous one. Read stuff twice and thrice if you don’t understand.
Today we’ll take a look at the client-side validation and how to bypass it.
client side validation
Client-side validation is when Javascript and HTML are used to check your input for any problems. Without contacting the server, everything is done on the client machine; like when you enter text into the email field which isn’t email but rather something potentially malicious. For example- (see image below)
Most of the web applications look for format- “abcd@xyz.com”, which is a mixture of string, “@” symbol, and a domain. HTML 5 forms automatically look for this kind of input in email fields, and Javascript can be used to throw an error if the email doesn’t look like an email, like in the example above. This is one of the simplest client-side validation techniques.
Other similar kinds of validations are:
- Character limit: You wouldn’t want phone numbers to be longer than 15 characters and passwords to be shorter than 6.
- Character type: Allowing only numbers in the phone number field.
Finding the XSS bug
A bit more complex kind of validation would be, cropping out suspicious characters. For example- “<” and “>” are classic sus characters in web security, simply because of XSS. We’ll study XSS in detail real soon. But note that, if you enter this string into an input field- “”, and if there are no security checks on it, and the website prompts an alert box with ‘hi’ in it, then CONGRATS! you’ve found the XSS bug.
XSS is one of the most popular bugs in web applications. That’s why every developer keeps “<” and “>” symbols out of their system. How do they do this? One of the ways on the client-side could be by removing greater than and less than symbols from a string. For example– If I enter “” into a search box, Javascript will remove the symbols and only process “script alert script”, ignoring all the symbols, hence protecting the web application from XSS attacks.
There are can be hundreds of variations of this kind of validation system. Read this article to understand the major client-side validation methods. Please do read it. – https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation
The job of this article is to give you an easily understandable template through the examples and theory we’ve given above. Your only job is to understand this, and then read the in-depth articles we provide so that you understand the in-depth article very well.
aTTACK: how to bypass client-side validation?
Alright, now that we’ve understood the security systems, let’s see the easiest method to crack through this kind of security. You must remember from the Burp Suite tutorial, that every time you want to interact with a web server, the information is sent in the form of an HTTP request to the server from the browser. And using Burp Suite, we can intercept that request and make potential changes to it.
Fortunately, these inputs go through HTTP requests as well, so we’re gonna exploit this property of the input system to bypass client-side validation. So, I turn the Burp Suite on with my browser. I open the webpage and enter a valid email that looks like an email and passes through the client-side validation without any issues.
Then I clicked on the login button, but since the burp suite is open, the request gets intercepted. I switched to Burp Suite and find this email field. Here I find abcd@lmao.com and replace it with a potentially malicious string that isn’t an email, and then click on the Forward button.
This string successfully reaches the server and gets processed. Although there are other levels of security like firewall, and server-side filters. But this is how we bypass client-side validations.
Client-side filters are pretty weak since almost all such filters can be bypassed using methods like above. That’s why firewall and server-side checks are important. Using this exact exploit, a hacker was able to enter phone numbers, emails, or torrent links into the URL field in this report- https://hackerone.com/reports/500348 – Got paid 100$ by Slack.
Using the same method in different contexts. An attacker was testing the payment system, and the amount of product was sent from the client-side, using the method, the attacker was able to enter negative values in a few fields, and buy expensive products at 1/5th of the price.
A normal user won’t be able to enter negative quantities because of client-side validation, but if you intercept it with Burp Suite, and change amount values to 00 or negative, maybe it’s vulnerable and you find a bug that allows you to buy stuff at a lesser price or even for free. Here’s the report, read it. Read it twice if you don’t understand- https://hackerone.com/reports/771694
a note to the reader
If you find such bugs, don’t exploit them, instead, report them to the concerned authority. Because by exploiting, you might get a free/cheap product, but it won’t be difficult to track you down. Moreover, it would be illegal, and we at Technical Sapien are good people, right? 🙂 So, never use this knowledge for anything wrong and/or illegal. This is only for educational purposes.
Alright, this is it for today. I have tried to make you understand as much as I can. Hope you learned something new. Let’s move on to the tasks to be completed for the next article.
tasks to be completed:
- Read the article on client-side validations- https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation
- Read the HackerOne reports given above.
- Test a few client-side validation systems on a few websites, on Hackerone or Bugcrowd.