Web Application Penetration Testing

Case Study: Web Application Penetration Testing

Occasionally public web applications combine software functionality with customer identity, user-generated content and the trust attached to an organisation’s domain. A weakness in any one of those areas can be amplified by the others: an unsafe attachment can disclose personal information, browser-side injection can create a route towards session misuse, and weak session lifecycle controls can extend the opportunity for attack after the initial compromise.

This case study outlines an external ProCheckUp penetration test of a national bank’s community portal. The engagement assessed public and authenticated functionality, content and file handling, authentication, password recovery, session management, browser security, transport security and third-party dependencies within a live production environment.

Overview

A national bank commissioned ProCheckUp to assess a public online community where customers could ask questions, reply to discussions, search content, manage profiles and receive support from staff and other users.

Testing was performed from both an unauthenticated and an authenticated self-registered-user perspective. Employee, moderator and administrative privilege levels were not included in the agreed scope.

The engagement identified 21 findings: two High, nine Medium, nine Low and one Informational. The most significant issue was not a conventional server exploit: instead publicly available customer attachments were found to contain names, addresses, financial information and account numbers of customers. The assessment also identified legacy transport security and a connected set of browser, authentication and session weaknesses that increased the potential impact of a stolen credential or client-side compromise.

Engagement at a glance

• - External assessment of a public customer community portal
• - Unauthenticated and authenticated self-registered-user perspectives
• - Public posts, replies, profiles, search, registration, login and password recovery
• - Content, attachment and remote-file-fetch functionality
• - Authentication, access control and session lifecycle testing
• - Browser trust, CORS, Content Security Policy and third-party dependencies
• - Twenty-one findings across four severity levels
• - Live password-policy improvement observed during the engagement

Challenge

Testing a customer-facing banking community required the assessment to connect technical behaviour with the way real users share information, trust links and maintain authenticated sessions.

Public content carried financial-sector trust

The portal allowed members to publish posts and attachments under the customer’s trusted domain. Sensitive information uploaded by users could therefore remain publicly discoverable even though the underlying application had not itself extracted or generated that information.

Testing took place in a live production environment

Higher-risk content testing had to remain non-disruptive. A non-public beta area was used for controlled post and payload testing, but it still formed part of the live service. The web application firewall initially blocked several test techniques, so agreed bypass rules and direct hosting information were used to distinguish application behaviour from perimeter filtering.

Moderate weaknesses could combine

A long idle timeout, concurrent sessions, incomplete logout invalidation, reflected JavaScript execution and permissive cross-origin behaviour were individually rated below High. Together, however, they increased the time and flexibility available to an attacker after credential theft or browser compromise.

Assessment Scope

The public case study generalises the original functions and routes. Testing concentrated on the following trust boundaries:

• - Public and anonymous surface: browsing, search, registration, public posts, attachments, redirects, external links and error handling
• - Authenticated user context: login, profile management, replies, account state and user-specific functionality available to a self-registered member
• - Content and file handling: user-generated text, images, documents, remote URL retrieval, attachment access and public-content moderation
• - Authentication and recovery: password policy, account enumeration, password-reset flow, credential delivery and multi-factor authentication
• - Session and access control: session creation, idle expiry, logout, token reuse, concurrent access and cookie protections
• - Browser and platform trust: input encoding, cross-site scripting, CORS, Content Security Policy, third-party scripts, transport security and client-side libraries

Solution

ProCheckUp combined the OWASP Top 10 framework with manual attack-path testing and application-specific research. The objective was not merely to list headers or dependency versions, but to determine how the application behaved when customer-controlled data moved through public pages, authenticated workflows, browser rendering and server-side services.

The assessment followed six stages:

• 1. Reconnaissance: confirm the authorised target, discover public information and establish the external application boundary.
• 2. Discovery: map visible, hidden and default content; identify technologies, functions, data-entry points and error behaviour.
• 3. Enumeration: examine information disclosure, input validation, authorisation, authentication, session management, file handling and application logic.
• 4. Research: correlate observed components and behaviours with public vulnerability information and known attack techniques.
• 5. Controlled exploitation: demonstrate material impact where safe, without modifying or deleting production data or disrupting genuine users.
• 6. Evidence-led final steps: document validated findings, communicate significant issues and translate the results into prioritised remediation.

