BOOK THIS SPACE FOR AD
ARTICLE ADWelcome back to my new article! I’m Mohammed Nafeed, a bug bounty hunter.
So today, we’re going to explore an intriguing vulnerability that many bug hunters tend to overlook & It is nothing but an input validation bypass.
What is Input Validation ?
Input validation is the process of checking user-provided data to ensure it meets required formats and constraints. It’s essential for security, preventing issues like SQL injection, cross-site scripting (XSS), buffer overflow, command injection, and directory traversal.
Many bug hunters, when they usually test websites and come to the registration or sign-up page, if the website doesn’t allow special characters in the first name or elsewhere, they usually log in using normal words for further testing. But wait, why the hurry there? It’s like you are leaving a vulnerability and going to test another vulnerability which might become a duplicate after reporting…LoL…just for fun But take it serious!
As a bug hunter, it’s essential to test every endpoint and functionality, especially during manual testing. When using XSS payloads or other exploits, they often contain special characters like `<`, `>`, `/`, `\`, `*`, `{`, `}`, and `#`. If you try to use these in input fields like first name, last name, or any other, and the validation fails with an error stating that special characters are not allowed, it’s an indication that the input validation process is in place.
Now let’s go deep into how to bypass this restriction.
What is Input Validation Bypass ?
Input validation bypass is a technique used to circumvent the security measures that check user input for proper formatting and content. This can lead to serious vulnerabilities such as SQL injection, XSS, remote code execution, and command injection. It is crucial to ensure that input validation is robust to prevent data corruption, system crashes, and security breaches.
When a normal input validation bypass occurs without any impact, it’s typically considered low or informational. However, if it can be chained with other vulnerabilities such as SQL injection, XSS, or RCE (remote code execution), the severity escalates from high to critical levels.
Some Normal Technique To Bypass Include :
Encoding and Decoding: Using different encoding techniques (URL encoding, Base64 encoding) to bypass filters that are designed to block special characters.Whitespace Injection: Inserting spaces, tabs, or newlines to bypass validation checks that don’t account for whitespace.Null Byte Injection: Using null bytes (%00) to terminate strings early and bypass validation checks.Character Encoding Manipulation: Employing different character encodings or Unicode characters that may not be properly validated or filtered.HTML Entity Encoding: Using HTML entities (<, >, &) to bypass filters that block specific characters.Unicode Encoding: Using Unicode representations of characters to bypass filters that are not Unicode-aware.Double Encoding: Encoding characters twice to bypass filters that only decode once.Using Escape Sequences: Employing escape sequences like \x or \u to bypass input validation.Now here comes the secret part: bypassing the input validation where many bug hunters aren’t familiar.
So, when you enter the payload or links in the input field, the system typically rejects them due to special character restrictions. However, using Burp Suite, you can intercept and submit the signup or registration form. Once the request is successfully captured, send it to Burp Repeater for testing. Turn off interception, navigate to the captured request in Burp Repeater, and then manipulate the request as needed for further testing.
POST /signup HTTP/1.1Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: [length]
first_name= md
last_name= nafeed
address= 403 area-51 USA
email=test@example.com
your request normally looks like this.
Now manipulate the request like
POST /signup HTTP/1.1Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: [length]
first_name= https://evil.com
last_name= <script>alert('XSS')</script>
address= /etc/passwd
email=test@example.com
Now send the request to the server and see thew result. if the website is vulnerable to this manipulation then you did a input validation bypass using this technique.
If the server response is 400 bad request or anything try to change POST TO GET or GET to POST method.
Why this happens?
This happens mainly because the developer has implemented front-side input validation checks but not server-side checks. So, when you send the modified data to the server, you have already bypassed the front check .
By doing this, we are breaking the developer’s logic. The developer assumes that front-side checks are sufficient, thinking that no one can add payloads to exploit other vulnerabilities.
But some developers don’t realize that they should also implement server-side checks.
Note: When you enter special characters in the signup page, client-side validation (like JavaScript) blocks them, saying “no special characters.” However, when you capture the request with Burp Suite, add special characters to fields like `first_name`, and resend it, you get a 200 OK response. This happens because the server lacks proper server-side validation to block these characters, making it a security vulnerability.
So from next time, try using this technique; you never know what vulnerability you might discover, like SQL injection, XSS, LFI, SSTI, etc.
Thus you can successfully bypass this type of restriction.
Thank You !