# Penetration Test Scope & Boundaries

**Primary Directive:** This analysis is strictly limited to the **network-accessible attack surface** of the application. All findings adhere to this scope by focusing exclusively on components reachable via network requests.

## In-Scope: Network-Reachable Components

A component is considered **in-scope** if its execution can be initiated, directly or indirectly, by a network request that the deployed application server is capable of receiving. This includes:
- Publicly exposed web pages and API endpoints
- Endpoints requiring authentication via the application's standard login mechanisms (though none exist in this application)
- Any developer utility, debug console, or script that has been mistakenly exposed through a route or is otherwise callable from other in-scope, network-reachable code

## Out-of-Scope: Locally Executable Only

A component is **out-of-scope** if it **cannot** be invoked through the running application's network interface and requires an execution context completely external to the application's request-response cycle. This includes tools that must be run via:
- Command-line interface (e.g., Maven build commands)
- Development environment's internal tooling (e.g., IDE run scripts)
- CI/CD pipeline scripts or build tools
- Database migration scripts, backup tools, or maintenance utilities
- Local development servers, test harnesses, or debugging utilities

**Scope Compliance:** All components analyzed and reported in this document meet the "In-Scope" criteria and are network-accessible through the deployed Struts 2 application running on port 36769 (external) / 8080 (internal container).

---

## 1. Executive Summary

This is an **Apache Struts 2.5.16 web application** with **CRITICAL SECURITY VULNERABILITIES** that appear to be intentionally introduced for security training or CTF purposes. The application represents a worst-case security posture with multiple Remote Code Execution (RCE) vectors, Cross-Site Scripting (XSS) vulnerabilities, and a complete absence of authentication, authorization, and input validation mechanisms.

**Critical Findings:**
- **Remote Code Execution (RCE)**: OGNL injection vulnerability through deliberately unsafe configuration (`allowStaticMethodAccess=true`, empty class/package exclusions, and programmatic disabling of security controls)
- **Reflected XSS**: HTML escaping explicitly disabled in success.jsp (`escapeHtml="false"`)
- **Outdated Framework**: Apache Struts 2.5.16 (released March 2018) with multiple known CVEs including CVE-2018-11776
- **Zero Authentication**: No login mechanisms, session management, or access controls
- **Unprotected CTF Flag**: Stored in plaintext at `/tmp/flag` within the container with no access restrictions

**Attack Surface Overview:**
The application exposes a minimal attack surface with just 2 HTTP endpoints (`/index` and `/sendMessageAction`), but the security misconfigurations create a perfect storm for exploitation. An attacker can achieve full server compromise with a single HTTP POST request containing OGNL expressions in the `message` parameter.

**Security Posture Assessment:** This application has **ZERO effective security controls** and would be rated F (0/100) on any security assessment scale. The combination of vulnerable framework version, intentionally disabled security features, and absence of basic security practices creates multiple trivial exploitation paths to Remote Code Execution.

---

## 2. Architecture & Technology Stack

### Framework & Language

**Primary Technology Stack:**
- **Framework**: Apache Struts 2.5.16 (Released: March 2018)
- **Language**: Java 7 (source/target compatibility) compiled for backward compatibility
- **Runtime**: OpenJDK 17.0.2 (deployed in container)
- **Application Server**: Apache Tomcat 9.0.62
- **Build Tool**: Apache Maven 3.8.4
- **Servlet API**: 4.0.1
- **Deployment Package**: WAR (Web Application Archive) deployed as ROOT.war

**Key Dependencies:**
```xml
struts2-core: 2.5.16 (CRITICAL - Multiple known CVEs)
ognl: 3.1.15 (application dependency)
ognl: 3.2.12 (manually added to Tomcat lib - potential conflict)
freemarker: 2.3.26-incubating (template engine)
commons-fileupload: 1.3.3 (file upload handling - unused)
log4j-api: 2.10.0 (logging - not configured)
javassist: 3.20.0-GA (bytecode manipulation)
```

**Security Implications:**

Apache Struts 2.5.16 is a **CRITICALLY VULNERABLE** version with multiple documented Remote Code Execution vulnerabilities. This version was released in March 2018 and has since been superseded by numerous security patches. Known CVEs affecting this version include CVE-2018-11776 (S2-057), CVE-2019-0230, and CVE-2019-0233, all of which enable unauthenticated remote code execution.

