PENTEST INTERVIEW 001

As a pentester in cybersecurity , you encounter vulnerabilities and weaknesses right ? … things like weak passwords, IDOR, Remote Code execution, Broken Access. But what gets me is report writing — i mean who doesn't ??? This time i'm talking to the ones getting familiar with …may be starting out this peculiar journey among a various cybersecurity universe.

Learning the A, B, C's for these types of interviews — Here's what i have learn't about them and it might be duh to you but some out there will find this useful…

OWASP TOP 10 :

Now , i have so far done 2 interviews — one about this very write — up and another one in my next write — up.

This is about Web pentesting and the other one is about Backend — broken Code BUT they all link to the OWASP TOP 10 when report writing comes in play explaining to share — holders in the NOT so boring professional jargons exercised through the board by some I.T dude — mostly the 2 months old ones …" always something to say — was there though "

Not to loose our path in my ambiguity stories , we are going to be using :

https://tryhackme.com/room/guidedpentestweb

Synopsis :

This room will guide you through a realistic web application penetration test from start to finish. You will not be dropped into a machine and told to "find the flags." Instead, each task walks you through a phase of the engagement, explaining what to do, why you are doing it, and what to look for. By the end, you will have moved from knowing nothing about the target to achieving remote code execution on the underlying server.

If in case you completed it already after this — you might want to look at everything again in that perspective because it simply works every-time.

UUHHmm … do i need to explain what the owasp top 10 is ?

The OWASP Top 10 web application security risks is an essential awareness document that highlights the most critical security risks for modern web applications. It reflects how App-sec has shifted toward architectural resilience, supply-chain integrity, and root causes.

The point of this write — up is to learn how to map our vulnerability findings to the owasp — top 10 web application security risks which is very helpful with technical report writing and most technical interviews.

A01 — Broken Access Control( includes BOLA, BFLA, SSRF )

A02 — Security Misconfiguration

A03 — Software Supply Chain Failures

A04 — Cryptographic Failures

A05 — Injection( includes XSS )

A06 — Insecure Design

A07 — Authentication Failures

A08 — Software or Data Integrity Failures

A09 — Security Logging and Alerting Failures

A10 — Mishandling of Exceptional Conditions

Case Scenario :

https://tryhackme.com/room/guidedpentestweb

Mapping Engagement Paths to the OWASP — TOP 10 web application security risks

SEVERITY : INFORMATIONAL

PHASE 1 — Reconnaissance & Enumeration :

What happens: We are going to find open ports, fingerprint exposed routes ( /login, /api, /admin ), discovers DEBUG_MODE=true leaking stack traces, and finds secrets committed to the repository.

API end — point enumeration :

The API helpfully lists its own endpoints. This is already an information disclosure issue in a production application; an unauthenticated user should not be able to discover internal routes. Let's keep these in mind as we move into the next task.

REMEDIATION :

• Remove the index endpoint or restrict it to authenticated administrators.
• Do not expose internal route structures to unauthenticated users.

PHASE 2 — Insecure Direct Object Reference (IDOR)

First , we have to be a familiar foe by creating a user account …

The /profile.php?id= parameter and the /api/user?id= endpoint allowed us to enumerate all users, including the administrator's name and email address.

Types of IDOR :

Horizontal IDOR (Horizontal Privilege Escalation):

Where User to user, at the same privilege level. Example: We changed profile.php?id=7 to profile.php?id=2 and viewed User B's order — both are regular users, just different accounts. moving sideways across the same tier.

Vertical IDOR (Vertical Privilege Escalation):

User to admin, crossing privilege levels. Example: A regular user accesses /api/admin/users or modifies a role parameter to escalate themselves to admin. You're moving up the privilege hierarchy.

SEVERITY : HIGH — CRITICAL

REMEDIATION :

Implement server-side authorisation checks on every request.

Verify that the authenticated user has permission to access the requested resource.

Apply least privilege, and add automated tests that prove permission checks hold.

Mapping PHASE 2 — Insecure Direct Object Reference (IDOR) to the OWASP — TOP 10 web application security risks :

→ A01: Broken Access Control (Primary — BOLA sub-type)

Broken access control happens when users can reach data or perform actions outside their intended permissions. A common example is changing profile.php?id=7 to profile.php?id=2 in a request and seeing another customer's account — an "insecure direct object reference."

Broken Access Control now explicitly covers BOLA and BFLA API authorization failures — the most exploited patterns in modern API-heavy applications.

→ A05: Injection (Secondary — compound risk)

The userId parameter is also unsanitized and injected directly into the SQL query, meaning the IDOR and a SQL injection exist on the same endpoint simultaneously — IDOR gets you someone else's data; SQLi lets you dump the whole table.

CWEs: CWE-639 (Authorization Bypass Through User-Controlled Key), CWE-284 (Improper Access Control)

PHASE 3 — Weak Password Reset → Account Takeover :

The password reset mechanism uses a predictable or short-lived-but-improperly-validated token, has no rate limiting, and possibly reflects the token in a URL — allowing account takeover without knowing the original password.

In this case , Password reset token was exposed in the response.

SEVERITY : HIGH — CRITICAL

REMEDIATION :

• Send reset tokens exclusively via email. Display only a generic confirmation message on the page.
• Use cryptographically random tokens of at least 32 characters.
• Use OIDC for authentication and appropriate OAuth 2.0 flows for delegated authorization, require multi-factor authentication, and manage sessions securely with proper expiry and rotation.
• Threat-model during design and write security requirements alongside functional ones. A reset flow with no rate limit or token entropy check is a design failure — clean code won't fix it.

