Source code disclosure

What is source code disclosure?

Source code disclosure happens when an unauthorized party gets access to the source code of a web application or API. This can be caused by web server misconfigurations or vulnerabilities in the web application or API. Source code disclosure is often considered a type of information disclosure attack.

How is source code disclosure possible?

Web applications and APIs are usually built using two different approaches:

• The source code of the application is executed by the web server on the fly using a built-in interpreter, as in PHP applications.
• The source code of the application is pre-compiled to byte code and then executed, as in Java applications.

In cases where the source code is executed directly, if the web server fails to recognize that a file should be executed by an interpreter, it will respond by sending the source file itself to the requesting web browser (instead of interpreting the source server-side and sending only the result).

Source code disclosure can also occur even when the source code is precompiled. Although most development environments rely on repositories, the actual source code might temporarily be stored in a different directory in plain text. If web vulnerabilities make it possible to access such a directory, you have source code disclosure.

Why is source code disclosure dangerous?

The source code of an application may contain sensitive information. Attackers may use this information for their direct competitive advantage or for privilege escalation/privilege elevation to help them continue the attack. Here are some typical attack scenarios:

• The attacker sells the disclosed source code to a company that wants to build a similar application to compete on the market.
• The attacker discovers that some source code files contain sensitive information, such as the database password. They can then try to access the database and steal more sensitive data.
• The attacker analyzes the source code and discovers other security flaws, for example, SQL injection vulnerabilities. Information obtained from the source code then makes it easier to perform other attacks against the web application.

What vulnerabilities cause source code disclosure?

Source code disclosure vulnerabilities can result from many different types of vulnerabilities and server misconfigurations. Here are some examples of typical vulnerabilities and misconfigurations that cause source code disclosure:

• Web server misconfigurations where the server doesn’t recognize some file names as executable files but instead sends them in plain text in its response. For example, if the web server is not configured to treat .php files as executable, when you request index.php, your browser will display the source code of index.php rather than the expected web page.
• Network security vulnerabilities in the web server software. For example, an old vulnerability in Microsoft IIS (CVE-2001-0709) allowed an attacker to specify the file extension in Unicode (for example, index.%61%73%70), which caused the server to treat .asp files as text instead of executing them (this only affected FAT partitions).
• Web application security vulnerabilities such as local file inclusion (LFI) and directory traversal. Local file inclusion allows an attacker to display/download files located in the web server root structure, so it can be used to display interpreted source code files. If combined with directory traversal, LFI allows the attacker to display files located anywhere on the server (provided the web server user has permission to access the directories) and find the source code even for precompiled apps such as Java apps.
• Directory listing vulnerabilities enable an attacker to view the content of directories that include source code. This lets the attacker not only access these files (if the server is misconfigured and displays them) but also discover all the files that make up the web application.
• Unprotected source code repositories can also lead to source code disclosure. For example, SVN or Git repositories may be configured to allow remote access by developers that work from home. With insufficient protection, third parties may be able to access the source code in these repositories.

Note that the above list is not exhaustive. For example, attackers can use techniques that prevent code from being interpreted in order to gain access to the raw source code instead of the interpreted result.

Source code disclosure is classified in the OWASP Top 10 as A01:2021 – Broken Access Control, in the Common Weakness Enumeration as CWE-540: Inclusion of Sensitive Information in Source Code, and by the Web Application Security Consortium as WASC-13: Information Leakage. Note that each of these classifications uses different criteria to define the main security risk, such as exposing information included in the source code or enforcing insufficient access control that allows exposure in the first place.

Example of a source code disclosure attack

In this example, the attacker finds a local file inclusion vulnerability on example.com and accesses the following download.php file:

<?php
// Import global config values
include('admin/config.php');

// Get the filename provided by the user
$filepath = $_GET['filename'];
if ($filepath) {
 // Database connection string
 $connection = mysqli_connect($cfg['DATABASE']['HOST'], $cfg['DATABASE']['UNAME'], $cfg['DATABASE']['PASS'], 'logs');
 if (!$connection) {
   die('Could not connect: '.mysqli_connect_error($connection));
 }
 $user_agent = $_SERVER['HTTP_USER_AGENT'];

 // Used by stats.php to track download trends
 $sql = "INSERT INTO stats VALUES ('$filepath', now(), '$user_agent')";
 $result = mysqli_query($connection, $sql);
 if (!$result) {
   echo 'DB Error: '.mysqli_error($connection);
   exit;
 }

 // Clean up and send the file
 mysqli_close($connection);
 header('Content-Disposition: attachment; filename=' . basename($filepath));
 readfile($filepath);
}
?>