Manual validation remained decisive. Confirmed browser-side execution was separated from potential account takeover; version-associated component exposure was separated from demonstrated exploitation; and external service interaction was not overstated as successful server-side request forgery.

Findings Overview

The twenty-one findings formed four related groups.

High severity — two findings

• - Public exposure of personally identifiable and financial information through customer attachments
• - Legacy TLS versions and weaker cryptographic configuration

Medium severity — nine findings

• - Excessive idle-session lifetime
• - Reflected cross-site scripting and HTML injection
• - Server-side session not invalidated after logout
• - External service interaction through remote file retrieval
• - Verbose errors disclosing technical detail
• - Cross-origin policy trusting arbitrary origins
• - Password-reset weaknesses
• - Outdated client-side JavaScript library
• - Concurrent logins permitted

Low severity — nine findings

• - Username enumeration, source-code disclosure and cross-domain script trust
• - Missing external-link warnings and support for macro-capable document formats
• - Lack of multi-factor authentication and autocomplete on sensitive forms
• - Incomplete Content Security Policy and residual password-policy weaknesses

Informational — one finding

• - Public diagnostic or support artefacts and minor application anomalies requiring ownership review

High-Severity Findings

Public exposure of personal information — High, CVSS 7.5

Publicly accessible attachments contained combinations of full names, addresses, financial information and account numbers. This created a direct confidentiality risk and could support targeted social engineering, identity fraud or criminal resale.

The assessment could not exhaustively review every historical attachment within the available test window. The confirmed examples therefore indicated both an immediate exposure and a wider moderation problem requiring a complete customer-led content review.

Recommendation: remove confirmed sensitive content, review historical uploads, add mandatory warnings with clear examples of prohibited information, introduce moderator review or automated alerting and define a rapid takedown process for personal data.

Legacy transport security — High, CVSS 7.5

The service accepted deprecated TLS versions and weaker cryptographic options associated with known attacks. Successful exploitation would require an appropriately positioned and capable attacker, but retaining obsolete protocol support unnecessarily weakened the confidentiality of customer sessions and credentials.

Recommendation: disable TLS 1.0 and TLS 1.1, remove weak cipher suites, retain modern protocol versions only and regularly validate the public edge after platform or delivery-network changes.

Session Integrity and Browser-Side Attack Paths

Idle session remained valid after 24 hours — Medium, CVSS 6.3

An authenticated session remained usable after at least 24 hours of inactivity. This extended the window in which a stolen or abandoned session could be replayed.

Recommendation: introduce a risk-appropriate idle timeout and an absolute session lifetime, with reauthentication for sensitive account changes.

Reflected cross-site scripting and HTML injection — Medium, CVSS 6.1

Untrusted URL and referrer-derived data was inserted into browser-side page state without adequate encoding across multiple application routes. Controlled testing confirmed arbitrary JavaScript execution in the test browser.

Recommendation: contextually encode every value before rendering, validate input using allow-lists where practical, remove unsafe DOM construction patterns and enforce a comprehensive Content Security Policy as defence in depth.

Logout did not invalidate the server-side session — Medium, CVSS 5.5

After the test user logged out, the previously issued authenticated session could still be reused. A person who obtained that session before logout could therefore retain access until it expired.

Recommendation: invalidate the server-side session at logout, rotate session identifiers after authentication or privilege changes and provide users with a way to revoke other active sessions.

Arbitrary cross-origin access policy — Medium, CVSS 5.0

The application returned a permissive cross-origin policy rather than restricting access to explicitly approved origins. In combination with browser-side injection or another trusted-domain compromise, this could increase the ability of hostile content to interact with authenticated application data.

Recommendation: use a narrow allow-list of required origins, methods and headers; avoid reflecting arbitrary origins; and validate credentialed cross-origin behaviour separately.

Concurrent logins remained active — Medium, CVSS 4.3

Multiple independent sessions could remain active for the same user, and logging out from one session did not terminate the others. This reduced visibility of unauthorised access and could prolong account misuse after credentials were stolen.

Recommendation: enforce single-session behaviour where appropriate or notify users of new logins, expose an active-session view and support immediate revocation of individual or all sessions.

Additional Medium-Severity Findings

External service interaction through remote file retrieval — Medium, CVSS 5.4

The application could be induced to retrieve a file from an attacker-controlled external service. The request revealed the application server’s public source address and could allow the service to be used as an outward-facing request proxy.

