Web Application Pentesting – Exploiting the Modern Web

Over the past few weeks, I’ve worked through the Web Application Pentesting learning path on TryHackMe—a course that explores the many layers of vulnerabilities found in modern web applications. This module has been one of the more challenging ones for me so far, not just because of its technical depth, but also due to time constraints. My current academic workload is demanding: exams are approaching, and school is focusing on practical skills like Windows Server administration and scripting with PowerShell.

Balancing this with self-driven learning in offensive security isn’t always easy, especially since my programming knowledge is still developing. However, despite the difficulty, I’ve kept pushing forward. The content covered in this path is essential for anyone aiming to become proficient in application security, and the structure—split into specific categories with accompanying hands-on rooms—offered me a systematic way to progress from theory to practical exploitation.

Breaking Authentication – More Than Just Passwords

Authentication mechanisms are the front gates of any web application. In this section, I learned how attackers enumerate users and brute force login portals. But it wasn’t just about guessing passwords. It was about understanding how misconfigurations or improper rate limiting can give attackers room to probe systems freely. Username enumeration, for instance, can be leveraged by analyzing subtle differences in error messages or response times.

The module then introduced session management, showing how poorly implemented session identifiers can lead to session fixation, hijacking, or privilege escalation. I was reminded how critical proper session expiration, secure cookie flags, and regeneration upon login are for web security.

JWT (JSON Web Token) vulnerabilities were particularly eye-opening. While JWTs are a popular method for stateless authentication, misuse—such as using none as the signing algorithm, weak secret keys, or accepting unsigned tokens—can compromise entire systems. The OAuth vulnerabilities section expanded on this, explaining how implicit flow, open redirect flaws, and misconfigured scopes can lead to account takeover. OAuth, if misunderstood, can create a false sense of security while enabling lateral movement or privilege escalation in connected services.

Multi-Factor Authentication (MFA) wasn’t spared either. While often considered a silver bullet, this module explained ways to bypass MFA through session reuse, token interception, or social engineering. The final challenge—Hammer—brought together everything covered in the authentication section. It forced me to chain enumeration, session abuse, and token manipulation into a full attack path, resulting in a successful authentication bypass and RCE.

Injection Attacks – Exploiting the Trust Boundary

The injection module was rich in content and showcased the many ways in which user-controlled input can compromise the logic and behavior of applications. Starting with Advanced SQL Injection, I revisited and expanded on my knowledge of time-based attacks, stacked queries, and techniques used to bypass WAFs or filters. It's not just about ' OR 1=1--, but understanding how database engines interpret input and how attackers can manipulate those interpretations to gain unauthorized access.

NoSQL injection was equally enlightening. With the rise of MongoDB and other document-based databases, I saw how traditional SQLi protections fall short. In these cases, operators like $ne, $gt, or even embedded JavaScript can be injected to retrieve or modify sensitive data.

XXE (XML External Entity) injection revealed the dangers of parsing XML improperly, particularly in applications that use XML to handle file uploads or SOAP-based APIs. From reading sensitive files to SSRF and even limited code execution, XXE has many faces.

SSTI (Server-Side Template Injection) was one of the more advanced topics. Learning how Jinja2, Twig, or other templating engines can be abused with malicious payloads gave me insight into another layer of application logic that is often overlooked. Template engines aren’t just for rendering content—they’re often gateways to the backend.

LDAP injection and ORM injection reminded me that any interpreter or query language is susceptible to injection. LDAP, while often used internally, can be a goldmine for privilege escalation or information gathering if left unfiltered. ORM frameworks like Hibernate or Sequelize, if misused, can open the door to indirect SQL injection attacks.

The section ended with the Injectics room—a realistic scenario where I applied various injection techniques across multiple attack surfaces. It was a demanding but satisfying test of everything covered.

Advanced Server-Side Exploitation – Beyond Input Validation

This part of the module moved away from classical input attacks and into more systemic and architectural vulnerabilities. Insecure Deserialization introduced me to the dangers of accepting serialized objects from untrusted sources. By manipulating serialized data, attackers can inject unexpected logic or even gain remote code execution, especially when dangerous methods like __wakeup() or __destruct() are triggered on the server side.

