File Size Restriction Bypass via MAX_FILE_SIZE Parameter Manipulation

Hey everyone!

I'm back with another interesting vulnerability that I discovered during a recent VAPT assessment. Today, I'll be sharing a simple but impactful file upload vulnerability that many developers often overlook.

Let's get started!

While performing security testing on an application, I came across a file upload functionality. As many security researchers know, file upload features are always worth investigating because even a small mistake in implementation can lead to serious security issues.

I started testing the upload feature with different approaches:

• File type restriction bypass
• Uploading malicious files
• EXIF data manipulation
• File size restriction bypass
• Content replacement techniques

Initially, everything looked secure. The application properly rejected malicious file types, and the server-side validations appeared to be working correctly.

At first glance, it seemed like there was nothing to find.

The Interesting Discovery

Since file size restrictions are commonly implemented incorrectly, I decided to spend more time testing that area.

I tried several techniques:

• Uploading files larger than the allowed limit
• Uploading a small file and replacing it with a larger one
• Modifying request contents to increase the overall size
• Replaying upload requests with modified payloads

Unfortunately, none of these methods worked.

The application continued rejecting oversized files.

While reviewing the intercepted request in Burp Suite, I noticed an interesting parameter:

MAX_FILE_SIZE

The parameter contained the maximum allowed file size in bytes.

Example:

MAX_FILE_SIZE=1024000

This value represented approximately 1024 KB.

That immediately raised a question:

Was the server trusting this client-supplied value?

Testing the Theory

To verify this, I performed the following steps:

1. Uploaded a valid small file.
2. Intercepted the request using Burp Suite.
3. Located the MAX_FILE_SIZE parameter.
4. Modified its value to a much larger number.
5. Replaced the original file content with a larger file.
6. Forwarded the request to the server.

And surprisingly…

The upload was accepted successfully.

The server trusted the user-controlled MAX_FILE_SIZE parameter instead of validating the actual uploaded file size on the backend.

The file size restriction was completely bypassed.

Steps to Reproduce

1. Navigate to the file upload functionality.
2. Attempt to upload a file larger than the permitted size.
3. Observe that the application rejects the upload.
4. Upload a smaller valid file.
5. Intercept the request using Burp Suite.
6. Locate the MAX_FILE_SIZE parameter.
7. Change its value to a larger size.
8. Replace the original file with a larger file.
9. Forward the modified request.
10. Observe that the upload succeeds.

Impact

Successful exploitation of this vulnerability may allow an attacker to:

• Bypass file size restrictions.
• Upload excessively large files.
• Consume server storage resources.
• Abuse the upload functionality for unauthorized content storage.
• Cause performance degradation.
• Potentially trigger Denial-of-Service (DoS) conditions due to resource exhaustion.

Root Cause

The application relied on a client-controlled parameter (MAX_FILE_SIZE) to enforce security restrictions.

Since users can easily modify HTTP requests using tools such as Burp Suite, any validation based solely on client-supplied values should never be trusted.

Recommendations

To prevent this issue:

• Perform file size validation entirely on the server side.
• Never trust client-supplied parameters such as MAX_FILE_SIZE.
• Verify the actual file size after receiving the upload.
• Reject files that exceed the configured limit regardless of request values.
• Implement centralized and consistent file upload validation controls.
• Log and monitor suspicious upload attempts.

Tips for Security Researchers

During file upload testing:

• Review every request parameter carefully.
• Don't ignore hidden fields or seemingly harmless values.
• Compare client-side validation with backend behavior.
• Test whether request parameters influence security controls.
• Think from a developer's perspective and identify shortcuts that may have been taken during implementation.

Many vulnerabilities are hidden in plain sight and are often missed because testers focus only on the obvious attack vectors.

Conclusion

This vulnerability demonstrates how a small oversight can completely undermine an otherwise secure implementation. The upload functionality appeared secure at first, but a single user-controlled parameter was enough to bypass the intended restriction.

Always remember:

Never trust client-side controls, and never assume a parameter is harmless until you've tested it.

Happy Hunting!