Important evidence boundary: direct server-side request forgery into internal or loopback services was not achieved during testing.

Recommendation: disable remote retrieval if it is not required, or restrict schemes, destinations and file types through an explicit allow-list; deny access to internal, metadata and loopback ranges and mediate outbound traffic through controlled egress.

Verbose errors disclosed valuable information — Medium, CVSS 5.3

Selected error conditions exposed SQL detail and stack-trace information. These responses could help an attacker understand the application architecture and refine follow-on requests.

Recommendation: return generic client-safe messages, preserve detailed diagnostics only in protected server logs and alert on repeated malformed requests or error-triggering probes.

Password-reset weaknesses — Medium, CVSS 4.7

The reset process issued a new password by email, the temporary value did not consistently follow the normal password policy and the user was not required to change it at first use. Compromise of the mailbox or persistent access to the email could therefore expose a reusable credential.

Recommendation: use a single-use, expiring reset link; never email a reusable password; apply rate limiting and consistent responses; and invalidate existing reset tokens after successful use.

Outdated JavaScript component — Medium, CVSS 4.3

A legacy client-side library version was associated with publicly disclosed cross-site-scripting weaknesses. The finding was based on retrieved version information; the associated vulnerabilities were not directly exploited during the assessment.

Recommendation: remove unused legacy libraries, migrate required functionality to a maintained release and use dependency inventory and software-composition analysis to prevent recurrence.

Low-Severity and Informational Findings

The remaining findings did not create the primary compromise path on their own, but they reduced defence in depth or increased the trust placed in users, browsers and external content.

• - Username enumeration: password-recovery responses differed for valid and invalid accounts, although CAPTCHA reduced automated exploitation.
• - Public source artefacts: obsolete or backup source material was accessible and increased reconnaissance value.
• - Cross-domain script inclusion: browser execution trusted third-party sources outside the direct application boundary.
• - External-link warnings: user-posted off-site links were not clearly distinguished from destinations under the customer’s control.
• - Macro-capable documents: legacy office formats containing an anti-malware test signature could be uploaded and downloaded; no end-user macro execution was performed.
• - No multi-factor authentication: account protection relied on passwords and the existing recovery flow.
• - Autocomplete on sensitive forms: browser storage could retain credential-related values on shared or compromised devices.
• - Incomplete Content Security Policy: the policy principally addressed framing and did not define a restrictive baseline for scripts, styles and other resources.
• - Password complexity: the customer introduced minimum length and complexity during testing, but usernames and excessive repeated characters could still be accepted.
• - Informational observations: a publicly accessible internal-looking page, a timestamp anomaly and other minor artefacts required ownership review; the robots file did not disclose sensitive directories.

Authorised Risk Models

Path A: public customer information

• 1. User upload — observed: a customer attaches a document or screenshot to a public post.
• 2. Sensitive content — confirmed: the attachment contains personal and financial information.
• 3. Public retrieval — confirmed: an unauthenticated visitor can access the content.
• 4. Collection and correlation — potential: an attacker harvests multiple attachments and combines them with other public information.
• 5. Fraud, social engineering or regulatory harm — potential: the exposed information is used against customers or the organisation.

Path B: browser and session state

• 1. Crafted input — confirmed: attacker-controlled URL or referrer data reaches a vulnerable page.
• 2. JavaScript execution — confirmed: the payload executes in the authorised test browser.
• 3. Credential phishing or session access — potential: hostile browser content targets credentials, page data or a usable session.
• 4. Extended access window — confirmed control weakness: idle sessions last at least 24 hours, logout does not revoke the token and concurrent sessions remain active.
• 5. Account impersonation — potential: a stolen credential or session is used to act as a customer or staff member.

These are authorised risk models, not evidence of a completed real-world compromise. The assessment confirmed the public information exposure, JavaScript execution and session-lifecycle weaknesses. It did not compromise a genuine customer account or demonstrate production data theft.

Control Effectiveness and Assessment Boundaries

Positive controls observed

• - The web application firewall initially blocked several testing techniques
• - A non-public beta area reduced exposure during higher-risk content testing
• - HttpOnly on session cookies reduced trivial script-based cookie theft
• - CAPTCHA reduced automated username-enumeration risk
• - Direct server-side request forgery into internal services was not achieved
• - Direct server-side attack and executable-file paths showed useful resilience
• - Password length and complexity were strengthened during the test window

