Information Disclosure Vulnerabilities

What is Information Disclosure?#

Information disclosure (or information leakage) happens when a website accidentally shares private or sensitive information. This can include:

• User data (usernames, emails, payment info)
• Business data (plans, prices)
• Technical details (server information, software versions)

Even small pieces of leaked information can help attackers plan bigger attacks.

Why is it Dangerous?#

There are two types of danger:

1. Direct danger: Leaking private user or business data, like credit card numbers.
2. Indirect danger: Giving technical details that help attackers find other weaknesses.

Example: If an attacker learns the software version, they might find known security holes for that version.

Common Examples#

• A robots.txt file showing hidden folders.
• Directory listing turned on, showing all files in a folder.
• Backup files (like backup.zip) left on the server.
• Error messages that show database details or server paths.
• Source code exposed with passwords or API keys.
• Different error responses that reveal if a username exists.

How Do These Vulnerabilities Happen?#

1. Developer Mistakes#

• Leaving comments in HTML or JavaScript with sensitive info.
• Forgetting old or backup files on the server.
• Not removing test pages.

2. Bad Configuration#

• Debug mode turned on in production.
• Error messages giving too much detail.
• Default settings showing extra information.

3. Poor Design#

• Login forms telling if a username is valid based on different error messages.
• APIs giving too much data.
• Responses changing based on internal logic.

How Attackers Find Them#

Attackers look for clues by:

• Viewing the page source to find comments or secrets.
• Forcing errors to see if messages reveal details.
• Using tools to find hidden directories or files.
• Changing request parameters to see how the server responds.
• Checking robots.txt and sitemap.xml for hidden paths.
• Seeing if folders are open to browsing.

Examples:

• A 200 OK vs 404 Not Found response can confirm if a user exists.
• An error with a stack trace shows code details.

How Serious is It?#

Not all information leaks are equally bad. The danger depends on:

• How sensitive the leaked information is.
• Whether it helps an attacker do more serious attacks.

Examples:

• Exposing user emails can lead to phishing.
• Revealing server software version can help exploit known bugs.
• Showing internal IP addresses can help plan an attack.

How to Prevent It#

You can reduce the risk by following these practices:

1. Team Awareness

   • Teach developers what information is sensitive.
   • Explain why even small leaks can be harmful.

2. Code Review

   • Remove comments before publishing.
   • Delete old and backup files.
   • Check API responses for unnecessary data.

3. Error Handling

   • Show generic error messages to users.
   • Avoid sharing technical details in errors.

4. Configuration

   • Turn off debug mode in production.
   • Use secure settings for all software and servers.
   • Check third-party tools for default settings that leak info.

5. Access Control

   • Protect sensitive files and directories.
   • Disable directory listing on the server.

6. Regular Testing

   • Test your website for information leaks.
   • Include these checks in security reviews and penetration tests.

Summary#

• Information disclosure is when a site leaks sensitive information by mistake.
• Even small details can help attackers.
• Attackers look for errors, comments, backups, and bad settings.
• Prevent it with awareness, clean code, safe configurations, and regular testing.

Information Disclosure Labs - Explanations#

1. Information Disclosure in Error Messages#

What is it? When the website shows detailed error messages that give away sensitive information. This might include:

• Database table names
• Server paths
• Code details

How to exploit it:

• Cause errors on purpose (e.g., send bad input).
• Read the error message carefully.
• Find any details that help plan further attacks.

How to prevent:

• Show simple, generic error messages to users.
• Log detailed errors only on the server.

2. Information Disclosure on Debug Page#

What is it? Some websites leave debug pages active. These pages are meant for developers but leak:

• Server configuration
• Database connection info
• Environment variables

How to exploit it:

• Look for common debug URLs (e.g., /debug, /info).
• Access them directly.
• Gather the sensitive information shown.

How to prevent:

• Disable all debug features in production.
• Restrict access to debug pages.

3. Source Code Disclosure via Backup Files#

What is it? Developers sometimes leave backup or old files on the server, like:

• index.php.bak
• old.zip
• backup.tar.gz

These files often contain full source code.

How to exploit it:

• Guess or brute-force common backup file names.
• Download and review them.
• Find credentials or logic you can abuse.

How to prevent:

• Do not store backups on the public server.
• Remove unused files before deployment.

4. Authentication Bypass via Information Disclosure#

What is it? Leaked information that helps bypass login or gain access without valid credentials. Examples:

• Error responses that reveal if a username exists.
• Tokens or passwords in logs or error messages.

How to exploit it:

• Observe differences in responses when you enter valid vs. invalid data.
• Use that info to guess or confirm credentials.

How to prevent:

• Return the same response for valid and invalid login attempts.
• Never log or expose sensitive info in responses.

5. Information Disclosure in Version Control History#

What is it? Developers sometimes upload .git or other version control folders by mistake. Attackers can download:

• Source code
• Secrets in commit history
• Deleted files

How to exploit it:

• Check if .git is accessible.
• Clone or download it.
• Review all commits for secrets.

How to prevent:

• Never expose version control folders on production servers.
• Use .gitignore and server rules to block them.

Information Disclosure - Labs Summary#

This document explains what we learned from each Information Disclosure lab.
It describes the idea, why it matters, and the key takeaway – without step-by-step solving instructions.

1️⃣ Information disclosure in error messages#

Idea:
Applications sometimes show detailed error messages that reveal internal details (like framework version, stack traces).

Why it matters:
Attackers can use this information to identify the exact software version and search for known vulnerabilities.

Key lesson:
Always show generic error messages in production. Don’t leak internal implementation details.

2️⃣ Information disclosure on debug page#

Idea:
Exposed debug pages can reveal sensitive environment variables and configuration data.

Why it matters:
These pages may leak secrets (API keys, database passwords) that give attackers direct access to systems.

Key lesson:
Disable debug pages in production. Don’t expose environment variables or sensitive settings to users.

3️⃣ Source code disclosure via backup files#

Idea:
Leaving backup or old source files on the server can expose your code to the public.

Why it matters:
Source code often contains hard-coded secrets or reveals how the application works, making it easier to attack.

Key lesson:
Clean up and remove backup files before deploying. Never store sensitive files in public directories.

4️⃣ Authentication bypass via information disclosure#

Idea:
Applications sometimes rely on hidden headers or special values for authentication. If these are exposed, attackers can spoof them.

Why it matters:
Information disclosure can reveal these secrets, allowing attackers to bypass access controls.

Key lesson:
Never trust client-controlled headers for authentication. Validate users securely on the server side.

5️⃣ Information disclosure in version control history#

Idea:
Even if secrets are removed from code, they can remain in version control history (like Git).

Why it matters:
Attackers accessing exposed .git folders can recover old commits with hard-coded passwords or secrets.

Key lesson:
Never commit secrets. Clean version history before sharing. Block access to version control folders on servers.

General Takeaway#

Information disclosure isn’t always an instant breach, but even small leaks can give attackers the pieces they need for bigger attacks.
Good security means controlling what you reveal.