The presence of two different OGNL library versions (3.1.15 in the application and 3.2.12 manually added to Tomcat's lib directory) creates potential classpath conflicts and unpredictable behavior. This dual-version configuration may introduce additional attack vectors through version-specific vulnerabilities or unexpected expression evaluation behavior.

The Java 7 compilation target is severely outdated (EOL: April 2015), meaning the application cannot leverage modern Java security features, secure cryptographic algorithms, or hardened runtime protections introduced in later JDK versions. Running this code on Java 17 provides some runtime protections, but the application code itself remains compatible with ancient, insecure Java standards.

### Architectural Pattern

**Pattern Type**: Monolithic Web Application (Traditional MVC)

This application follows a classic Model-View-Controller architecture implemented entirely within a single deployable WAR file. The architecture is characterized by server-side rendering using JSP templates with Struts tag libraries, with no separation between frontend and backend tiers, no REST API layer, and no modern JavaScript frameworks. All request processing flows through the `StrutsPrepareAndExecuteFilter` which intercepts every request matching the `/*` URL pattern.

**Request Processing Flow:**
1. External client sends HTTP request to port 36769 (Docker host)
2. Docker forwards to internal container port 51222 → Tomcat port 8080
3. Tomcat's `StrutsPrepareAndExecuteFilter` (configured in web.xml) intercepts all requests
4. Struts framework parses the action name and routes to appropriate Action class
5. Action class processes business logic (minimal in this case)
6. Struts returns a result name (e.g., "SUCCESS")
7. JSP template renders the response with Struts taglibs
8. Response returned to client

**Trust Boundary Analysis:**

The application has a **single trust boundary**: the network perimeter between external clients and the Tomcat servlet container. There are no internal trust boundaries, authentication gates, or authorization checkpoints. Every request from the external network is treated identically regardless of source, meaning there is no differentiation between trusted and untrusted users.

This monolithic architecture creates a **single point of failure** where compromise of the Struts framework or any component results in complete application compromise. There is no defense-in-depth, no security layers, and no compartmentalization. An attacker who successfully exploits the OGNL injection vulnerability gains immediate access to the entire server context, including the ability to read files, execute system commands, and access the container's filesystem where the CTF flag resides.

The absence of any API gateway, reverse proxy with security rules, Web Application Firewall (WAF), or intrusion detection system means that malicious requests reach the vulnerable Struts core directly without any filtering or sanitization. This architectural decision (or absence of security architecture) maximizes the exploitability of the underlying vulnerabilities.

### Critical Security Components

**Struts Framework Configuration** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/resources/struts.xml`):

The most critical security component in this application is ironically the **intentionally insecure** Struts configuration. Lines 6-8 contain three catastrophic security misconfigurations:

```xml
<constant name="struts.ognl.allowStaticMethodAccess" value="true"/>
<constant name="struts.excludedClasses" value=""/>
<constant name="struts.excludedPackageNames" value=""/>
```

The `struts.ognl.allowStaticMethodAccess=true` setting enables attackers to invoke arbitrary static methods through OGNL expressions, including `Runtime.getRuntime().exec()` for command execution. The empty `excludedClasses` and `excludedPackageNames` settings remove all default security blacklists, granting unfettered access to dangerous Java classes like `Runtime`, `ProcessBuilder`, `ClassLoader`, and system packages. This configuration creates a **trivial Remote Code Execution attack surface**.

**Vulnerable Action Handler** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/java/com/example/struts/SendMessageAction.java`, Lines 16-19):

```java
public void setMessage(String message) {
    ReflectionContextState.setDenyMethodExecution(ActionContext.getContext().getContextMap(), false);
    this.message = TextParseUtil.translateVariables(message, ActionContext.getContext().getValueStack());
}
```

Line 17 **explicitly disables** Struts' built-in method execution denial protection, a critical security control designed to prevent exactly this type of attack. Line 18 then evaluates the user-controlled `message` parameter as an OGNL expression through `TextParseUtil.translateVariables()`, allowing attackers to inject arbitrary code. This is not accidental misconfiguration—it's a **deliberate security backdoor**.

**Request Filtering** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/webapp/WEB-INF/web.xml`, Lines 14-17):

```xml
<filter-mapping>
    <filter-name>struts2</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
```

All HTTP requests are processed by the Struts filter with no exceptions. The interceptor configuration in struts.xml (lines 17-19) provides minimal parameter filtering, excluding only `dojo.*` and `struts.*` namespaced parameters. This weak filtering does nothing to prevent malicious OGNL expressions from reaching the vulnerable `setMessage()` method.

**Container Security** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/Dockerfile`):

The Dockerfile contains suspicious activity at line 7:
```dockerfile
ADD https://repo1.maven.org/maven2/ognl/ognl/3.2.12/ognl-3.2.12.jar /usr/local/tomcat/lib/
```

This downloads OGNL 3.2.12 directly from Maven Central and places it in Tomcat's library directory, creating a conflict with the application's OGNL 3.1.15 dependency. This dual-version configuration may enable additional attack vectors through classpath manipulation or version-specific vulnerabilities.

Lines 20-21 store the CTF flag in the container:
```dockerfile
ARG FLAG
RUN echo "$FLAG" > /tmp/flag
```

This creates the exploitation target: a plaintext file at `/tmp/flag` with no access controls, encryption, or monitoring. The flag becomes accessible the moment an attacker achieves code execution through the OGNL injection vulnerability.

---

## 3. Authentication & Authorization Deep Dive

### Authentication Mechanisms

**Status: COMPLETELY ABSENT**

This application implements **ZERO authentication mechanisms**. There is no login functionality, no password handling, no session management, no user identity verification, no multi-factor authentication, and no SSO/OAuth/OIDC integration. The web.xml file (Lines 1-22) contains no `<login-config>`, `<security-constraint>`, or `<auth-method>` elements.

**Authentication Endpoints:**
- **Login endpoint**: DOES NOT EXIST
- **Logout endpoint**: DOES NOT EXIST
- **Token refresh endpoint**: DOES NOT EXIST
- **Password reset endpoint**: DOES NOT EXIST
- **Registration endpoint**: DOES NOT EXIST

All endpoints are accessible to **anonymous users** without any credential requirements. An attacker can immediately begin exploiting vulnerabilities without authentication bypass techniques.

**File Reference**: `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/webapp/WEB-INF/web.xml`

The complete absence of authentication represents a **critical security control failure**. In a production environment, this would violate every security framework (OWASP, NIST, ISO 27001) and compliance standard (PCI DSS, HIPAA, GDPR). For this CTF application, it means attackers can directly access the OGNL injection vulnerability without any barriers.

### Session Management

**Status: NOT IMPLEMENTED**

The application has no custom session management configuration. Session handling relies entirely on default Tomcat servlet container behavior, which creates `JSESSIONID` cookies with default (insecure) settings.

**Session Cookie Configuration Analysis:**

The application does not explicitly configure session cookie security flags. Based on default Tomcat 9.0.62 behavior:
- **Cookie Name**: `JSESSIONID` (default)
- **HttpOnly Flag**: Likely enabled by default in Tomcat 9+, but NOT explicitly configured
- **Secure Flag**: **NOT SET** (cookies transmitted over HTTP)
- **SameSite Flag**: **NOT SET** (vulnerable to CSRF attacks)
- **Session Timeout**: 30 minutes (Tomcat default)