Mapping PHASE 3 — Weak Password Reset → Account Takeover to the OWASP — TOP 10 web application security risks :

→ A07: Authentication Failures (Primary)

Authentication Failures covers weak or broken login, session, and identity flows. It allows attackers to impersonate users or hijack sessions. A session token that never expires, or a login endpoint with no protection against credential stuffing, is a representative example.

→ A06: Insecure Design (Architectural root cause)

Insecure design refers to security flaws baked into the architecture itself, not bugs in otherwise sound code. A banking flow with no rate limiting or step-up authentication is an example: the code may be correct, but the design invites abuse and fraud.

→ A10: Mishandling of Exceptional Conditions (Failure mode)

Mishandling of Exceptional Conditions covers improper error handling, logic that fails open instead of closed, and unexpected states that leave the application in an insecure condition. An example is an authorization check that throws an exception and instead of denying access, lets the request through. If the reset token validation throws an error and the app silently proceeds, access is granted by exception.

CWEs: CWE-640 (Weak Password Recovery Mechanism), CWE-307 (Improper Restriction of Excessive Auth Attempts), CWE-330 (Use of Insufficiently Random Values)

PHASE 4 — Admin Panel Access (Privilege Escalation)

The admin panel exposes several management pages. Most of these are standard administrative functions, but one stands out immediately: /admin/upload.php. A file upload function in the hands of an administrator is a powerful feature, and from a penetration tester's perspective, it is a potential path to remote code execution.

SEVERITY : HIGH — CRITICAL

REMEDIATION :

• Enforce server-side authorization on every admin route
• Default to deny, explicitly grant access (least privilege)
• Never trust client-supplied role/permission data

Mapping PHASE 4 — Admin Panel Access (Privilege Escalation) to the OWASP — TOP 10 web application security risks :

→ A01: Broken Access Control (Primary — BFLA sub-type)

Broken Access Control now explicitly covers BOLA and BFLA API authorization failures. BFLA (Broken Function Level Authorization) is exactly this: a regular user invoking admin-only functions because the endpoint has zero auth enforcement.

→ A02: Security Misconfiguration (Contributing factor)

Security misconfiguration covers unnecessary open services and missing hardening. Deploying an admin route with no access control is a configuration/hardening failure — the service should never have been reachable without role verification.

→ A07: Authentication Failures (Chain link)

The JWT token is signed with a weak hardcoded secret (secret123). An attacker who has done Phase 3 can forge a token with role: "admin" set and pass it to authenticated endpoints — bypassing role-based access entirely.

CWEs: CWE-285 (Improper Authorization), CWE-862 (Missing Authorization), CWE-269 (Improper Privilege Management)

PHASE 5 — Remote Code Execution (RCE)

From the admin panel, the attacker abuses functionality (e.g., file upload, command execution feature, or a server-side template injection vector) to execute OS-level commands on the server.

The accept attribute on the file input restricts file types, but this is a client-side restriction only. The browser enforces it, but a direct HTTP request can send whatever file type it wants. The page also reveals the upload destination: /uploads/documents/

The application's file type filter blocks .php but does not account for alternative extensions. This is a common oversight; developers create a blocklist of "dangerous" extensions, but miss less common ones that the server still processes as PHP.

Obtaining a Reverse Shell:

A Shell can be found at :

Online - Reverse Shell Generator Online Reverse Shell generator with Local Storage functionality, URI & Base64 Encoding, MSFVenom Generator, and Raw…

SEVERITY : HIGH — CRITICAL

REMEDIATION :

Use an allowlist rather than a blocklist. Only permit specific, expected extensions. Validate file content ( MIME type) in addition to the extension. Store uploaded files outside the web root.

Mapping PHASE 5 — Remote Code Execution (RCE) to the OWASP — TOP 10 web application security risks :

→ A05: Injection (Primary)

Injection occurs when untrusted input is interpreted as a command or query, letting an attacker change what the application executes. A SQL query built by concatenating user input is the canonical example. The fix is to use parameterized queries or a well-maintained ORM, validate input against an allowlist, and run the database with least privilege. At the OS level, this becomes command injection — child_process.exec(userInput) or equivalent.

→ A06: Insecure Design (Architectural)

Admin functionality that allows arbitrary server-side execution (file management, shell commands, template rendering from user input) is a design flaw. No amount of sanitization makes exposing shell access to a web interface acceptable.

→ A02: Security Misconfiguration (Amplifier)

DEBUG_MODE=true in production means stack traces, file paths, and environment variables leak through error responses — giving the attacker the map they need to construct a working RCE payload.

→ A09: Security Logging and Alerting Failures (Persistence enabler)

Without effective logging and alerting, attacks may go undetected or take longer to investigate. RCE with no command logging means the attacker can establish persistence, exfiltrate data, and move laterally — all without a single alert firing.

CWEs: CWE-78 (OS Command Injection), CWE-94 (Code Injection), CWE-77 (Command Injection)

" This mapping not only strengthens the credibility and structure of the report but reflects the kind of risk-based, framework-driven thinking expected in a security analyst role / Pentester role — connecting technical findings to business impact and remediation priority rather than treating each vulnerability in isolation. "

For interview prep specifically: this is a strong one to have ready verbally too — if asked "walk me through a recent finding," you can lead with "I mapped everything to OWASP Top 10:2025, and the three most critical themes were broken access control, misconfiguration, and injection" and then go deep on one example (like the vertical IDOR/admin panel one).

Alright , I hope this helps human to human …i'm not a robot !!!!

CHEERS …!!!!