An analysis of the download.php source code reveals information that allows for escalation. For example, the comment Used by stats.php to track download trends suggests the existence of a stats.php file, and there is an include directive for the admin/config.php file. Exploiting the same vulnerability, the attacker can now download both these files, starting with config.php:

<?php
 $cfg['TITLE'] = 'Example';
 $cfg['BASE_URL'] = 'http://www.example.com/';
 $cfg['DATABASE']['TYPE'] = 'mysql';
 $cfg['DATABASE']['HOST'] = 'localhost';
 $cfg['DATABASE']['UNAME'] = 'root';
 $cfg['DATABASE']['PASS'] = 'nx01-74656-ds9-b5';
?>

Now the attacker knows that the database is hosted on the same server as the web application, and that the database server is MySQL.

The second file to download is stats.php:

<?php
// Import global config values
include('admin/config.php');
print '<table style="width:100%">';
print '<tr><th>Available Files</th>';
print '<tr><td><a href="' . $cfg['BASE_URL'] . 'stats.php?filename=aboutus.pdf">About Us (PDF)</a></td>';
print '<tr><td><a href="' . $cfg['BASE_URL'] . 'stats.php?filename=pricing.html">Pricing (HTML)</a></td>';
print '<tr><td><a href="' . $cfg['BASE_URL'] . 'stats.php?filename=services.pdf">Services (PDF)</a></td>';
print '</table>';
print '<br><br>';
$filepath = $_GET['filename'];
if ($filepath) {
 $connection = mysqli_connect($cfg['DATABASE']['HOST'], $cfg['DATABASE']['UNAME'], $cfg['DATABASE']['PASS'], 'logs');
 if (!$connection) {
  die('Could not connect: '.mysqli_connect_error($connection));
 }
 $sql = "SELECT * FROM stats WHERE filename = '$filepath'";
 $result = mysqli_query($connection, $sql) or die(mysqli_error($connection));
 print '<table style="width:100%; border: 1px solid black; text-align: left;">';
 print '<tr><th>Filename</th><th>Timestamp</th><th>User-Agent String</th></tr>';
 while ($row = mysqli_fetch_assoc($result)) {
   print "<tr>";
   foreach ($row as $column => $value) {
     print "<td style='text-align: left;'>$value</td>";
   }
   print "</tr>";
 }
 print '</table>';
}
?>

The stats.php file lists the download history for a particular set of files. The records are fetched directly from the same table that download.php uses to log downloads. The file path is taken directly from the request with no input validation. Because the developer did not use a parameterized query, the app probably has an SQL injection vulnerability. For example, the attacker may try calling the following URL:

http://www.example.com/stats.php?filename=%27%20UNION%20SELECT%20%40%40version%2C%20null%2C%20null%23

Without URL encoding, the filename value is ' UNION SELECT @@version, null, null#. If executed by the server, this query displays the database version and confirms there is an SQL injection vulnerability. From now on, the malicious hacker can escalate the attack even further.

How to detect source code disclosure?

Since there are many different vulnerabilities and misconfigurations that can cause source code disclosure, including web vulnerabilities, web server misconfigurations, and network vulnerabilities, you may need to use different methods and tools to discover all possible causes. Using a modern dynamic application security testing tool such as Invicti or Acunetix by Invicti, you can discover web vulnerabilities and web server misconfigurations. The SCA functionality available in such products also lets you discover open-source components that are known to have such vulnerabilities.

Note that some limited source code exposure may sometimes be intentional, for example, on web pages with educational content. Any automated scanning should therefore be paired with manual security reviews. Periodic penetration testing is also needed to deal with complex business logic vulnerabilities and other security issues that require manual intervention.

How to prevent source code disclosure?

Source code disclosure can be caused by many different vulnerabilities and misconfigurations, so there is no single way to prevent it. To avoid source code disclosure, follow these general recommendations:

• Make sure your web server software is up to date.
• Check your web server configuration and make sure that all source code files are set as executable by the server so they are not served to the requester. Also ensure that directory listing functionality is turned off.
• Perform user input validation in your web applications and follow secure coding practices to avoid other vulnerability types, such as LFI and directory traversal. For example, avoid passing filenames in user input, or at least create a whitelist of safe files. Where possible, you may also run your web apps in safe containers such as Docker.