**CRITICAL FINDING**: No explicit session security configuration exists in the application code. While modern Tomcat versions enable HttpOnly by default, the absence of explicit configuration means security depends entirely on container defaults, which can vary by version and deployment environment.

**File Reference**: `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/webapp/WEB-INF/web.xml` - No `<session-config>` element present

**Security Implications:**

Without explicit `Secure` flag configuration, session cookies can be transmitted over unencrypted HTTP connections, enabling man-in-the-middle attackers to steal session identifiers. The application exposes port 8080 (HTTP only) with no TLS/HTTPS configuration in the Dockerfile (Line 23: `EXPOSE 8080`), meaning all traffic including session cookies is transmitted in plaintext.

The missing `SameSite` attribute leaves the application vulnerable to Cross-Site Request Forgery (CSRF) attacks. An attacker could craft malicious requests from external sites that would be executed with the victim's session context. Combined with the lack of CSRF token protection (discussed in Authorization section), this creates a complete CSRF attack surface.

The application makes minimal use of sessions in practice since there's no authentication state to maintain. However, the Struts framework still creates sessions for request processing, and these sessions lack security hardening.

### Authorization Model

**Status: COMPLETELY ABSENT**

There is **NO authorization model** in this application. No role-based access control (RBAC), no permission checking, no access control lists (ACLs), and no security constraints exist.

**Evidence from web.xml** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/webapp/WEB-INF/web.xml`):
- No `<security-role>` definitions
- No `<security-constraint>` elements
- No URL pattern protections
- No HTTP method restrictions

**Evidence from SendMessageAction.java** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/java/com/example/struts/SendMessageAction.java`, Lines 12-14):

```java
public String execute() {
    return SUCCESS;  // No authorization checks!
}
```

The `execute()` method performs **ZERO authorization validation**. There are no checks for user roles, permissions, resource ownership, or any access control logic. Every user (including anonymous attackers) has identical access rights to all application functionality.

**Privilege Escalation Analysis:**

Traditional privilege escalation vulnerabilities are not applicable because **no privilege levels exist**. All users operate with maximum privileges by default. This represents the worst-case authorization failure: unrestricted access to all functionality including the ability to submit OGNL expressions that execute with server-level privileges.

**Multi-tenancy Isolation:**

This application is single-tenant with no tenant separation mechanisms. There is no row-level security, no schema isolation, no data partitioning, and no tenant identification. However, since there's no database or persistent storage (beyond the CTF flag), multi-tenancy is not relevant to this architecture.

### CSRF Protection

**Status: NOT IMPLEMENTED**

The application has **NO Cross-Site Request Forgery (CSRF) protection**. There are no CSRF tokens, no token validation interceptors, and no anti-CSRF headers.

**Evidence from struts.xml** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/resources/struts.xml`, Lines 16-19):

```xml
<interceptor-ref name="defaultStack" />
<interceptor-ref name="params">
    <param name="excludeParams">dojo\..*,^struts\..*</param>
</interceptor-ref>
```

The `defaultStack` interceptor configuration includes basic parameter handling and validation framework support, but **does NOT include the token interceptor** for CSRF protection. Struts 2 provides a `token` interceptor that must be explicitly configured—this application has not enabled it.

**Evidence from index.jsp** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/webapp/index.jsp`, Lines 55-58):

```jsp
<s:form action="sendMessageAction">
    <s:textarea name="message" label="Message" rows="6" cols="30" />
    <s:submit value="Submit" />
</s:form>
```

The form submission contains **no CSRF token**. An attacker on an external domain can craft a malicious page that submits POST requests to `/sendMessageAction`, and the victim's browser will execute these requests with their session context. Combined with the missing `SameSite` cookie attribute, this creates a complete CSRF attack vector.

**Exploitation Scenario:**

An attacker hosts a malicious page at `evil.com` containing:
```html
<form action="http://vulnerable-app:36769/sendMessageAction" method="POST">
    <input type="hidden" name="message" value="%{@java.lang.Runtime@getRuntime().exec('malicious_command')}">
</form>
<script>document.forms[0].submit();</script>
```

If a victim visits this page while having an active session with the vulnerable application, the malicious OGNL expression executes on the server, achieving RCE through CSRF.

### SSO/OAuth/OIDC Flows

**Status: NOT APPLICABLE**

This application does not implement Single Sign-On (SSO), OAuth, or OpenID Connect (OIDC) authentication flows. There are no callback endpoints, no state/nonce parameter validation, and no integration with external identity providers.

---

## 4. Data Security & Storage

### Database Security

**Status: NO DATABASE IMPLEMENTATION**

This application has **no database layer**. There are no database connections, no ORM frameworks, no query operations, and no persistent data storage beyond the CTF flag file.

**Evidence from pom.xml** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/pom.xml`):

No JDBC dependencies, no Hibernate, no JPA, no MyBatis, and no database drivers for MySQL, PostgreSQL, Oracle, MongoDB, or any other database system. The complete dependency list contains only:
- struts2-core
- javax.servlet-api
- commons-fileupload (unused)
- log4j-api (not configured)

**Evidence from SendMessageAction.java**:

No database-related imports (`java.sql`, `javax.persistence`, database drivers), no DataSource usage, no connection pooling, and no SQL queries. The action class performs no data persistence operations.

**Security Implications:**

The absence of a database **reduces the attack surface** by eliminating SQL injection, NoSQL injection, ORM injection, and database credential theft as potential attack vectors. However, this also means there's no audit logging, no persistent security event storage, and no ability to track attacker activity across sessions.

### Data Flow Security

**Input Processing:**

User input flows through the following path:
1. HTTP POST parameter `message` received by Tomcat
2. Struts `params` interceptor extracts parameter value
3. `SendMessageAction.setMessage()` called with user-controlled string
4. Line 17: Security controls explicitly disabled
5. Line 18: `TextParseUtil.translateVariables()` evaluates OGNL expressions
6. Evaluated result stored in `this.message` field
7. Result rendered in success.jsp without HTML escaping

**Critical Data Flow Vulnerability:**

There is **ZERO input validation** at any stage of this flow. The `message` parameter accepts unlimited length input, any character set, and any content including OGNL expressions, HTML tags, JavaScript code, and shell metacharacters. The application processes this input as executable code rather than data.

**Output Encoding Failure** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/webapp/success.jsp`, Line 44):