SSRF (Server-Side Request Forgery) demonstrated how a vulnerable server can be tricked into making requests to internal services. This can be used to access admin-only metadata endpoints in cloud environments, scan internal networks, or pivot into other services.

Path traversal and file inclusion attacks were explored in great detail. These are especially dangerous in PHP environments where file inclusion functions are common. By manipulating directory paths, attackers can read sensitive configuration files or even execute arbitrary code through local file inclusion (LFI) vulnerabilities.

Race conditions added a new layer to my understanding. These are concurrency-based vulnerabilities where two processes access the same resource in a way that creates unpredictable results. This is particularly relevant in payment systems, user role updates, or file uploads.

Finally, prototype pollution—mostly a client-side JavaScript vulnerability—was explained in the context of how modifying object prototypes can change application logic. This attack is subtle and complex but can result in privilege escalation or DoS in JavaScript-heavy applications.

The Include room brought all these ideas together and challenged me to apply server-side logic bugs in a full-chain exploit.

The Client Side Is Not Safe Either

This section covered Advanced Client-Side Attacks in depth. XSS (Cross-Site Scripting) continues to be a prevalent and dangerous vulnerability. Here, I refined my understanding of DOM-based vectors, event-handler injections, and bypassing CSP (Content Security Policy). Stored and reflected XSS both carry different implications depending on context and placement.

CSRF (Cross-Site Request Forgery) taught me how trust can be abused in authenticated sessions, and how attackers can craft malicious requests that users unknowingly submit on behalf of the attacker. The lesson emphasized the importance of CSRF tokens and SameSite cookie attributes.

DOM-based attacks, which occur entirely in the browser without server interaction, were more difficult to detect and mitigate. They reminded me how much modern frontend frameworks rely on JavaScript—and how fragile that ecosystem can be if client-side logic is not handled securely.

The section also discussed CORS (Cross-Origin Resource Sharing) and SOP (Same-Origin Policy)—two mechanisms that protect user data across domains. Misconfiguring them can lead to leakage of sensitive information and unauthorized API calls.

The challenge room What’s Your Name? was a fun but technical task where I had to chain client-side issues to take full control over a vulnerable app.

HTTP Request Smuggling – Attacking the Communication Layer

This was by far one of the most subtle and complex sections of the module. HTTP Request Smuggling involves exploiting inconsistencies in how front-end proxies and back-end servers parse HTTP requests. It’s a rare but critical vulnerability that can lead to session hijacking, cache poisoning, or bypassing WAFs.

I explored multiple techniques including CL.TE (Content-Length vs. Transfer-Encoding) and TE.CL, which confuse systems that expect a specific parsing behavior. HTTP/2 smuggling demonstrated how the next generation of HTTP protocols can introduce new parsing discrepancies.

The section also covered WebSocket smuggling, a technique that abuses the upgrade mechanism of HTTP to inject malicious WebSocket traffic. Browser desync was a fascinating case of client-side smuggling, where inconsistent rendering leads to unintended side effects.

The final room, El Bandito, brought all these techniques together in a creative mission-based challenge that reinforced the risks of HTTP layer exploitation.

Final Thoughts

This learning path wasn’t just about finding bugs—it was about understanding the deep mechanics of how web applications, protocols, and technologies interact. The more I studied, the more I realized how complex and layered web application security truly is. Every function, every data structure, every header can be a point of failure.

While I’m currently slowed down by school and exam prep, this module reaffirmed why I chose this path in the first place. It’s intellectually demanding, but incredibly rewarding. I now have a stronger foundation in authentication mechanisms, injection techniques, server/client-side logic bugs, and advanced exploitation methods.

There’s still a long road ahead, especially in programming and automation, but I’m more motivated than ever to continue. I’ll be revisiting these concepts regularly—not only to prepare for future certifications, but to build the muscle memory that makes a competent penetration tester.