When an input field (like an email box) isn't strictly validated, it opens the door for several types of attacks. It's not just about messy data, it's about how the server processes those symbols.
Here are the three biggest risks when you allow any old thing into an input:
1. SQL Injection (SQLi)
If a user enters symbols like ', --, or ; followed by database commands, and your backend isn't prepared, they can trick your database into "leaking" information.
- The Risk: An attacker could bypass login screens or download your entire user list by typing a command into the email field instead of a real email address.
2. Cross-Site Scripting (XSS)
XSS occurs when your application takes malicious code, often JavaScript, from a user's input and renders it on a page without properly neutralizing it. This code then runs in the browser of anyone who views that page.
There are two common types of XSS:
1, Stored XSS:
An attacker injects a malicious script into a field that gets saved to your database, like a user profile bio, a comment, or a forum post.
How it works: Every time a legitimate user views that content, the script executes automatically in their browser.
The Goal: Stealing Session Cookies.
Why Session Cookies Matter:
Think of a session cookie as a Digital ID Card. It tells the server you've already logged in so you don't have to re-enter your password on every page.
Stealing these sessions cookies or "ID Card" allows for:
Account Hijacking: Attackers can bypass Multi-Factor Authentication (MFA) because they are using a session that is already verified.
Data Theft: Accessing private financials, personal info, or private messages.
Impersonation: Performing actions as you, like changing your password or deleting your data.
2, Reflected XSS:
In Reflected XSS: The "Phishing" Attack, the malicious script isn't saved on the server.
Instead, it is "reflected" off the web application to the victim via a crafted link.
- Example: An attacker sends a link like:
http://site.com/search?q=<script>alert('Gotcha!')</script>
How it works: If the search page displays the user's query back to them without cleaning it, the script runs the moment the victim clicks the link.
The Risk: This is primarily used in phishing. It can be used to deface a site, redirect users to a fake login page, or capture keystrokes (keylogging).
3. Buffer Overflows and Logic Errors
This happens when your system expects a certain amount of data but receives far more.
If your application is expecting a 50-character username, but a bot sends 5,000,000 characters, it can overwhelm the memory allocated for that input i.e. cause the memory to overflow.
The Risk/s:
- At best this can crash your service, leading to a Denial of Service (DoS) attack.
- At worst, the memory "overflow" can be exploited to overwrite critical parts of your application's memory, potentially allowing an attacker to execute their own code directly on your server.
Takeaway:
- When we don't limit the size of an input we are risking System Stability as well as risking a messy database.
- Whether it's a memory-safe crash (DoS) or a memory-unsafe exploit (RCE), failing to set a 'Maximum Length' on your inputs is like leaving your front door open during a storm, eventually, the house is going to flood.
How to Fix This (The "Standard" Way)
You don't have to write complex code to stop this. Most modern frameworks do the heavy lifting for you:
- Validation: Check that the input looks like what it should be. For an email, use a Regular Expression (Regex) or a built-in validator to ensure it has an
@and a domain. - Sanitization: Strip out dangerous characters (like
< > ; ') before saving them to the database. - Parameterized Queries: This is the #1 defence against SQL Injection. It treats the input as "plain text" only, so the database never tries to "run" it as a command.
Use both Sanitization and Validation. Ask:
"Are we using Parameterized Queries and Input Sanitization on this new form?"
The Ideal Workflow:
- Front-end: A simple check to ensure it looks like
name@domain.com. - Back-end: Strip dangerous characters (sanitization) before it touches the database.
- Verification: Send a "Confirm your email" link (Double Opt-In). This is the gold standard for ensuring an email is real, safe, and intentional.
Takeaways:
Validation and Sanitization stop the data from being dangerous. But even if the data is clean, you still have to ask: Is this user allowed to see this specific resource?
In my next post, I'll look into IDOR an access control level vulnerability, and how I found my first one.