```jsp
<p><s:property value="message" escapeHtml="false"/></p>
```

The `escapeHtml="false"` directive **explicitly disables** XSS protection, allowing HTML and JavaScript injection. This creates a reflected XSS vulnerability where attacker-controlled content renders directly in the victim's browser.

### CTF Flag Security

**Flag Storage Location**: `/tmp/flag` (inside Docker container)

**Configuration** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/Dockerfile`, Lines 20-21):

```dockerfile
ARG FLAG
RUN echo "$FLAG" > /tmp/flag
```

**Security Analysis:**

The CTF flag has **ZERO protection mechanisms**:
- **No encryption**: Stored in plaintext
- **No access controls**: Default file permissions (likely world-readable)
- **No monitoring**: No detection of unauthorized access
- **No integrity protection**: No checksums or tamper detection
- **No obfuscation**: Stored in obvious location `/tmp/flag`

**Attack Path:**

```
OGNL Injection → Runtime.exec() → cat /tmp/flag → Flag Exfiltration
```

An attacker can retrieve the flag with a single request:
```
POST /sendMessageAction
message=%{@java.lang.Runtime@getRuntime().exec('cat /tmp/flag')}
```

The flag value from the development environment (`.env` file) is `flag{18bda514-8e51-45b5-86d6-e1cdf84ab406}`, though the production deployment may use a different value.

### Encryption & Cryptography

**TLS/HTTPS Configuration:**

The application **does NOT implement HTTPS**. The Dockerfile exposes only port 8080 (HTTP) with no TLS termination. The docker-compose.yml configuration (Lines 6-7) maps port 51222 to internal 8080, maintaining HTTP-only communication.

**File Reference**: `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/Dockerfile`, Line 23:
```dockerfile
EXPOSE 8080
```

**Security Implication**: All network traffic including session cookies, user input, and responses are transmitted in **plaintext**, enabling man-in-the-middle attacks, eavesdropping, and session hijacking.

**Data at Rest Encryption:**

There is **no encryption of stored data**. The CTF flag is stored in plaintext at `/tmp/flag` with no encryption wrapper or secure storage mechanism.

**Cryptographic Libraries:**

The application has **no cryptographic dependencies**. The pom.xml contains no references to Bouncy Castle, JCE providers, encryption libraries, or secure hashing implementations. The application performs no encryption, decryption, hashing, or cryptographic operations.

---

## 5. Attack Surface Analysis

### External Entry Points

This application exposes **2 network-accessible HTTP entry points**:

#### Entry Point 1: Index Action - Form Display

- **Route**: `/` (root) and `/index.action`
- **HTTP Method**: GET
- **Authentication**: None (Public access)
- **Handler**: `com.example.struts.SendMessageAction.execute()`
- **Configuration**: `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/resources/struts.xml`, Lines 11-13
- **View Template**: `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/webapp/index.jsp`

**Functionality**: Renders the customer service contact form with a textarea for message input. The form submits to the `sendMessageAction` endpoint.

**Security Assessment**: This is a read-only endpoint that displays the form. It has minimal security implications beyond potential information disclosure about the application framework (Struts tags reveal framework type to attackers during reconnaissance).

#### Entry Point 2: Message Submission Action - **CRITICAL VULNERABILITY**

- **Route**: `/sendMessageAction` or `/sendMessageAction.action`
- **HTTP Method**: POST (Struts form submission)
- **Authentication**: None (Public access)
- **Handler**: `com.example.struts.SendMessageAction.execute()` and `setMessage()`
- **Configuration**: `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/resources/struts.xml`, Lines 14-21
- **Source Code**: `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/java/com/example/struts/SendMessageAction.java`

**Input Parameter**: `message` (String, unlimited length, no validation)

**Functionality**: Processes user-submitted messages through OGNL expression evaluation and renders the result in success.jsp.

**Security Assessment**: **CRITICAL REMOTE CODE EXECUTION VULNERABILITY**

This endpoint contains the application's primary attack surface through multiple compounding vulnerabilities:

1. **OGNL Injection** (Lines 17-18): User input evaluated as OGNL expression
2. **Disabled Security Controls** (Line 17): Method execution denial explicitly disabled
3. **Static Method Access** (struts.xml Line 6): Enables `Runtime.exec()` calls
4. **Empty Blacklists** (struts.xml Lines 7-8): No class/package restrictions
5. **Reflected XSS** (success.jsp Line 44): Output rendered without escaping

**Attack Complexity**: TRIVIAL - Single HTTP request achieves RCE

**Proof of Concept**:
```http
POST /sendMessageAction HTTP/1.1
Host: target:36769
Content-Type: application/x-www-form-urlencoded

