6. Master the Basics, Break the Web: Input & Output Basics

Input & Output

1. Client-Side Validation vs Server-Side Validation

Client-side validation happens in the browser using JavaScript or HTML rules before sending data to the server. Server-side validation occurs on the backend after the request arrives, ensuring the data is safe, correct, and authorized. Client-side checks improve user experience, but server-side validation is the real security layer.

Client-Side Validation

Runs in the browser to check basic rules like required fields, formats, and lengths. It enhances usability but is easily bypassed by modifying requests or disabling scripts.

Pentest Relevance:

• Never trusted for security — attackers can edit or remove validations.
• Useful for identifying hidden fields or logic enforced only on the client.

💡Example: Blocking “negative amounts” in a form using JavaScript does nothing once an attacker edits the request manually.

Server-Side Validation

Runs on the server and decides what’s acceptable or rejected before processing data. It must enforce strict rules regardless of what the client sends.

Pentest Relevance:

• Missing or weak validation leads to SQLi, XSS, command injection, and logic bypasses.
• Pentesters fuzz input to see what the server accepts or rejects.

💡Example: Even if the browser stops special characters, the pentester can still send them server-side to test injection flaws.

2. Data Encoding Basics

Encoding transforms data into a safe or transferable format so browsers and servers can correctly interpret it. Different encoding types prevent breaking the structure of HTML, URLs, or scripts and ensure special characters are handled safely. Pentesters must recognize and decode encoded data to understand attacks, bypass filters, or identify injections.

HTML Encoding

Replaces special HTML characters with safe representations so they don’t execute as code. Example: < becomes <, > becomes >.

Pentest Relevance:

• Used to prevent XSS by neutralizing dangerous characters.
• Weak HTML encoding can allow injected scripts to render.

💡Example:

Input: <script>alert(1)</script>

Encoded: <script>alert(1)</script>

URL Encoding

Encodes characters so they can safely appear in URLs. Spaces, symbols, and unicode characters are replaced with % sequences.

Pentest Relevance:

• Useful for bypassing filters, breaking parsers, and fuzzing endpoints.
• Needed when testing URL-based injections or path traversal.

💡Example: /search?q=test value → /search?q=test%20value

Base64 Encoding

Converts binary or text data into ASCII characters (A–Z, a–z, 0–9, +, /). Not encryption — anyone can decode it easily.

Pentest Relevance:

• Often used to hide data in APIs, cookies, JWT payloads, or parameters.
• Pentesters decode Base64 to inspect hidden info or modify it before re-encoding.

💡Example: admin:1234 → YWRtaW46MTIzNA==

Unicode Encoding

Represents characters using Unicode code points (e.g., \u003C for <). Helps display symbols and languages consistently across systems.

Pentest Relevance:

• Used in bypasses for XSS, filtering, and WAF evasion.
• Malicious payloads may hide in mixed or encoded unicode formats.

💡Example: <script> → \u003Cscript\u003E

3. Sanitization & Escaping

Sanitization and escaping are two core techniques used to safely handle user input before sending it to the browser or database. They help prevent injections (XSS, SQLi, command injection) by ensuring dangerous characters are removed or rendered harmless. Understanding both is essential for evaluating how securely an application processes untrusted data.

Sanitization

Sanitization modifies or removes unsafe parts of user input. It typically strips or neutralizes characters, tags, or patterns that could cause harm.

Pentest Relevance:

• Overly strict sanitization may break functionality; overly weak sanitization leads to vulnerabilities.
• Attackers test alternative payloads, encodings, or nested input to bypass filters.
• Sanitization is context-dependent — sanitizing for HTML is different from sanitizing for SQL.

💡Example: Removing <script> tags from input before storing it in the database.

Escaping

Escaping converts special characters into safe representations so they are treated as text, not code. It prevents input from breaking out of its intended context (HTML, JavaScript, SQL, etc.).

Pentest Relevance:

• Proper escaping stops XSS by ensuring characters like < and " don’t become executable code.
• Input must be escaped based on where it appears: HTML, attributes, URLs, or JS contexts.
• Pentesters test for places where escaping is missing or inconsistent.

💡Example: Escaping < to < so it displays as text on the page instead of executing.

4. File Upload Handling Basics

File uploads allow users to send files (images, PDFs, documents) to the server for storage or processing. Because uploaded files come directly from users, they must be treated as untrusted input. Secure file upload handling ensures only safe files are accepted, stored correctly, and never executed as code.

File Type Validation

Servers check the file extension, MIME type, or file signature to ensure the upload is allowed. However, extensions and MIME types can be easily spoofed.

Pentest Relevance:

• Bypass attempts include renaming .php to .jpg.php or altering headers.
• Weak validation can lead to remote code execution (RCE).

💡Example: Uploading shell.php disguised as image.jpg.

File Size Limits

Servers restrict file size to prevent resource exhaustion or denial-of-service attacks. Large files can overwhelm storage or processing pipelines.

Pentest Relevance: Pentesters test maximum limits and upload huge files to check DoS resilience.

💡Example: Uploading a 5GB file to a system expecting <10MB.

Storage Location

Uploaded files should be stored outside the webroot so they cannot be directly executed or accessed. Access should be controlled by the application, not by file paths.

Pentest Relevance:

• Files stored in public directories may be executed if interpreted by the server.
• Path traversal attacks may expose internal directories.

💡Example: /uploads/image.jpg accessible directly → test for executing uploaded scripts.

Renaming & Sanitization

Servers must rename uploaded files to safe, random names. Sanitizing filenames prevents injection or path traversal.

Pentest Relevance:

• Filename injection (../../etc/passwd) can reveal system files.
• Poor sanitization can allow overwriting existing files.

💡Example: Original: ../../../malicious.php → Sanitized to: upload_12345.jpg

Content Scanning

Some applications scan the file content for malicious payloads. This adds an extra protection layer.

Pentest Relevance: Pentesters attempt polyglot files, obfuscated payloads, or metadata-based exploits.

💡Example: A .jpg containing embedded PHP code.

Wrapping up here — next up: Backend Application Flow

Catch you soon 🙌,
Abinesh