CSC 4585/5585: Software and Systems Security

Automated Static Code Analyzer

Fawaz Alkharaa
 Task 1

Horusec

The static analysis performed with Horusec on the DVWA application revealed 13 vulnerabilities
with 8 being critical and 5 being high severity.

Critical Vulnerabilities
1. JavaScript (Line 7, Column 3) - Use of eval function (RCE)
- File: /dvwa/js/dvwaPage.js
- Details: The eval function is dangerous due to the risk of remote code execution (RCE) if user
input is not sanitized. (CWE-94)
2. JavaScript (Line 1, Column 9842) - Use of eval function (RCE)

- File: /vulnerabilities/javascript/source/high.js
- Details: Another instance of the eval function, posing a similar RCE risk. (CWE-94)
3. Leaks (Line 4, Column 1) - Hard-coded password
- File: /vulnerabilities/sqli/test.php
- Details: The software contains a hard-coded password, making it vulnerable to attacks if
exploited. (CWE-798)
4. Leaks (Line 34, Column 79) - Potential hard-coded credential

- File: /dvwa/includes/DBMS/PGSQL.php
- Details: Hard-coded database credentials were detected. This can be exploited for
unauthorized access. (CWE-798)
5. Leaks (Line 41, Column 8) - Hard-coded password
- File: /vulnerabilities/cryptography/source/low.php
- Details: The password “Olifant” is hard-coded into the file, increasing risk of credential
exposure. (CWE-798)
6. Leaks (Line 566, Column 56) - Potential hard-coded credential

- File: /dvwa/includes/dvwaPage.inc.php
- Details: Credentials, such as database names and passwords, were hard-coded. (CWE-798)
7. Leaks (Line 571, Column 55) - Potential hard-coded credential
 - File: /dvwa/includes/dvwaPage.inc.php
- Details: More hard-coded credentials related to the database. (CWE-798)

8. Leaks (Line 674, Column 7) - Hard-coded password

- File: /dvwa/includes/dvwaPage.inc.php
- Details: A hard-coded database password found in the code. (CWE-798)

High-Severity Vulnerabilities

1. JavaScript (Line 8, Column 15) - Cross-origin communications

- File: /dvwa/js/add_event_listeners.js
- Details: Lack of origin verification in cross-origin communications, leading to potential
message spoofing attacks. (OWASP A2:2017)
2. JavaScript (Line 16, Column 4) - Use of alert statement
- File: /dvwa/js/dvwaPage.js
- Details: Usage of alert, which can expose sensitive data if displayed in production. (CWE-489)

3. JavaScript (Line 38, Column 8) - Use of confirm statement

- File: /dvwa/js/dvwaPage.js
- Details: Use of confirm pop-up dialogs which are discouraged in production due to the risk of
exposing sensitive information. (CWE-489)
4. JavaScript (Line 16, Column 13) - Cross-origin communications
- File: /vulnerabilities/csp/source/high.js

- Details: Another case of unverified origins during cross-origin communication. (OWASP

A2:2017)

5. JavaScript (Line 16, Column 13) - Cross-origin communications

- File: /vulnerabilities/csp/source/impossible.js
- Details: Lack of origin verification during cross-origin communication. (OWASP A2:2017)

Key Insights
Remote Code Execution (RCE) via eval function
Using eval poses risks because it makes it easy to run arbitrary code, which is extremely risky, and
potentially allows for remote code execution (RCE) if user input is not adequately filtered. The
safer alternative would be JSON.parse() or template literals for string concatenation. To execute
dynamic code, it is advised to use function constructors with proper input sanitization so that no
bad code is executed.
Hard-coded Credentials
If an attacker gains access to the source code, then embedding passwords and other credentials
into code makes it much more likely to be exposed. Static configuration should not be used but
rather environment variables (or any other secret management tool) such as HashiCorp Vault,
AWS Secrets Manager, orAzure Key Vault. With these tools, sensitive data is protected, and not
include this information as part of the source code.
Cross-Origin Communication without Origin Verification:
When communications are performed cross-origin than the failing to verify offers of message
spoofing attack. To ensure a secure transfer, it is essential to specify the exact trusted origin in the
communication instead of accepting any origin with the use of the wildcard *. Moreover, for a
receiving function, it is important to verify the sender’s identity by checking the origin attribute,
before processing the message. This makes sure that your messages can only come from
legitimate sources.
Insecure Pop-ups (alert, confirm, prompt)

