Secrets in Source

Secrets in Source - Complete Solution

Understanding the Vulnerability

This challenge demonstrates two critical OWASP Top 10 vulnerabilities working together:

Phase 1: Accessing the Challenge

Navigate to the challenge URL in your web browser:

https://lab.hdna.me/4-secrets-in-source

You'll see a professional corporate website for "TechNova Solutions" with information about their services and team. The visible page appears completely normal with no obvious security issues.

Phase 2: Understanding Information Disclosure

The key insight is that web pages contain more than what's visible. When you visit a website, your browser downloads HTML, CSS, and JavaScript files. While these render into the visual page, the underlying source code often contains additional information.

Information Disclosure vulnerabilities occur when applications unintentionally expose sensitive data through:

• HTML Comments: Developer notes, TODO items, file paths, credentials
• JavaScript Code: API endpoints, authentication logic, internal URLs
• Error Messages: Database details, system paths, configuration info
• Debug Code: Testing credentials or development information left in production

Phase 3: Viewing the HTML Source Code

To examine the underlying HTML source code, you have several options:

Method 1: Keyboard Shortcut (Fastest)

Windows/Linux: Ctrl + U
macOS: Cmd + Option + U

Method 2: Right-Click Menu

• Right-click anywhere on the page
• Select "View Page Source" or "View Source"

Method 3: URL Prefix

view-source:https://lab.hdna.me/4-secrets-in-source

Phase 4: Finding the Hidden Information

Once you have the source code open, examine it carefully. Look specifically for HTML comments, which are enclosed in <!-- --> tags.

Near the bottom of the source code (around line 63), you'll find a developer comment:

<!-- TODO: move the flag "/anwvdzqtcucr/flag.txt" in a more secure location -->

This is a classic example of Information Disclosure - a developer left a TODO note revealing:

• The exact path to a sensitive file: /anwvdzqtcucr/flag.txt
• That this file contains "the flag"
• That the developer knows it's not in a secure location

Phase 5: Exploiting Broken Access Control

Now that we have the file path, we can test if the file has proper access controls. The developer's comment suggests it doesn't - they want to "move it to a more secure location" but haven't done so yet.

This is where Broken Access Control comes into play. The file can be accessed directly without any authentication simply by constructing the full URL.

Method 1: Using a web browser, navigate to:

https://lab.hdna.me/4-secrets-in-source/anwvdzqtcucr/flag.txt

Method 2: Using curl from the command line:

curl https://lab.hdna.me/4-secrets-in-source/anwvdzqtcucr/flag.txt

Method 3: Using wget:

wget -qO- https://lab.hdna.me/4-secrets-in-source/anwvdzqtcucr/flag.txt

The file loads without any authentication prompt or access denied error. This confirms the Broken Access Control vulnerability - the file lacks proper authentication and authorization checks.

Phase 6: Capturing the Flag

The file displays the flag in UUID format. Copy it exactly as shown and submit it to complete the challenge.

Why Security Through Obscurity Fails

This challenge demonstrates a critical security principle: security through obscurity does not work.

The developer attempted to "secure" the flag by:

• Placing it in a directory with a random name (anwvdzqtcucr)
• Assuming nobody would guess or discover this path

However, this approach failed because:

• The path was exposed in an HTML comment (Information Disclosure)
• Once discovered, there were no access controls to prevent access (Broken Access Control)
• The file could be accessed by anyone who knew the URL

Key Takeaways