Project Overview

#

This project presents a black-box web application penetration test performed against a public-facing corporate website from the perspective of an unauthenticated external attacker.

The assessment followed the OWASP Web Security Testing Guide (WSTG) and focused on reconnaissance, attack surface mapping, passive security analysis, controlled manual active testing, vulnerability validation, risk assessment, and remediation planning.

The assessment was conducted using a controlled and non-destructive approach. Automated active scanning was intentionally limited because anti-automation or WAF-like controls were observed during testing.

Assessment Notice

This project was conducted as an authorized academic security assessment. The public version of the report has been sanitized to remove target-identifying information, URLs, and sensitive screenshot content.

Executive Summary

#

The assessment identified one High-severity confirmed vulnerability and several configuration and client-side security weaknesses.

The most significant finding was an error-based SQL Injection vulnerability affecting a product page parameter. A controlled, non-destructive validation caused the application to disclose database error information, including the backend database version and part of the SQL query structure.

Additional findings included missing browser security headers, incorrect content-type handling for an AJAX response, missing Subresource Integrity for third-party resources, publicly accessible attachment paths, development comments in production resources, and a recommendation for a more complete client-side dependency review.

The overall security risk was assessed as High, primarily because the confirmed SQL Injection was reachable through a public unauthenticated endpoint.

Assessment Overview

#

The assessment scope covered public website functionality, dynamic PHP parameters, AJAX-like endpoints, static resources, public attachments, HTTP response headers, HTTPS behavior, and publicly visible client-side source code.

Objectives

#

The primary objectives of the assessment were to:

• Identify publicly exposed application functionality and attack surface.
• Review dynamic parameters for input validation weaknesses.
• Assess HTTP security headers and HTTPS configuration.
• Identify information disclosure and insecure configuration issues.
• Perform controlled validation of potentially exploitable vulnerabilities.
• Assess the security impact of identified findings.
• Provide remediation recommendations and retest guidance.

Methodology

#

The assessment followed the OWASP Web Security Testing Guide and was organized around the following activities:

1. Information Gathering and Reconnaissance
2. Configuration and Deployment Management Testing
3. Identity, Authentication, Authorization, and Session Management Review
4. Input Validation Testing
5. Error Handling Review
6. Weak Cryptography and HTTPS Review
7. Business Logic Review
8. Client-Side Testing
9. AJAX/API-like Endpoint Testing
10. Reporting and Remediation Planning

Testing Workflow

#

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

Reconnaissance
      ↓
Attack Surface Mapping
      ↓
Passive Testing
      ↓
Manual Active Testing
      ↓
Vulnerability Validation
      ↓
Risk Assessment
      ↓
Remediation Planning
      ↓
Reporting

Tools Used

#

The following tools and techniques were used during the assessment:

• Burp Suite — HTTP interception, sitemap generation, request/response analysis, and manual validation
• OWASP ZAP — passive proxying, sitemap generation, and URL inventory
• curl — HTTP response and security-header analysis
• dig — DNS reconnaissance
• Web Browser / Developer Tools — manual application and client-side analysis

Burp Suite and OWASP ZAP were primarily used for passive analysis and attack-surface mapping, while active validation was performed manually at a low rate to minimize impact.

Key Findings

#

Featured Finding

#

WEB-01 — Error-Based SQL Injection

#

Severity: High Status: Confirmed Category: Input Validation OWASP WSTG: WSTG-INPV-05 — Testing for SQL Injection

Description

#

A product page parameter was found to be vulnerable to error-based SQL Injection.

A controlled, non-destructive input caused the application to return a database error in the HTTP response. The response disclosed database information and part of the backend SQL query structure.

The vulnerable behavior was reachable through a public unauthenticated endpoint.

Evidence

#

The vulnerability was validated by comparing a normal baseline request with a modified request containing a controlled SQL Injection test input.

The modified request resulted in an application response containing:

• A database error message.
• The backend database version.
• A fragment of the SQL query structure.

The public portfolio version intentionally omits target-identifying URLs, hostnames, IP addresses, and sensitive raw request details.

Impact

#

Depending on database privileges and application logic, successful exploitation of the underlying SQL Injection could potentially allow:

• Database metadata enumeration.
• Unauthorized access to application data.
• Further server-side exploitation.
• Database manipulation if sufficient privileges are available.

The disclosed database error information also provides useful intelligence for further targeted attacks.

Root Cause

#

The observed behavior indicates that user-controlled input was processed unsafely within a backend SQL statement.

Detailed database error messages were also exposed directly through production HTTP responses.

Recommendation

#

• Use parameterized queries or prepared statements for all database operations.
• Enforce strict server-side validation for numeric parameters.
• Reject unexpected input types before database interaction.
• Disable detailed SQL and PHP error output in production.
• Return generic error responses to users.
• Log detailed diagnostic information only on the server side.
• Review other dynamic endpoints for similar SQL Injection weaknesses.

Retest Guidance

#

After remediation, repeat the controlled SQL Injection validation.

The application should:

• Reject malformed input safely.
• Avoid returning SQL errors.
• Avoid disclosing database version information.
• Avoid exposing SQL query fragments.

Additional Findings

#

WEB-02 — Missing Content Security Policy Header

#

Severity: Medium Status: Confirmed

Sampled HTTP responses did not include a Content-Security-Policy header.

CSP provides browser-side defense-in-depth by controlling the origins from which scripts, styles, images, frames, and other resources may be loaded.

Recommendation

#

Implement an appropriate Content Security Policy and initially validate it in report-only mode before enforcing the policy.

Where possible, avoid unnecessary use of unsafe-inline and migrate toward nonces or hashes.

WEB-03 — Missing HTTP Strict Transport Security Header

#

Severity: Low Status: Confirmed