Triggering native pop-up dialogs such as alert, confirm, and prompt might disclose sensitive
information or act unthought of by user if an attacker so like to. Rather than using these, build
custom modal dialogs inside the application’s interface. It offers better control over how input
from user is handled, sanitizes the input properly and also eliminates the pop-up access to
production environments.

PHPCS-security
The PHPCS-security audit identified multiple vulnerabilities in the DVWA.
1. Dynamic Parameter Usage

 MYSQLi Queries: Detected in multiple files with warnings due to dynamic parameters,
which can expose the application to SQL Injection vulnerabilities. Examples include:
 /login.php: mysqli_query() detected with dynamic parameters.
 /dvwa/includes/dvwaPage.inc.php: Multiple instances of mysqli_query() with
dynamic parameters.
  Other vulnerabilities include various levels of SQL injection exposure in files like
/vulnerabilities/sqli_blind/source/high.php,
/vulnerabilities/brute/source/low.php, and
/vulnerabilities/captcha/source/medium.php.

2. Filesystem Functions with Dynamic Parameters

 Functions like file_exists(), realpath(), copy(), move_uploaded_file(), and getimagesize()

were found to use dynamic parameters across different files.

 For example, the /dvwa/includes/dvwaPage.inc.php uses file_exists()

with dynamic parameters, which may lead to path traversal attacks or
remote file inclusion.

3. Direct User Input Handling

 Several errors were reported related to unsafe handling of user inputs, such as:
 /vulnerabilities/csp/source/low.php: HTML construction with direct user
input via $_POST.
 /vulnerabilities/xss_r/source/low.php: HTML construction with direct
user input via $_GET. These errors open the door for Cross-Site Scripting
(XSS) and Injection Attacks.
4. Function Callbacks and System Command Execution

 Dynamic Function Callbacks: Usage of call_user_func() and array_map() with dynamic

parameters in files like /dvwa/includes/Parsedown.php can lead to remote code
execution.
 Shell Execution: Functions like shell_exec() detected with dynamic parameters in files
under /vulnerabilities/exec/source, representing a significant risk of command injection.
5. Unsafe Include/Require Usage

 Missing file extensions in several include() and require() statements, implying that some
PHP code is not scanned. This weakens code integrity checks and can facilitate file
inclusion attacks.
 Example: /vulnerabilities/sqli_blind/index.php.

6. Eval() Usage
  eval() was found in /vulnerabilities/view_help.php, which is highly risky as it allows
execution of arbitrary PHP code, leading to remote code execution.

Highlights

 SQL Injection risks are prevalent due to dynamic parameters in mysqli_query() functions.
These should be mitigated by using prepared statements with bound parameters.
 Cross-Site Scripting (XSS) vulnerabilities can be reduced by sanitizing user inputs before
embedding them into HTML responses.
 Filesystem Operations should validate and sanitize input to prevent directory traversal or
unauthorized file access.
 Callback functions like call_user_func() should be replaced with direct function calls or
more secure alternatives.
 The use of eval() should be avoided altogether due to its high security risks.

Task 2

Aspect PHPCS Security Audit Horusec

Ease of Use Simple setup, minimal Requires setup, tokens, and flags
configuration. for comprehensive reporting.
May overwhelm beginners with Better suited for advanced
verbose output. setups (e.g., CI/CD integration).
Detail of Reports Flags violations in PHP coding Detailed categorization (Critical,
standards, such as dynamic High, Medium vulnerabilities).
parameters in SQL.
Provides CWE references and
Focus on PHP-specific issues. detailed vulnerability insights
Coverage of Focuses on PHP files and coding Covers multiple languages (PHP,
Vulnerabilities best practices. JavaScript) and more critical
issues.
Limited scope: does not analyze
JavaScript or other non-PHP code. Broader language support,
covering hard-coded credentials,
RCE, and XSS.
Unique Dynamic parameters in MySQLi Hard-coded credentials, misuse
Vulnerabilities functions, missing file extensions in of eval(), cross-origin
Identified include/require. communication issues.
Overlaps of Both tools identified SQL injection Both flagged potential issues
Vulnerabilities risks and dynamic SQL parameters. with file handling and SQL
Found queries.
 Other Insights Best for enforcing PHP-specific More security-focused,
