Today, we’ll dive into the basics of authentication and authorization, specifically focusing on common vulnerabilities and how they can be exploited. These types of bugs often form the foundation of real-world attacks, so getting familiar with them is key. Below is a walkthrough of a few beginner-friendly exercises that help build your intuition around these flaws.
Exercise 1 – Header Manipulation (Authentication)
This was a simple one. The app relied on a specific header value to determine the user role. Initially, the header was set to something like X-User: guest. Changing this to X-User: admin granted admin access. Always inspect headers and any values passed between client and server — you’d be surprised how often these are trusted blindly.
🛠️ Takeaway: Never trust client-supplied headers for authentication. Use secure session or token-based methods instead.
Exercise 2 – MD5 Cracking (Authentication)
Again, quite straightforward. The challenge involved an MD5 hash of a basic password. Using an online tool or hash lookup service, we were able to reverse it quickly. This highlights how weak hashes (especially without salting) are practically useless for secure password storage.
🛠️ Takeaway: Never use plain MD5 for password hashing. Use strong hashing algorithms like bcrypt, scrypt, or Argon2 — and always salt your hashes.
Exercise 3 – Case Sensitivity Bypass (Authentication)
Here, we found a flaw in how usernames were handled. During registration, the system allowed us to create an account with the username Admin, but during login, the case was ignored, allowing access as if we were admin. That mismatch in logic was the exploit vector.
🛠️ Takeaway: Ensure consistent case sensitivity (or insensitivity) checks across all stages of authentication and registration.
Exercise 4 – Trailing Space Bypass (Authentication)
Similar to the previous one but this time involving whitespace. The registration form blocked admin, but allowed admin (with a trailing space). During login, trailing spaces were trimmed, effectively logging us in as admin.
🛠️ Takeaway: Always normalize and sanitize user inputs consistently. What you store should match exactly what you compare during authentication.
Exercise 5 – Leaking Secrets via 302 Redirect (Authentication)
This one was a bit more nuanced. Upon reloading the homepage, the app redirected to a login page — but the secret key was exposed in the 302 redirection response. While rare, it’s a good reminder to inspect all parts of HTTP responses, especially redirects.
🛠️ Takeaway: Never leak sensitive data in URLs, headers, or redirection responses. Always audit what gets exposed during redirects.
Exercise 6 – IDOR (Authorization)
We finally shifted to an authorization bug here — a basic IDOR (Insecure Direct Object Reference). By changing a user ID in the URL from 2 to 3, we were able to access another user’s (in this case, an admin’s) information.
🛠️ Takeaway: Always perform access control checks on every resource access. Never rely on obscurity (like guessing an ID) for security.
Final Thoughts
These exercises highlight how small oversights can lead to major vulnerabilities. Whether it’s trusting client headers, mishandling casing or spaces, or leaking secrets in redirects — it all boils down to one thing: don’t trust user input. Always validate and verify on the server side, and ensure consistency across the entire authentication and authorization flow.
Stay tuned for Part 2, where we’ll dive deeper into more complex auth bugs and real-world attack scenarios. 🔐
Leave a Reply