Limitations requiring follow-up

• - The assessment took place against a live service and avoided disruptive activity
• - Staff, moderator and administrator privilege levels were outside scope
• - Every historical attachment could not be exhaustively reviewed within the test window
• - Version-associated library vulnerabilities were not individually exploited
• - Macro execution on an end-user device was not performed
• - The source material does not confirm that the complete remediation programme was later implemented or independently retested

The assessment therefore provides an evidence-led view of the tested customer journey, not a guarantee that every application role, historical item or future deployment is secure.

Outcome

The engagement converted a broad public-portal risk into a sequenced programme that could be owned across application engineering, security operations, content moderation, customer communications and identity governance.

The national bank received direct evidence that customer-uploaded information, session lifecycle and browser trust were part of the application boundary. This allowed immediate data-removal and transport-security actions to be prioritised ahead of deeper session, authentication and dependency improvements.

The assessment also recorded positive behaviour: the perimeter control impeded testing, direct SSRF was not achieved, cookies carried a useful browser-side protection and the customer improved its password policy during the engagement. These controls were recognised without allowing them to obscure the confirmed weaknesses.

Publication boundary: this case study does not state that the complete remediation programme was subsequently implemented or independently retested.

Remediation Priorities

Immediate containment

• - Remove confirmed personal and financial information from public posts and attachments
• - Conduct a moderator-led review of historical public content
• - Add mandatory upload warnings and a rapid sensitive-content takedown process
• - Disable TLS 1.0, TLS 1.1 and weak cipher suites

Application and session hardening

• - Replace emailed passwords with single-use, expiring reset links
• - Restrict CORS to approved origins and required methods
• - Invalidate sessions server-side at logout and shorten idle lifetime
• - Notify users of new sessions and support revocation of active sessions
• - Encode and validate all user-controlled data before browser rendering
• - Restrict remote-file retrieval and controlled outbound access
• - Update or remove obsolete JavaScript libraries
• - Replace verbose client errors with generic responses and protected server logging

Sustained content and identity governance

• - Block or safely handle macro-capable legacy document formats
• - Warn users before they follow external links and scan posted destinations where appropriate
• - Remove obsolete source artefacts and unowned diagnostic pages
• - Introduce multi-factor authentication and strengthen password-deny rules
• - Disable autocomplete on sensitive recovery forms where appropriate
• - Trust scripts only from controlled sources and enforce a comprehensive Content Security Policy
• - Repeat independent testing after major platform, authentication or content-handling changes

The Core Security Lesson

The application boundary includes the content customers upload, the session the browser carries and every external source the page trusts.

Server endpoints can resist common injection attacks while customers remain exposed through public attachments, browser rendering, password recovery or incomplete session revocation. Strong assurance follows the complete customer journey from anonymous content discovery through authentication, active use, logout and long-term content retention.

The correct question is not simply:

“Did the server reject common attack payloads?”

It is:

“Can public content, browser trust or session state still be used to expose or impersonate a customer?”

How ProCheckUp Helps

ProCheckUp’s Web Application Penetration Testing service assesses the complete relationship between public functionality, user input, browser behaviour, authentication, sessions and supporting infrastructure. Support can include:

• - Authenticated and unauthenticated application testing
• - OWASP Top 10 and business-logic assessment
• - Registration, login, password-recovery and MFA testing
• - Session creation, timeout, logout, rotation and concurrent-access review
• - Cross-site scripting, injection and DOM-based testing
• - Access control, forced browsing and parameter-tampering assessment
• - File upload, remote retrieval and user-generated-content testing
• - CORS, Content Security Policy and third-party dependency review
• - TLS, cookie, caching and response-header assessment
• - Prioritised remediation guidance and verification testing

Related services include Application PenTesting and Penetration Testing.

Conclusion

This engagement demonstrated why a public community application must be tested as a connected content, identity and session system. The most consequential exposure came from information customers had uploaded themselves, while browser-side injection and session-lifecycle weaknesses created a credible route towards account misuse if another attacker precondition were met.

By removing sensitive content, modernising transport security, closing browser-side injection, enforcing server-side session revocation and governing every trusted script, link and upload path, organisations can materially reduce both direct technical risk and the broader fraud, privacy and reputational consequences of a public portal compromise.

To discuss a web application penetration test, customer-journey security assessment or targeted remediation-verification exercise, contact ProCheckUp.