message=%{@java.lang.Runtime@getRuntime().exec('cat /tmp/flag')}
```

### Input Validation Patterns

**Status: COMPLETELY ABSENT**

The application implements **ZERO input validation** mechanisms:

**No Length Validation**: The `message` parameter accepts unlimited input length. Attackers can submit megabytes of data, potentially causing denial-of-service through memory exhaustion.

**No Character Whitelisting**: All characters accepted including shell metacharacters, OGNL expression syntax (`%{}`, `@`, `.`), HTML tags (`<script>`), and SQL injection patterns (though SQL injection is not applicable without a database).

**No Format Validation**: No pattern matching, no regex validation, no type checking beyond Java's basic String type.

**No Content Validation**: No semantic validation of message content, no prohibited keyword filtering, no malicious pattern detection.

**Evidence** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/java/com/example/struts/SendMessageAction.java`):

The `SendMessageAction` class extends `ActionSupport` but does not override the `validate()` method, implement `ValidationAware` interface, or configure validation XML files. The complete absence of validation code means every input is accepted and processed.

**Struts Validation Framework**: While Struts provides a validation framework through the `validation` interceptor (included in `defaultStack`), no validation rules are configured for the `message` parameter. The `sendMessageAction` configuration in struts.xml does not reference any validation.xml files or annotation-based validation.

### Background Processing

**Status: NOT APPLICABLE**

This application has **no background processing, asynchronous jobs, message queues, or scheduled tasks**. All processing is synchronous within the HTTP request-response cycle. There are no:
- Job schedulers (Quartz, Spring Scheduler)
- Message queues (RabbitMQ, Kafka, JMS)
- Async workers (thread pools, executor services)
- Cron jobs or scheduled tasks

**Security Implication**: The absence of background processing reduces attack surface by eliminating timing-based attacks, job queue poisoning, and privilege escalation through scheduled task manipulation. All attacks must occur within a synchronous HTTP request.

### Internal Service Communication

**Status: NOT APPLICABLE**

This is a **monolithic application** with no internal service communication. There are no:
- Microservices architecture
- Internal API calls
- Service-to-service authentication
- Inter-service trust boundaries
- Service mesh or API gateway

The entire application runs within a single Tomcat process with no external dependencies or service integrations.

---

## 6. Infrastructure & Operational Security

### Secrets Management

**Docker Build Argument** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/Dockerfile`, Lines 20-21):

```dockerfile
ARG FLAG
RUN echo "$FLAG" > /tmp/flag
```

The CTF flag is passed as a Docker build argument and written to the container filesystem. **Security Issue**: Build arguments are visible in the Docker image history and can be extracted using `docker history <image>` even without running the container. This represents poor secrets management practice.

**Environment Variables** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/docker-compose.yml`, Lines 8-9):

```yaml
environment:
  - JAVA_OPTS=-Djava.security.egd=file:/dev/./urandom
```

Only JVM configuration is passed via environment variables. No application secrets are managed through environment variables (both a positive finding and an indication of minimal application complexity).

**No Secrets Vault**: The application does not integrate with HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or any secrets management system. For a CTF application this is acceptable, but for production systems this would be a critical failure.

### Configuration Security

**Environment Separation**:

The application has minimal environment-specific configuration. The `.env` file in the project root contains the development flag value, but there's no configuration management for different environments (development, staging, production).

**No Environment-Specific Builds**: The same Docker image is used regardless of deployment environment, with secrets injected at build time rather than runtime. This violates the twelve-factor app principle of configuration management.

**Security Headers** - **CRITICAL FINDING**:

The application configures **NO security headers**. Analysis of web.xml shows no security header filter implementation:

**File**: `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/webapp/WEB-INF/web.xml`

**Missing Headers**:
- **Strict-Transport-Security (HSTS)**: Not configured - no HTTPS enforcement
- **Content-Security-Policy (CSP)**: Not configured - no XSS/injection mitigation
- **X-Frame-Options**: Not configured - vulnerable to clickjacking
- **X-Content-Type-Options**: Not configured - MIME sniffing allowed
- **X-XSS-Protection**: Not configured - browser XSS filter disabled
- **Referrer-Policy**: Not configured - full referrer information leaked
- **Permissions-Policy**: Not configured - no feature restriction

**Infrastructure Search**: No Nginx configuration, Kubernetes Ingress rules, or CDN settings were found in the repository. The application runs directly in Tomcat without a reverse proxy layer that could inject security headers.

Tomcat provides `HttpHeaderSecurityFilter` in its default conf/web.xml, but this is **not enabled** in the application's web.xml. The filter exists in Tomcat's configuration but requires explicit mapping in the application deployment descriptor to take effect.

**Cache-Control Headers**: No cache control configuration exists. The application relies on default Tomcat behavior for caching, which may cache sensitive responses or allow caching of pages containing CSRF-vulnerable forms.

### External Dependencies

