bWAPP Administrative Portal Access Control

Author: RatBully Platform: bWAPP (Broken Web Application) Lab/Module: Session Management — Administrative Portals Category: Broken Authentication / Broken Access Control Levels Covered: Low, Medium, High

Objective

This report examines how bWAPP's "Administrative Portals" module controls access to a restricted admin page, and whether that access decision can be manipulated by a user who was never granted it. This continues the session management thread from earlier reports, shifting focus from session token theft to client-side trust in access-control decisions.

Methodology

• Dev Tools :— view-source and inspection used first at each level to rule out visible hints before testing manipulation directly
• Manual request/URL and cookie manipulation :— testing whether the access flag could be controlled directly from the browser
• Source code review (via SSH) :— confirming the exact mechanism behind each level's check

Source code confirmation: if($_GET["admin"] == "1") { // access granted }

Root cause: Access is granted purely based on a value the user supplies directly in the URL, with no server-side verification of who the user actually is.

Medium: Access Controlled via Cookie

Approach: Since page source revealed nothing new, testing moved straight to DevTools. The cookie named admin (set to 0 by default) was edited directly to 1.

Finding: Setting the admin cookie to 1 granted access to the portal. **Source code confirmation:**if($_COOKIE["admin"] == "1") { // access granted }

Root cause: Identical trust problem to Low, just relocated from the URL to a cookie, still a value the client fully controls and can edit at will.

High: Correctly Secured, No Client-Side Bypass Available

Approach: Extensive testing was attempted (URL manipulation, cookie manipulation), with no success. The page's own hint ("contact your dba") pointed toward a deeper explanation, confirmed by reading the source directly.

Finding: Access is gated by a server-side session variable ($_SESSION["admin"]), which is never set anywhere reachable by the client in this module. There is no cookie, URL parameter, or hidden field for the user to manipulate.

Source code confirmation: if(isset($_SESSION["admin"]) && $_SESSION["admin"] == 1) { // access granted

Conclusion: This level is genuinely secure against client-side tampering. The access decision has been moved entirely server-side, where the browser has no reach, the correct architectural fix for the flaw demonstrated at Low and Medium.

Key Takeaways

• Any access-control decision based on a value the client supplies, whether in a URL, a cookie, or a hidden field, can be trivially manipulated, regardless of how that value is delivered.
• The fix isn't a smarter client-side check; it's removing the client's ability to influence the decision at all, by keeping authorization state entirely server-side.
• A security level that resists every manipulation attempt isn't a dead end to "solve" confirming why it holds, through source code, is itself a valid and valuable finding.

Tools Used

• Browser Dev Tools :— URL and cookie inspection/manipulation across all three levels
• SSH + source code review :— confirmed the exact access-control mechanism per level, including proving High has no reachable client-side bypass