Source Code Review for Vulnerabilities

Source code review (also called static analysis or white-box testing) is the process of examining an application's source code to identify security vulnerabilities. Unlike dynamic analysis (penetration testing against a running application), source code review does not require the application to be executed. The reviewer reads the code and identifies potential security issues by looking for dangerous functions, insecure coding patterns, and logic flaws.

Many vulnerabilities are introduced during development due to programmer error, lack of security awareness, or time pressure. Common vulnerabilities like SQL injection, cross-site scripting (XSS), buffer overflows, and insecure direct object references (IDOR) often have telltale signs in the source code that can be spotted before the application is deployed. By reviewing source code, organizations can catch these issues early, reducing the cost and risk of exploitation.

Source code review can be performed manually or with automated tools. The process generally follows these steps:

While source code review does not involve running commands on a live system, you may use tools from the command line. For example:

# Using SonarScanner to analyze a project
sonar-scanner \
  -Dsonar.projectKey=my_project \
  -Dsonar.sources=. \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.login=myauthenticationtoken

# Using Flawfinder (open-source C/C++ analyzer)
flawfinder --html my_source.c > results.html

For manual review, common commands to search code for dangerous functions:

# Search for dangerous PHP functions
grep -rn "eval(" .
grep -rn "system(" .
grep -rn "exec(" .

# Search for SQL queries in Python
grep -rn "execute(" .

SQL Injection - Look for dynamic SQL queries constructed by concatenating user input. - Example vulnerable code (PHP):

$query = "SELECT * FROM users WHERE username = '" . $_GET['username'] . "'";
$result = mysqli_query($conn, $query);

Cross-Site Scripting (XSS) - Look for user input reflected in HTML output without proper encoding. - Example vulnerable code (Java):

out.println("<p>Welcome, " + request.getParameter("name") + "</p>");

Buffer Overflow - Common in C/C++ code using unsafe functions like strcpy(), sprintf(), gets(). - Example:

char buffer[10];
strcpy(buffer, user_input); // no bounds checking

Insecure Direct Object Reference (IDOR) - Look for endpoints that use user-supplied identifiers without authorization checks. - Example (REST API):

@app.route('/api/user/<int:user_id>')
def get_user(user_id):
    # No check if current user is allowed to access this user_id
    user = db.query("SELECT * FROM users WHERE id = ?", user_id)
    return jsonify(user)

Path Traversal - Look for file operations that use user input to construct file paths without sanitization. - Example:

$file = $_GET['file'];
include("/var/www/html/" . $file); // allows ../../etc/passwd

Insecure Cryptographic Storage - Look for hardcoded encryption keys, use of weak algorithms (e.g., DES, MD5), or improper initialization vectors. - Example:

String key = "1234567890123456"; // hardcoded 16-byte key for AES

Source code review is a vital component of a comprehensive security assessment. It requires a combination of automated tools and manual expertise. The PT0-002 exam will test your ability to identify common vulnerability patterns in code snippets and understand the role of source code review in the penetration testing lifecycle.

A large e-commerce company hired a penetration testing firm to review the source code of their custom-built shopping cart application before a major release. The application was written in Java and used Spring MVC with Hibernate for database access. The testing team performed a manual source code review focusing on the checkout and payment processing modules. They discovered an SQL injection vulnerability in the order lookup feature where the order ID was taken directly from the URL parameter and concatenated into a SQL query. The fix was to use parameterized queries. They also found that credit card numbers were logged in plaintext in the application logs, which violated PCI DSS. The team recommended encrypting log entries and masking sensitive data. The automated SAST tool (Fortify) had flagged the SQL injection but missed the logging issue because it was a configuration problem, not a code flaw. This highlights the need for manual review to complement automated tools.

A healthcare startup needed to ensure their patient portal was compliant with HIPAA. They used SonarQube to perform continuous static analysis on their Python Django codebase. The tool flagged several instances of hardcoded secret keys in settings files and insecure direct object references in API endpoints. However, the development team initially ignored many warnings as false positives. A manual review by a security consultant confirmed that the IDOR findings were real: any authenticated user could access another patient's medical records by changing the patient ID in the URL. The consultant also identified a business logic flaw where user roles were not properly enforced in the admin panel, allowing a regular user to promote themselves to admin. This logic flaw was not detected by SonarQube because it did not have rules for business logic. The company implemented role-based access control and added additional manual review steps to their CI/CD pipeline.

In large codebases (millions of lines), automated tools can take hours to scan. To manage this, organizations often run incremental scans on changed files only, or schedule full scans overnight. False positives are a major challenge: tools may flag thousands of issues, but many are not exploitable. A common mistake is to dismiss all tool findings as false positives without manual verification. Conversely, some teams fix every finding without understanding the context, leading to wasted effort. The best practice is to triage findings based on risk, validate each one manually, and prioritize by exploitability and impact.