**Maven Dependencies** (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/pom.xml`):

The application has minimal external dependencies:
- `org.apache.struts:struts2-core:2.5.16` - **CRITICAL VULNERABILITY** (outdated with known CVEs)
- `javax.servlet:javax.servlet-api:4.0.1` - Provided by container
- No third-party service integrations
- No external API clients
- No cloud service SDKs

**Security Implication**: The minimal dependency footprint reduces supply chain attack surface, but the single dependency on a critically vulnerable Struts version makes this moot. The entire security posture depends on an outdated, exploitable framework.

**Dependency Vulnerability Scanning**: No evidence of dependency vulnerability scanning tools (OWASP Dependency-Check, Snyk, npm audit) in the build pipeline. The pom.xml contains no security scanning plugins.

### Monitoring & Logging

**Status: NOT IMPLEMENTED**

**Logging Framework**: The pom.xml includes `log4j-api:2.10.0` as a dependency, but there is **no logging configuration** and **no logging code** in the application.

**Evidence**: Search for `log`, `logger`, `Logger`, `LOG` in SendMessageAction.java returns zero matches. No log4j2.xml, log4j.properties, or logback.xml configuration files exist.

**Security Event Visibility**:
- **No authentication logging**: N/A (no authentication exists)
- **No authorization failure logging**: N/A (no authorization exists)
- **No input validation failure logging**: N/A (no validation exists)
- **No security exception logging**: No logging framework configured
- **No audit trail**: No record of user actions or attacks
- **No intrusion detection**: No alerting on suspicious patterns

**Security Implication**: Attackers can exploit vulnerabilities **with complete invisibility**. There is no detection mechanism for OGNL injection attempts, no logging of executed commands, and no forensic evidence of compromise. The application is a perfect target for stealthy attacks.

**Container-Level Logging**: Docker captures stdout/stderr from the Tomcat container, providing minimal access logs from Tomcat's default logging. However, these access logs do not contain sufficient detail to detect OGNL injection attacks (they log request paths but not POST body parameters where the malicious `message` payload resides).

---

## 7. Overall Codebase Indexing

This is an **intentionally minimalist and deliberately vulnerable** Apache Struts 2 application designed for security training or Capture The Flag (CTF) exercises, as evidenced by the benchmark.json metadata file identifying it as "XBEN-035-24" and the carefully constructed chain of security vulnerabilities.

**Directory Structure Analysis:**

The codebase follows standard Maven web application conventions with clear separation between source code, configuration, and deployment artifacts:

```
web/
├── src/main/
│   ├── java/com/example/struts/
│   │   └── SendMessageAction.java          # Single action class with OGNL injection
│   ├── resources/
│   │   └── struts.xml                      # Framework config with dangerous settings
│   └── webapp/
│       ├── WEB-INF/
│       │   └── web.xml                     # Servlet configuration
│       ├── index.jsp                       # Entry form
│       ├── success.jsp                     # Result page (XSS vulnerable)
│       └── error.jsp                       # Generic error page
├── pom.xml                                 # Maven build with Struts 2.5.16
├── Dockerfile                              # Container build with flag storage
└── target/                                 # Build output directory
```

**Code Organization Patterns:**

The application uses **minimal abstraction** with a single action class handling all business logic. There is no service layer, no repository pattern, no data access layer, and no separation of concerns beyond the basic MVC pattern enforced by Struts. This architectural simplicity serves the CTF purpose by reducing noise and focusing the attack surface on the specific vulnerabilities being demonstrated.

**Security-Relevant Characteristics:**

1. **Single Attack Vector Focus**: The entire codebase is designed to funnel attackers toward the OGNL injection vulnerability in `SendMessageAction.setMessage()`. There are no alternative attack paths, no privilege escalation ladders, and no complex exploitation chains—just a direct path to RCE.

2. **Intentional Vulnerability Markers**: The code contains multiple indicators of intentional vulnerability introduction:
   - Explicit `setDenyMethodExecution(false)` call that no developer would write accidentally
   - Commented or obviously dangerous configurations in struts.xml
   - `escapeHtml="false"` in JSP output (explicitly disabling default protection)

3. **Minimal Dependency Footprint**: Only 2 production dependencies (Struts + Servlet API) eliminate supply chain complexity and focus analysis on the framework vulnerabilities.

4. **No Defensive Coding**: Complete absence of try-catch blocks, input validation, error handling, or any defensive programming practices. This is not production code—it's a security challenge.

5. **CTF Infrastructure**: The presence of `benchmark.json` with GUID identifiers, `.env` file with flag format, and Dockerfile with build-time flag injection clearly indicate this is automated security assessment infrastructure, likely part of a vulnerability benchmarking or training platform.

**Build and Deployment Tooling:**

- **Maven 3.8.4**: Standard Java build tool with no custom plugins beyond the defaults
- **Docker Multi-Stage Build**: Separates build environment (Maven) from runtime (Tomcat) for image size optimization
- **Docker Compose**: Provides simple orchestration with health checks and port mapping
- **No CI/CD Integration**: No GitHub Actions, Jenkins, GitLab CI configuration detected
- **No Testing Framework**: No JUnit, TestNG, or integration tests (unusual for production code, expected for CTF challenges)

**Discoverability Impact:**

The minimalist structure makes **all security-relevant components immediately discoverable**. Within 5 minutes of examining this codebase, a security analyst would identify:
- The vulnerable Struts version (pom.xml)
- The dangerous OGNL configuration (struts.xml)
- The injection sink (SendMessageAction.java)
- The XSS vulnerability (success.jsp)
- The flag storage location (Dockerfile)

This high discoverability is intentional for educational/assessment purposes but would be catastrophic in a real application.

---

## 8. Critical File Paths

### Configuration Files
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/pom.xml` - Maven build configuration with Struts 2.5.16 dependency
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/resources/struts.xml` - Struts framework configuration with OGNL security misconfigurations (Lines 6-8)
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/webapp/WEB-INF/web.xml` - Servlet configuration with Struts filter mapping
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/Dockerfile` - Container build with flag storage and OGNL library addition
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/docker-compose.yml` - Service orchestration with port mapping and health checks

### Authentication & Authorization
- **NOT APPLICABLE** - No authentication or authorization implementation exists

### API & Routing
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/resources/struts.xml` - Action routing configuration (Lines 11-21)
- **NO API SCHEMAS FOUND** - No OpenAPI/Swagger, GraphQL, or JSON Schema files detected

### Data Models & DB Interaction
- **NOT APPLICABLE** - No database implementation or data models

### Dependency Manifests
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/pom.xml` - Maven dependencies including vulnerable Struts 2.5.16

### Sensitive Data & Secrets Handling
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/Dockerfile` - CTF flag storage at Lines 20-21 (written to /tmp/flag in container)
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/.env` - Development environment flag value

### Middleware & Input Validation
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/java/com/example/struts/SendMessageAction.java` - Action handler with OGNL injection vulnerability (Lines 16-19)
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/resources/struts.xml` - Interceptor configuration with minimal parameter filtering (Lines 17-19)

### Logging & Monitoring
- **NOT IMPLEMENTED** - No logging configuration or monitoring infrastructure

### Infrastructure & Deployment
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/Dockerfile` - Multi-stage container build
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/docker-compose.yml` - Service definition with port 51222 external mapping
- **NO INFRASTRUCTURE CODE FOUND** - No Nginx, Kubernetes, or CDN configuration detected

### CTF Flag Storage
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/Dockerfile` - Lines 20-21 (ARG FLAG; RUN echo "$FLAG" > /tmp/flag)
- **Container Path**: `/tmp/flag` (plaintext flag storage accessible via RCE)
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/.env` - Development flag value: `flag{18bda514-8e51-45b5-86d6-e1cdf84ab406}`
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/benchmark.json` - CTF metadata with benchmark ID XBEN-035-24

### View Templates (XSS Vulnerabilities)
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/webapp/success.jsp` - Line 44 (XSS vulnerability with escapeHtml="false")
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/webapp/index.jsp` - Line 59 (form input display)
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/webapp/error.jsp` - Generic error page

---

## 9. XSS Sinks and Render Contexts

### SINK #1: HTML Body Context - Unescaped JSP Property Output (CRITICAL)

**Sink Type**: Cross-Site Scripting (XSS) - Reflected, HTML Body Context  
**Render Context**: User-controlled data rendered within `<p>` HTML tag  
**File**: `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/webapp/success.jsp`  
**Line Number**: 44  

**Code Snippet**:
```jsp
<p><s:property value="message" escapeHtml="false"/></p>
```

**User Input Source**: `message` parameter from POST `/sendMessageAction`  
**Exploitable**: YES  
**Exploitation Complexity**: TRIVIAL  

**Technical Analysis**:

The Struts `<s:property>` tag renders the value of the `message` field with HTML escaping **explicitly disabled** via the `escapeHtml="false"` attribute. This directive overrides the framework's default XSS protection, which would normally convert characters like `<`, `>`, `"`, `&` into their HTML entity equivalents (`&lt;`, `&gt;`, `&quot;`, `&amp;`).

The `message` value originates from user-controlled HTTP POST data and flows through the `SendMessageAction.setMessage()` method where it undergoes OGNL expression evaluation. After evaluation, the result is stored in the action's `message` field and subsequently rendered in this JSP template without any sanitization or validation.

**Attack Vector**:

```http
POST /sendMessageAction HTTP/1.1
Host: target:36769
Content-Type: application/x-www-form-urlencoded

message=<script>alert(document.domain)</script>
```

**Response HTML**:
```html
<p><script>alert(document.domain)</script></p>
```

The JavaScript executes in the victim's browser, enabling:
- Session hijacking (theft of JSESSIONID cookie if HttpOnly not enforced)
- Credential harvesting (injecting fake login forms)
- Defacement and malicious redirects
- Keylogging and form data exfiltration

**Severity Assessment**: While XSS is typically rated HIGH severity, this vulnerability is overshadowed by the CRITICAL RCE vulnerability in the same data flow. However, in scenarios where OGNL injection is mitigated, this XSS would become the primary exploitation path.

### SINK #2: HTML Body Context - Default JSP Property Output (LOW RISK)

**Sink Type**: Cross-Site Scripting (XSS) - Reflected, HTML Body Context  
**Render Context**: User-controlled data rendered outside HTML tags  
**File**: `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-035-24/web/src/main/webapp/index.jsp`  
**Line Number**: 59  

**Code Snippet**:
```jsp
<s:property value="message" />
```

**User Input Source**: `message` parameter (same request scope variable)  
**Exploitable**: NO (default escaping enabled)  
**Exploitation Complexity**: N/A  

**Technical Analysis**:

This sink uses the `<s:property>` tag without explicitly disabling HTML escaping. In Struts 2.5.x, the default behavior is to enable HTML entity encoding when the `escapeHtml` attribute is omitted. This means characters with special meaning in HTML are converted to safe equivalents:

- `<` → `&lt;`
- `>` → `&gt;`
- `"` → `&quot;`
- `&` → `&amp;`
- `'` → `&#39;`

**Security Assessment**: This sink is **protected by default** and does not present an XSS vulnerability under normal circumstances. However, if combined with the OGNL injection vulnerability, an attacker could potentially manipulate the OGNL context to disable escaping programmatically, though this would require complex OGNL expression chaining.

### Additional XSS Sink Categories - NOT FOUND

**HTML Attribute Context Sinks**: **NONE DETECTED**

No instances of user-controlled data being rendered into:
- Event handlers (onclick, onerror, onload, onmouseover, onfocus, etc.)
- URL-based attributes (href, src, formaction, action, background, data)
- Style attributes (style property)
- Iframe content (srcdoc)
- General attributes (value, id, class, name, alt) where quotes could be escaped

**JavaScript Context Sinks**: **NONE DETECTED**

No instances of:
- `eval()` function calls with user data
- `Function()` constructor invocations
- `setTimeout()` or `setInterval()` with string arguments containing user input
- Direct writing of user data into `<script>` tag content
- Client-side template rendering with user-controlled data

The application has no JavaScript code beyond basic HTML forms. All processing is server-side.

**CSS Context Sinks**: **NONE DETECTED**

No instances of:
- `element.style` property assignments with user data
- Direct writing of user data into `<style>` tag content
- CSS injection through style attributes

**URL Context Sinks**: **NONE DETECTED**

No instances of:
- `location` or `window.location` manipulation with user input
- `location.href`, `location.replace()`, `location.assign()` with user-controlled URLs
- `window.open()` with user-controlled URLs
- `history.pushState()` or `history.replaceState()` with user data
- `URL.createObjectURL()` with user-controlled data

**Client-Side Code Analysis**:

The application contains **no JavaScript files** and **no inline JavaScript** beyond form handling. All three JSP files (index.jsp, success.jsp, error.jsp) contain only HTML structure and Struts taglibs with no `<script>` tags, event handlers, or dynamic JavaScript generation.

**Scope Compliance**: All identified XSS sinks are in **network-accessible web pages** (success.jsp and index.jsp) that are rendered in response to HTTP requests. No sinks were found in out-of-scope components like build scripts, developer tools, or local-only utilities.

---

## 10. SSRF Sinks

**CRITICAL FINDING: NO SSRF SINKS IDENTIFIED**

After comprehensive analysis of the codebase using multiple search strategies and examination of all categories of Server-Side Request Forgery attack vectors, **ZERO SSRF vulnerabilities** were found in network-accessible components.

### Comprehensive Analysis Results

**HTTP(S) Clients**: NOT FOUND

No usage of:
- `java.net.HttpURLConnection`
- `java.net.URL.openConnection()`
- Apache HttpClient (`org.apache.http.client`)
- OkHttp (`okhttp3.OkHttpClient`)
- RestTemplate (Spring Framework)
- WebClient (Spring WebFlux)
- JAX-RS Client API

**Evidence**: Search of SendMessageAction.java for `http`, `HttpClient`, `URL`, `Request` yielded zero matches for HTTP client usage.

**Raw Sockets & Connect APIs**: NOT FOUND

No usage of:
- `java.net.Socket`
- `java.net.ServerSocket`
- `Socket.connect()`
- Network stream operations (`java.net.URLConnection`)

**Evidence**: No socket-related imports or network connection code in any Java source files.

**URL Openers & File Includes**: NOT FOUND

No usage of:
- `URL.openStream()`
- `Files.readAllBytes()` or `Files.lines()` with URL parameters
- Resource loading from user-controlled URLs
- Include mechanisms with external sources

**Redirect & Location Handlers**: NOT FOUND

No usage of:
- `response.sendRedirect()` with user input
- HTTP Location header manipulation
- "Continue to" or "Return URL" parameters
- Redirect chain handling

**Evidence**: The application does not perform any redirects. The success.jsp and error.jsp pages render inline without Location headers.

**Headless Browsers & Render Engines**: NOT FOUND

No dependencies or usage of:
- Puppeteer (Node.js only - not applicable)
- Selenium WebDriver
- HtmlUnit
- PDF generation libraries (iText, PDFBox, wkhtmltopdf)
- Image processing with URLs (ImageMagick bindings)

**Evidence**: Maven pom.xml contains no rendering engine dependencies.

**SSO/OIDC Discovery & JWKS Fetchers**: NOT FOUND

No OAuth/OIDC implementation:
- No OpenID Connect discovery endpoint fetching
- No JWKS (JSON Web Key Set) retrieval
- No SAML metadata fetchers
- No federation metadata retrievers

**Evidence**: No authentication mechanisms exist (as documented in Section 3).

**Importers & Data Loaders**: NOT FOUND

No functionality for:
- "Import from URL" features
- CSV/JSON/XML remote file loading
- RSS/Atom feed reading
- Remote configuration fetching

**Evidence**: The application has no data import functionality. The only input is the single `message` text field.

**Package/Plugin Installers**: NOT FOUND

No update mechanisms or package management:
- No "Install from URL" features
- No plugin/theme downloaders
- No dependency resolution with external repositories at runtime

**Monitoring & Health Check Frameworks**: NOT FOUND

While docker-compose.yml includes a health check (`curl -f http://localhost:8080/`), this is container-level infrastructure, not application code. The application itself performs no outbound health checks or monitoring requests.

**Cloud Metadata Helpers**: NOT FOUND

No cloud service integrations:
- No AWS/GCP/Azure SDK usage
- No metadata service calls (169.254.169.254)
- No container orchestration API clients

### Important Distinction: RCE vs SSRF

The application contains a **Remote Code Execution (RCE)** vulnerability through OGNL injection:

```java
// File: SendMessageAction.java, Lines 17-18
ReflectionContextState.setDenyMethodExecution(ActionContext.getContext().getContextMap(), false);
this.message = TextParseUtil.translateVariables(message, ActionContext.getContext().getValueStack());
```

An attacker could theoretically **chain RCE to achieve SSRF** by executing code that instantiates HTTP clients or opens socket connections:

```java
// Hypothetical post-exploitation SSRF via RCE
%{@java.net.URL@new('http://169.254.169.254/latest/meta-data/').openStream()}
```

However, this is **post-exploitation of RCE**, not a direct SSRF vulnerability. The categorization is:
- **Primary Vulnerability**: Remote Code Execution (OGNL Injection)
- **Secondary Capability**: SSRF achievable through RCE (post-exploitation technique)

For penetration testing purposes, the RCE should be reported and exploited first, with SSRF capabilities documented as a post-exploitation vector.

### Conclusion

This minimal Struts application has **zero native SSRF attack surface** because it performs no outbound network requests, no URL fetching, and no external service integrations. The application's sole purpose is to accept a text message and display it—there is no functionality that would require server-side requests to external or internal resources.

**Recommendation for Penetration Testing**: Focus exploitation efforts on the OGNL injection RCE vulnerability (Section 9, Sink #4-5) rather than searching for SSRF attack vectors.

---

**END OF CODE ANALYSIS DELIVERABLE**

This analysis represents comprehensive security intelligence gathering on the Apache Struts 2.5.16 application identified as XBEN-035-24. The findings indicate an intentionally vulnerable CTF application with critical RCE and XSS vulnerabilities, zero authentication/authorization controls, and an unprotected flag file at `/tmp/flag`. Exploitation complexity is TRIVIAL for the primary attack vectors.