standards. identifying critical vulnerabilities.

Lacks multi-language analysis. Stronger for multi-language,

security-centric audits.

The table above compares and contrasts between PHPCS Security Audit and Horusec based on
their operational mode and result, obtained when used to scan the DVWA project. Ease of use
wise, PHPCS Security Audit is one of the simplest and requires very little setting up. It is relatively
simple to administer ensuring it suits PHP developers whose main objective is to maintain coding
standards. However, the output of the tool can be quite extensive and while for experts, this is
not an issue, for beginners it might be rather unpleasant particularly if the latter has no prior
experience in PHP coding standards. In turn, Horusec needs more efforts in initial configuration
like the usage of tokens and special flags for the detailed report. In return, while having more
functions shown to enhance security, Horusec should be geared for power users deploying it as
part of CI/CD pipelines for automated audits.

The writing style or structure of the two tools also vary in the extent of detail provided in their
reports. PHPCS Security Audit in fact is still more directed at the coding standard violations which
include things like using dynamic parameters for your SQL queries or file extensions in your
include/require statements. It provides detailed PHP-specific feedback, but it does not classify
the vulnerabilities by their severity and this can hamper the security improvement prioritization.
On the other hand, Horusec offers some more extensive and, especially, security-related reports.
The following flaws splits them up into three classes, Critical, High, and Medium that helps with
differentiation between the problems that have to be solved immediately and those, which can
wait. Horusec also has links to CWE that gives the developer more information and detailed
advice on how to avoid the vulnerabilities identified by Horusec.

In as much as vulnerabilities, what is specific to PHPCS Security Audit is that it only gets concerned
with PHP files such that any problems in other languages of parts of the project go unnoticed. It
does not cover JavaScript and multi-language support; however, it is explicitly focused on PHP
practices. In contrast, Horusec identifies and categorizes a broad set of vulnerabilities, and within
different languages, in the same project. First, it analyses crucial security threats in PHP but also
in JavaScript, including cross-origin messaging problems and eval() functions; thus, it is more
efficient as a security scanning tool in multi-lingual platforms.
The tools are also unique in that they also estimate different types of risks. Although PHPCS
Security Audit is better in identifying the PHP coding standards, there are certain limitations of
PHPCS Security Audit such as inability to identify the problem associated with dynamic
parameters in MySQLi queries or missing file extension for the include/require function parts of
the code base may not be analyzed. Nevertheless, Horusec found more critical issues, which are
hardcoded credentials, possible RCE problems. The problems we found, particularly with
JavaScript code, were not detected by PHPCS, which proved that Horusec works on a higher level
of code security.
Both tools highlighted overlapping concerns – weak information handling and specifically, SQL
injection concerns linked to dynamic parameters included in SQL queries. Both of them also
expressed concern in dealing with files. However, what is important to note here is that while
there are many similarities with both Horusec and LART, there is a difference in the data both
tools present based on the type of vulnerability with Horusec posing more depth oriented
security threats.

Task 3
To streamline the Software Development Life Cycle (SDLC) process, it is essential to
address the specific vulnerabilities found by both Horusec and PHPCS-security tools in the DVWA
application. Below are potential fixes and best practices that developer teams can implement to
mitigate these risks.

Suggested Fixes for Vulnerabilities Identified by Horusec

Remote Code Execution (RCE) via eval function