HTTP traffic was observed redirecting to HTTPS, but sampled HTTPS responses did not include the Strict-Transport-Security header.

Recommendation

#

Implement HSTS with an appropriate max-age value after confirming that all required application functionality and subdomains support HTTPS.

WEB-04 — Missing Referrer-Policy and Permissions-Policy Headers

#

Severity: Low Status: Confirmed

The sampled responses did not include:

• Referrer-Policy
• Permissions-Policy

These headers provide additional browser security hardening and help control referrer information and access to browser capabilities.

Recommendation

#

Implement appropriate policies based on the application’s functional requirements.

WEB-05 — Incorrect Content Type for AJAX Response

#

Severity: Low Status: Confirmed

An AJAX-like endpoint returned a JSON-style response body while declaring the response as text/html.

This mismatch may result in inconsistent behavior between browsers, proxies, and security tooling.

Recommendation

#

Return the response using the appropriate JSON content type:

1

Content-Type: application/json; charset=UTF-8

The application should also ensure that dynamically generated HTML content is safely encoded and rendered.

WEB-06 — Third-Party Resources Without Subresource Integrity

#

Severity: Low Status: Confirmed

The application loaded resources from third-party providers without observed Subresource Integrity attributes.

Recommendation

#

Where appropriate:

• Implement SRI for externally hosted resources.
• Use crossorigin where required.
• Alternatively, self-host third-party resources.
• Maintain a controlled dependency update process.

WEB-07 — Public Attachment Files and Paths

#

Severity: Informational Status: Confirmed

The assessment identified publicly accessible attachment paths associated with website functionality.

Public attachment exposure is not inherently a vulnerability when the files are intended to be public. However, public directories should be reviewed to ensure that internal, draft, backup, or sensitive files are not accidentally exposed.

Recommendation

#

• Review publicly accessible attachment directories.
• Remove internal, backup, draft, or outdated documents.
• Disable directory listing where appropriate.
• Avoid storing private documents under the web root.
• Apply suitable access controls where required.

WEB-08 — Development Comments in Production Resources

#

Severity: Informational Status: Confirmed

Production HTML contained commented-out menu structures and development-style comments.

Although the observed comments were not directly exploitable, development artifacts may disclose implementation details or information useful during reconnaissance.

Recommendation

#

Remove unnecessary development comments and unused code from production resources.

WEB-09 — Client-Side Dependency Review

#

Severity: Informational Status: Observed

Passive testing identified multiple JavaScript and frontend resources within the public client-side attack surface.

A complete dependency inventory and version assessment was not available within the provided evidence. Therefore, this item was recorded as a dependency review recommendation rather than a confirmed vulnerable dependency finding.

Recommendation

#

• Identify exact versions of JavaScript and CSS libraries.
• Upgrade unsupported or vulnerable dependencies.
• Remove unused libraries.
• Review custom JavaScript for unsafe DOM manipulation.
• Avoid rendering unsanitized HTML returned from AJAX responses.

Security Observations

#

The assessment also identified several positive security observations.

HTTPS Enforcement

#

HTTP traffic was observed redirecting to HTTPS.

Existing Browser Security Headers

#

Sampled responses included:

• X-Frame-Options: SAMEORIGIN
• X-Content-Type-Options: nosniff

Limited Public Application Functionality

#

No public authentication, payment, shopping cart, or user dashboard functionality was identified within the reviewed scope.

Defensive Request Filtering

#

Anti-automation or WAF-like request filtering was observed during testing.

Testing Limitations

#

The assessment was intentionally performed using a controlled and non-destructive methodology.

Automated active scanning was not used as the primary validation method because abnormal request patterns appeared capable of triggering defensive blocking.

The following activities were not performed:

• Denial-of-Service testing
• High-volume brute forcing
• Credential stuffing
• Phishing or social engineering
• Destructive exploitation
• Database dumping or extraction
• Unauthorized backend access
• Aggressive automated scanning
• Testing of unrelated third-party infrastructure

After confirming the SQL Injection behavior, no database extraction was performed.

These limitations mean that the assessment results represent the reviewed public scope and observed testing conditions, rather than proof that the application is completely free of vulnerabilities.

Remediation Priority

#

The primary remediation priority is WEB-01 — Error-Based SQL Injection.

Skills Demonstrated

#

This assessment allowed me to practice and demonstrate the following security skills:

• Black-box web application penetration testing
• Web reconnaissance
• Attack surface mapping
• HTTP request/response analysis
• SQL Injection validation
• Security-header assessment
• Client-side security review
• AJAX endpoint analysis
• Information disclosure analysis
• Vulnerability severity assessment
• Evidence collection
• Remediation planning
• Retest planning
• Professional security reporting

Evidence

#

Selected evidence from the assessment included:

• Burp Suite application sitemap
• OWASP ZAP sitemap
• Baseline HTTP request/response
• SQL Injection validation response
• HTTP security-header analysis
• AJAX endpoint response analysis
• Client-side resource inspection

Screenshots shown on this portfolio have been sanitized to remove target-identifying and sensitive information.

Full Assessment Report

#

The complete sanitized assessment report contains the detailed methodology, findings, evidence register, technical observations, remediation plan, retest guidance, and supporting evidence.

Download Full Pentest Report →

Conclusion

#

The assessment identified one High-severity confirmed vulnerability together with several lower-severity configuration and client-side security weaknesses.

The most significant issue was the confirmed error-based SQL Injection affecting a public application parameter. The vulnerability allowed controlled input to trigger database errors and disclose backend database information.

The remaining findings primarily relate to browser security hardening, content-type handling, third-party resource integrity, public file exposure, production artifacts, and client-side dependency management.

The assessment demonstrates the importance of combining automated tooling with manual validation and contextual analysis, particularly when defensive controls limit aggressive automated scanning.