Comprehensive Web Security Assessment: From Reconnaissance to Privilege Escalation

Bababtunde Qodri, an aspiring cybersecurity analyst, believes every security breach starts with reconnaissance — and in this project, he put that theory into practice over just two days.

From scanning ports to privilege escalation, I simulated a real-world penetration testing engagement in a controlled lab environment. Driven by curiosity, I wanted to move beyond certifications and challenge myself with a realistic project that mirrored how attackers think and operate.

Objective

The project aimed to simulate an end-to-end penetration test against a demo environment, “electron-strore.fezzant.com.” The goal was to document vulnerabilities and highlight how defenders can detect and prevent such attacks. The simulation followed the attacker’s path from initial reconnaissance to privilege escalation, using tools such as nslookup, dig, Nmap, and Burp Suite to uncover weaknesses in web applications and APIs.

In this post, I’ll walk you through my process — step by step — highlighting the tools, techniques, and lessons learned along the way. Sit back and enjoy!

(You can also find a link to this project here: Talk2Babatunde).

Like any attacker, I began by surveying the battlefield: reconnaissance. The goal wasn’t to exploit yet, but to uncover what the server was hiding beneath the surface. Here’s how it started…

DNS Reconnaissance with nslookup & dig

nslookup and dig are my go-to tools for DNS reconnaissance. This phase helped me map the target domain and uncover useful information about the underlying infrastructure. Using nslookup, I identified the server’s IP address, and with dig I was able to extract additional records (A, MX, TXT) — giving me a clearer picture of the target’s environment as seen below:

Figure 1: The output revealed the IP address of the target server (138.68.170.157), which became the starting point for further enumeration.

nslookup electron-store.fezzant.com

dig electron-store.fezzant.com

Port Scanning with Nmap

After completing DNS reconnaissance, my next step was to identify open ports and services on the target. For this, I used Nmap, a powerful network scanning tool that also provides operating system and service detection.

The command I ran was: sudo nmap -A -o -v 138.68.170.157

Figure 2: The scan began with Nmap loading its scripts, confirming the host was alive, and initiating a SYN stealth scan to enumerate open ports and services.

nmap -A -O -sV -sC electron-store.fezzant.com

Figure 3: The scan revealed critical services and open ports, which shaped the next stage of my testing and guided where to focus my enumeration efforts.

-A → Enables OS detection, version detection, script scanning, and traceroute.
-O → Enables OS fingerprinting.
-v → Verbose output (more detailed info).

138.68.170.157 → The target IP.

Before I move further, let me share you the the key Vulnerabilities Identified in the Assessment and exposure.

• Privilege Escalation (Role Manipulation): I identified Weak client-side role validation that allowed normal users to escalate privileges to admin.

• Cross-Site Request Forgery (CSRF): There are Lack of CSRF protections enabled unauthorized profile updates through crafted requests.

• Payment Workflow Bypass: I bypass payment bank details and completed with fake card details due to missing payment verification.

• Unrestricted Directory Access: I viewed Misconfigured server that exposed sensitive files, logs, and business documents.

• Insecure Session Management: Authentication tokens remained valid after logout, allowing session hijacking.

• Insecure Direct Object References (IDOR): Attackers could manipulate basket IDs to view or delete other users’ items. Empty all the basket id, Lol.

• Weak Password Policy: I exploited the system accepted simple, guessable passwords without complexity requirements.

• Server-Side Template Injection (SSTI): I successuly login as a root user while Input in profile fields was executed on the server, allowing remote command execution as root.

Privilege Escalation via Insecure Client-Side Role Handling

Upon noticing that the application relies on a client-side role assignment mechanism, and then confirmed it’s insecure. I decided to intercept and modify the role of the user, what does it mean? a normal user can escalate privileges to an administrator. Since the server does not validate roles, sweet? Lol. access control can be bypassed entirely. But first of all, Lets login as a normal user.

Figure 4: Burp Suite screenshot showing login as normal users as a “customer” role.

On your browser, Log in as a normal user.
Intercept the login response with Burp Suite.
Modify the role parameter from user to admin.
Forward the request and refresh the application page. The interface now exposes administrative features.

Figure 5: Burp Suite screenshot showing login as normal user being modified as an “admin” role.

Now we’ve successfully executed privilege escalation against this server comfortably. Onto the next one.

References

• OWASP Access Control Cheat Sheet

• CWE-266: Incorrect Privilege Assignment

Cross-Site Request Forgery on Profile Update Allows Unauthorized Username Change

Here, i am targeting the the /profile endpoint, because it paramount for me to perfomed A Cross-Site Request Forgery (CSRF) vulnerability, i later discovered in the /profile endpoint, which handles state-changing operations such as updating a user’s profile details. By the time i break into the /profile endpoint, i noticed these following vulnerabilities:

• The application fails to implement CSRF protections (e.g., CSRF tokens, SameSite cookie attributes), and this flaws can quickly enable a sophisticated attacker to trick an authenticated user into executing unwanted actions without their consent.

Another flaw I identified and can be exploited is by hosting a malicious HTML page that sends a forged POST request to /profile, it is possible to change the username of a logged-in victim without their knowledge. This attack requires only that the victim be authenticated to the application in the same browser session.

Upon noting all these flaws again. I ran the following:

Log in as a user, Intercept the POST request to /profile when updating username

Intercept the set username request to see how it is being processed

Craft Malicious HTML code and save
Start a Python HTTP server in the same directory as the html code: python3 -m http.server 80

Deliver the Exploit: Send the malicious link to a logged-in victim

Trigger the Exploit, Deliver the exploit to the victim Exploited: I ran http://127.0.0.1/csrf .

Now we’ve successfully performed a redirection to the profile page to show a successful username change.

Order Placement Without Valid Payment

The web server is a stored service where customers and buyer pick and order their goods which often took them a while before delivery. Since the payment is made via e-transaction. This prompted me to validate the checkout payment process and see if it does not validate the authenticity of payment details before confirming an order.

Yipe!!! It didn’t validate the authenticity of the payment details. My mentor always tell me, it is not about beautifully design alone, security should lead first. This flaw allows an attacker to submit fake bank card information and still have the order processed as paid. The system issues order confirmations and receipts without verifying payment through a legitimate payment gateway or processor.

So lets try it if we can submit with fake details and still get our order confirmed and delivery date, follow me.

Log in with a valid user account or register a new one. On the payment page, choose the bank card option.
Enter random, fake card details and submit.

Proceed to checkout, enter a valid shipping address, and select a delivery interval.

I choose my delivery date.
The system accepts the details and processes the order as successful.

And FINALLY! An order confirmation page is displayed and a receipt is generated as seen below:

This reveal a big flaw in the web server which needs to be fixed! Lets look for more! Follow me.

Unrestricted Directory Access Exposes Confidential Business Files and System Logs

A quick run ffuf command reveal this one!

What is ffuf and how ffuf Works?

Let’s paint an analogy for non tech users to understand, Think of ffuf like a curious visitor trying every possible door in a building to see which ones are open. Websites often have hidden rooms (directories and files) that aren’t linked anywhere but still exist. Attackers can use ffuf to automatically test thousands of possible names for these hidden doors until they find ones that respond.

In my own scenario, I noticed that there’s a misconfigured web server that allows public access to sensitive records, system logs, and file directories without authentication. This quickly ran to my thought from our earlier flaw, l.e if we can order with invalid card without authentication then, there’s a strong likelihood that there will be free and unrestricted access to confidential files and directories. Think like an attacker! Lol

During my testing, while browsing to a linked document in the "About Us" section led to /ftp/legal.md. I then manually navigating back to /ftp/ revealed a directory listing containing confidential files, including acquisitions.md (business acquisition records) and incident-support.kdbx (KeePass database file). That’s when i know that further enumeration using FFUF will surely identified /support/log containing downloadable system logs, exposing internal operational data. Check them out below:

I remove legal.md from the URL to access /ftp/ and view directory contents.

Directory Brute Forcing with ffuf help me discover hidden directories and files on the target, I used ffuf with a common wordlist: ffuf -w /usr/share/wordlists/dirb/common.txt -u http://electron-store.fezzant.com:3000/FUZZ -fs 71567

This expose all the resources that weren’t directly linked on the website but were still accessible — a common oversight in web security.

Figure 6: In this screenshot, the -w flag specifies the wordlist to use, and the -u flag defines the target URL. The FUZZ keyword acts as a placeholder in the URL, which ffuf will replace with each entry from the wordlist (in this case, values from userIDs.txt). The mechanism is similar to Wfuzz, where the placeholder is iteratively replaced to test for valid responses.

I Found the logs path/Log Directory Listing

Figure 7: Directory listing extracted from the web server’s root or main directory using ffuf, revealing accessible files and folders including system, application, and log-related resources.

Insecure Session Management

I decided to logout from my web page and check if the application does not properly invalidate authentication tokens upon logout, allowing them to be reused indefinitely. During my testing, i noticed i can save token from my user account and swap into the browser session of another logged-in user, which can be used anonymously to performe malicious activities. One that might even resulting in full account takeover without needing credentials.

Normally, if tokens are stored in client-side storage and are not bound to a specific device, IP address, or session context, making them vulnerable to reuse by attackers. Let’s performed the trick:

Let’s Exchange login: Replace User B’s token in local storage with User A’s saved token.
Then intercepted with burp and sent to repeater, highlighting mysoc.helpdesk01@gmail.com authentication token and logged out as a normal user would.

After that I signed in as the second user

Replace User B’s token in local storage with User A’s saved token.

Refresh the page — the application now loads with User A’s account data and privileges as shown below.

What Insecure Token Storage in Local Storage means?

In this testing, the application stores authentication tokens in the browser’s localStorage. This storage mechanism is accessible to JavaScript, making tokens vulnerable to theft if an attacker successfully executes malicious JavaScript in the victim’s browser (e.g., via Cross-Site Scripting). Tokens in localStorage also persist beyond browser sessions, extending the exposure window if a device is lost, stolen, or compromised.

Insecure Direct Object Reference (IDOR) – Basket Manipulation

Insecure (IDOR) this is own basket

I think access control is the most underrated of all security mechanisms. In the resources on the application, I noticed its fails to enforce proper access controls on each of their basket resources, allowing an authenticated user to view or modify another user’s basket by changing the basket_id parameter in requests. I also observed that an HTTP method manipulation can allows unauthorized deletion of basket items belonging to other users. This lack of authorization checking enables direct object access and modification outside the attacker’s own account. Let’s go and DELETE the resources in the basket!!

Log in and view your own basket (basket_id = 5).

I modify the request URL or payload to reference another user’s basket (basket_id = 13).

Add and view another users another users basket ID (5) as shown in the response below: This is our ITEM on basket 5 before exploitation.

To delete an item, change the HTTP method from PUT to DELETE and target:

Include the target basket_id and item ID in the request. while also adding the ID of the item I want to delete in the path (DELETE/api/BasketItems/7), then sent the request. See the result from the response below:

After the request has been sent , I verified that the item has been deleted by sending a GET request to the basket ID 5 to confirm the deletion of the item. This conformed our EMPTY BASKET after we deleted everything !!

- Empty basket after deleted

We’ve successfully exposed their BASKET! Lol. Unto the next one..

Weak Password Policy

The application’s account registration process accepts passwords that are short, simple, and lack complexity requirements. During testing, it was possible to create accounts using easily guessable passwords such as "123456", "password", and "test123". There was no enforcement of minimum length, special characters, or uppercase/lowercase combinations.
Additionally, there is no mechanism to check newly created passwords against known breached password lists (e.g., HaveIBeenPwned database), which increases the risk of attackers successfully guessing or brute forcing user credentials.

Step 1: Navigate to the registration page.
Step 2: Enter "testuser" as the username and "123456" as the password.
Step 3: Submit the form; the account is successfully created without any password strength warning or rejection
Step 4: Repeat with other weak credentials like "password", "admin", or "qwerty", all of which are accepted by the system.

Server side template injection/ testing to confirm SSTI vulnerability

During a security assessment of the Electron-store.fezzant.com web application, a Server-Side Template Injection (SSTI) vulnerability was identified on the /profile page. Exploitation of this vulnerability allowed the execution of arbitrary operating system commands as the root user, granting full control over the application environment. Immediate remediation is required to prevent potential compromise of the system.

Burp suite was used for resetting the username back to a normal user after a bad payload has been injected in the username input field .

Logged in as the admin user and navigated to the profile where a simple payload was tested

To confirm the application was vulnerable to SSTI .

payload= #{1+1}

Figure 8: This confirms Server-Side Template Injection (SSTI) exists in the username input on the profile page.

the server evaluated the expression as (2) instead of displaying it literally as #{1+1}

This implies that User input is executed by the template engine (Node.js applications that uses Pug )

Further testing

Result = root

payload = #{global.process.mainModule.require('child_process').execSync('whoami').toString()}

Shows that the command is being executed as root in the application.

ROOT USHER!!!!

Conclusion

This assessment revealed a range of vulnerabilities, from critical business logic flaws to fundamental security control gaps, that together place the application at significant risk. Issues such as Privilege Escalation, Insecure Payment Workflow, Directory Exposure, and IDOR directly threaten the confidentiality, integrity, and availability of both business and customer data.

While some vulnerabilities stem from missing technical safeguards (e.g., lack of server-side validation, weak session/token handling), others reflect broader process and design shortcomings, such as absent secure coding standards, insufficient input validation, and inadequate authentication policies.

The good news is that these findings present an opportunity for immediate and meaningful improvement. By prioritizing the critical fixes outlined in this article and adopting a proactive security mindset, integrating security reviews, regular testing, and developer training into the development lifecycle the organization can significantly strengthen its overall security estate.

“⚠️ Disclaimer: All testing was conducted in a controlled lab environment that are configured for educational purposes. No unauthorized systems were accessed.”

Babatunde Qodri

reference:
OSWAP10
hatricks
OWASP Top 10