The eval() function is incredibly risky, as it leads to Remote Code Execution (RCE). This
vulnerability exists in the scripts:DVWA/default/scripts/dvwaPage.js and
Vulnerabilities/Javascript/source/high.js. To reduce this risk, developers should avoid the use of
eval() function or if it is necessary then use a safer version like JSON.parse() or use template
literals instead of concatenation. In case, there is a necessity to utilize the dynamic code
execution, it is required to use function constructors properly in combination with input filtering
in order to protect against code execution at the script level.
Hard-Coded Credentials
User name and password were also found hardcoded in several files such as;
/vulnerabilities/sqli/test.php, /dvwa/includes/DBMS/PGSQL.php and
/dvwa/includes/dvwaPage.inc.php It is undesirable to store passwords in the program code
because anyone can easily gain access to the system. Compilers should add an importance to use
environment variables or third-party services such as AWS HC, ASM, AKV, and HV. Most of these
tools ensure that they keep important credentials safe by avoiding exposing them in the source
code.

Cross-Origin Communication without Origin Verification

For cross-origin communication /dvwa/js/add_event_listeners.js and
/vulnerabilities/csp/source/high.js are mismanaged. This needs to be changed and instead of the
use of the wildcard (*) the trusted origins should be defined. Whenever using cross-origin
communication, developers have to check on the origin attribute to ensure that the messages
they receive are from trusted sources. This minimizes the possibility of getting a spoofing attack
messages which may not be from the genuine sender.

Insecure Pop-ups (alert, confirm, prompt)

Scripts such as dvwaPage function located in the file of /dvwa/js/dvwaPage.js use native
JavaScript pop-ups for example alert(), confirm(), which are really dangerous in production
environments. These should be substituted by custom modal dialogs that are adjuncts of the
application. Custom modals give better control over user input, enable correct input cleaning and
can reduce an opportunity to share some important information by mistake.

Suggested Fixes for Vulnerabilities Identified by PHPCS-security

SQL Injection (SQLi) Vulnerabilities

Due to the dynamic parameters mysqli_query(), the occurrences of SQL Injection
vulnerabilities were reported to files such as /login.php and
/vulnerabilities/sqli_blind/source/high.php. To avoid being vulnerable to SQLi, developers ought
to make a switch to prepared statements with parameterised queries. Stemming directly from
the ability to script statements, prepared statements have the added benefit of allowing only
direct data to be placed into the query; specifically, the user’s input cannot influence the
construction of the query itself.

Filesystem Functions with Dynamic Parameters

GET functions tallying up file_exists(), realpath() and move_uploaded_file(), were
discovered to be used with dynamic parameters in files inclusive of
/dvwa/includes/dvwaPage.inc.php. This is a security concern since an attacker can use it to
perform path traversal or a remote file inclusion attack. In this case, it is advisable that developers
confirm and cleanse all content inputs before they are passed as arguments on filesystem
functions. This will help to make sure that the file system only gets to access valid file paths.
Direct User Input Handling

One of the breaches highlighted in scripts as in files like

/vulnerabilities/csp/source/low.php was unsafe use of $_POST or $_GET variables by including
them in HTML tags without proper cleansing of the inputs. A good example for filtering input is
htmlspecialchars() in PHP; which converts special characters such as ” < > & and % into their
equivalents in HTML allowing the prevention of cross site scripting – XSS.

Dynamic Function Callbacks and System Command Execution

Using call_user_func() and shell_exec() with dynamic parameters even in files like
/dvwa/includes/Parsedown.php and /vulnerabilities/exec/source/low.php results in enabling of
RCE and command injection attack. To remove these dynamic function callbacks developers
should instead use direct function calls. For command execution, it is safer to use prepared or to
control the command execution processes.
Unsafe Include/Require Usage:
The absence of file extensions in include() or require() statements like those present in
/vulnerabilities/sqli_blind/index.php has the effect of making code inclusion and scanning less
secure. All code should always be included and scanned by using fully qualified path with the file
extensions to check for any security vulnerabilities.
Avoid the Use of eval():
The use of eval() was detected in /vulnerabilities/view_help.php, which poses a high risk
of remote code execution. The eval() function should be avoided entirely, as it allows for arbitrary
code execution. Developers should refactor the code to eliminate eval() and use safer alternatives
that do not involve executing raw PHP code dynamically.