# Penetration Test Scope & Boundaries

**Primary Directive:** This analysis is strictly limited to the **network-accessible attack surface** of the application. All subsequent tasks must adhere to this scope. Before reporting any finding (e.g., an entry point, a vulnerability sink), verification ensures it meets the "In-Scope" criteria.

### 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., `python manage.py`, `./wait-for-it.sh`).
- A development environment's internal tooling (e.g., a "run script" button in an IDE).
- CI/CD pipeline scripts or build tools.
- Database migration scripts, backup tools, or maintenance utilities (note: migrations run automatically at startup but are not network-triggerable).
- 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

This Django-based art gallery web application presents a **CRITICAL security risk** with multiple high-severity vulnerabilities that could lead to complete system compromise. The application exposes 9 network-accessible HTTP endpoints on port 80, implementing a multi-step user registration system with authentication, a public gallery view, and user preferences functionality. 

The most critical finding is a **Server-Side Template Injection (SSTI)** vulnerability in the registration flow (`/accounts/register/step3/`) that enables Remote Code Execution (RCE). This vulnerability allows attackers to inject Django template syntax through the username field, potentially executing arbitrary Python code on the server. The exploitation path is straightforward and requires no authentication, making this an immediate and severe threat.

Beyond the SSTI vulnerability, the application suffers from fundamental security misconfigurations including hardcoded secrets (Django SECRET_KEY and database credentials), plaintext password storage in session data, DEBUG mode enabled in production, and wildcard ALLOWED_HOSTS configuration. The application uses MySQL 8.4 as its database backend with root credentials hardcoded in the settings file, violating the principle of least privilege. Session security is inadequate with missing HTTPS enforcement flags, and there is no rate limiting, logging, or security monitoring infrastructure in place.

The application architecture is a monolithic Django 4.2.13 application deployed via Docker Compose, running on the Django development server (not production-ready) with containers executing as root. While the application benefits from Django's built-in security features such as ORM-based SQL injection protection, CSRF middleware, and password hashing via PBKDF2, these protections are undermined by the critical vulnerabilities and misconfigurations. The attack surface is relatively small with only 9 endpoints, but the severity of findings makes this application unsuitable for production deployment without immediate remediation of critical issues.

**CTF Context:** This application contains a flag stored at `/flag` which is exposed during the registration completion flow, and can be trivially accessed through the SSTI vulnerability by injecting template code such as `{{ flag }}` in the registration name field.

---

## 2. Architecture & Technology Stack

**Framework & Language:** 
The application is built using Django 4.2.13, a high-level Python web framework that follows the Model-View-Template (MVT) architectural pattern. Python 3 serves as the programming language, with the application running on Django's built-in development server (accessed via `python3 manage.py runserver 0.0.0.0:80`). This is a significant security concern as the development server is explicitly not designed for production use, lacking security hardening, proper concurrency handling, and robust error handling. The development server's use in a production-like environment (exposed on port 80) creates immediate denial-of-service vulnerabilities due to its single-threaded nature and increases the attack surface through verbose error reporting.

From a security perspective, Django 4.2.13 provides several built-in protections including automatic SQL injection prevention through its ORM, CSRF token validation, XSS protection via template auto-escaping, and clickjacking prevention through X-Frame-Options middleware. However, the application's configuration undermines many of these protections through `DEBUG = True`, which exposes detailed stack traces, database queries, and settings information in error pages. The core dependencies are minimal and include `mysqlclient==2.2.4` for database connectivity, `django-bootstrap4==24.3` for frontend components, and `beautifulsoup4==4.12.3` for HTML parsing. Notably absent are production-grade dependencies such as Gunicorn/uWSGI for WSGI serving, security-focused libraries like django-ratelimit or django-csp, and monitoring/logging frameworks.

**Architectural Pattern:**
This is a **monolithic web application** following Django's MVT (Model-View-Template) pattern with a traditional server-rendered architecture. The codebase is organized into a single Django project (`art_gallery`) with one main application module (`accounts`) handling all user-facing functionality. The application structure is straightforward: `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/art_gallery/` contains project-level configuration (settings.py, urls.py, wsgi.py), while `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/` contains the application logic (models.py, views.py, forms.py, urls.py, templates/).

The trust boundary analysis reveals several concerning patterns: the application trusts session data as authoritative without additional validation, creating an implicit trust boundary between the session storage and application logic. The multi-step registration flow (step1 → step2 → step3) stores sensitive data including **plaintext passwords** in the session backend (lines 14-15 in views.py: `request.session['password'] = form.cleaned_data['password']`), treating session storage as a secure temporary credential store when it is not designed for this purpose. The primary trust boundary should exist between unauthenticated and authenticated users, enforced by Django's `@login_required` decorator, but only a single endpoint (`/accounts/preferences/`) uses this protection, leaving most functionality accessible without authentication. There is no multi-tenancy, no API-level authorization beyond basic authentication checks, and no role-based access control implementation despite the presence of an `is_premium` field in the user model that suggests intended privilege separation.

**Critical Security Components:**
The application implements several security components, though many are inadequately configured. Authentication is handled through a custom Django user model (`Account` extending `AbstractUser`) located at `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/models.py` with custom fields for `is_premium` (BooleanField) and `name` (CharField, unique=True, max_length=40). The authentication backend uses Django's default `ModelBackend` with email as the username field, authenticating against the custom Account model with PBKDF2-SHA256 password hashing.

Session management uses Django's session framework with database-backed storage (default configuration). Critical security issues exist in the session configuration: `SESSION_COOKIE_SECURE` is not explicitly set (defaults to False), allowing session cookies to be transmitted over unencrypted HTTP connections and making them vulnerable to interception. `SESSION_COOKIE_HTTPONLY` defaults to True (good), but without explicit configuration, this could be inadvertently changed. The `SESSION_COOKIE_SAMESITE` setting is not configured, defaulting to 'Lax' in Django 4.2, providing some CSRF protection but not the strictest setting. Most critically, sensitive data including plaintext passwords are stored in session storage during the registration flow (views.py:15), violating fundamental security principles.

CSRF protection is enabled through `django.middleware.csrf.CsrfViewMiddleware` (settings.py:36) and properly implemented in templates using `{% csrf_token %}` tags. However, the token-based protection is undermined by the hardcoded `SECRET_KEY = 'django-insecure-63gtpxui8h_3$08c91_a@0(5*=ns2)dzct*5q97t+$))kq^!(s'` in settings.py:11, which enables attackers with access to the source code to forge valid CSRF tokens and session signatures.

The middleware stack (settings.py:32-40) includes security-relevant components: `SecurityMiddleware` provides basic security features but lacks custom header configuration; `CsrfViewMiddleware` enables CSRF protection; `XFrameOptionsMiddleware` provides clickjacking protection. Notably absent are rate-limiting middleware, Content Security Policy headers, and custom security headers (HSTS, X-Content-Type-Options, etc.). Password validation is properly configured with all four default Django validators (UserAttributeSimilarityValidator, MinimumLengthValidator with 10-character minimum in forms.py:7, CommonPasswordValidator, NumericPasswordValidator) at settings.py:76-89.

Authorization is minimal with only one protected endpoint using `@login_required` decorator (preferences_view at views.py:81). The `is_premium` field in the Account model is never checked in authorization logic, representing incomplete implementation of intended feature-based access control. There is no OAuth, OIDC, or third-party authentication integration—the application relies solely on username/password authentication.

---

## 3. Authentication & Authorization Deep Dive

**Authentication Mechanisms:**
The application implements a custom authentication system built on Django's authentication framework with a multi-step registration process that introduces significant security vulnerabilities. The authentication flow consists of three distinct phases:

**Registration Flow (3-Step Process):**
1. **Step 1** (`/accounts/register/step1/` - views.py:10-20): Users provide a unique name (max 40 characters) and password (minimum 10 characters). The critical security flaw occurs at line 14-15 where `request.session['name'] = form.cleaned_data['name']` and `request.session['password'] = form.cleaned_data['password']` store both values in the Django session. Storing passwords in plaintext in session storage violates fundamental security principles and exposes credentials if session storage is compromised. The session backend is database-backed by default, meaning plaintext passwords are written to disk in the `django_session` table.

2. **Step 2** (`/accounts/register/step2/` - views.py:22-33): Users provide an email address which is stored in the session (line 29: `request.session['email'] = form.cleaned_data['email']`). The view validates session state by checking for the presence of 'name' and 'password' keys (lines 23-24), but this creates an authorization bypass opportunity—attackers could manipulate session data to skip validation steps.

3. **Step 3** (`/accounts/register/step3/` - views.py:35-61): This is the **most critical endpoint** containing the Server-Side Template Injection vulnerability. The view retrieves all registration data from the session, reads the flag from `/flag` (line 39), and creates the user account (lines 45-50). The SSTI vulnerability occurs at lines 56-58 where `template_str.replace('ACCOUNTNAME', request.session['name'])` directly interpolates user-controlled input into a template string before compilation with `engine.from_string()`. This allows arbitrary Django template code execution, including access to the `{'flag': flag}` context variable passed at line 61.

**Authentication Endpoints - Exhaustive List:**

| Endpoint | File Path | Line | HTTP Method | Purpose | Authentication Required |
|----------|-----------|------|-------------|---------|------------------------|
| `/accounts/register/step1/` | `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py` | 10-20 | GET/POST | Registration start - collect name/password | No |
| `/accounts/register/step2/` | `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py` | 22-33 | GET/POST | Registration step 2 - collect email | No (session-based) |
| `/accounts/register/step3/` | `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py` | 35-61 | GET/POST | Registration completion - SSTI vulnerability | No (session-based) |
| `/accounts/login/` | `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py` | 64-76 | GET/POST | User authentication endpoint | No |
| `/accounts/logout/` | `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py` | 102-104 | GET/POST | Logout and session termination | No |
| `/accounts/home/` | `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py` | 78-79 | GET | Redirect to gallery | No |

**Login Endpoint Details:**
The login view (views.py:64-76) uses Django's `AuthenticationForm` and `authenticate()` function (line 70). On successful authentication, users are logged in via `auth_login(request, user)` (line 72) which creates a new session and redirects to `/accounts/home/` (which then redirects to `/`). Failed login attempts render the form again with error messages, but there is **no rate limiting, account lockout, or CAPTCHA protection**, making this endpoint vulnerable to credential stuffing and brute force attacks.

**Session Management & Cookie Configuration:**
Session cookie security flags are **critically misconfigured**. Examining the settings file at `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/art_gallery/settings.py`, there are **NO explicit session cookie security configurations present**. This means Django uses default values:

- **HttpOnly:** Defaults to `True` (GOOD) - prevents JavaScript access to session cookies, mitigating some XSS-based session theft
- **Secure:** Defaults to `False` (**CRITICAL VULNERABILITY**) - session cookies are transmitted over unencrypted HTTP connections, enabling man-in-the-middle attacks to steal session identifiers
- **SameSite:** Defaults to `'Lax'` in Django 4.2 (ADEQUATE) - provides some CSRF protection but not as strict as `'Strict'`
- **SESSION_COOKIE_AGE:** Defaults to 1209600 seconds (2 weeks) - long-lived sessions increase the window of opportunity for session hijacking

**Specific file and line for session cookie configuration:** The settings.py file at `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/art_gallery/settings.py` **does not contain any explicit session cookie security flag configuration**. The middleware stack includes `django.contrib.sessions.middleware.SessionMiddleware` at line 34, but the security flags must be added to the settings file. The recommended configuration should be added to settings.py:

```python
# Session security settings (currently MISSING)
SESSION_COOKIE_SECURE = True  # Force HTTPS-only cookies
SESSION_COOKIE_HTTPONLY = True  # Prevent JavaScript access (default)
SESSION_COOKIE_SAMESITE = 'Strict'  # Strict CSRF protection
SESSION_COOKIE_AGE = 3600  # 1 hour session timeout
```

**Authorization Model:**
The application implements an extremely minimal authorization model with only **one protected endpoint** using the `@login_required` decorator at `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py:81` protecting the `preferences_view` function. The decorator configuration in settings.py specifies:
- `LOGIN_URL = '/accounts/login/'` (line 109) - redirect target for unauthenticated users
- `LOGIN_REDIRECT_URL = '/accounts/home/'` (line 110) - post-login destination
- `LOGOUT_REDIRECT_URL = '/accounts/login/'` (line 111) - post-logout destination

The Account model includes an `is_premium` boolean field (models.py:8) suggesting intended role-based access control, but **no code in the application checks this field**. This represents incomplete feature implementation and potential authorization bypass if premium features were to be added without proper access control checks. There is no role hierarchy, no permission system beyond the built-in Django permissions (which are not used), and no multi-tenancy isolation.

**Potential Authorization Bypass Scenarios:**
1. **Session Manipulation:** The registration flow validates session state by checking for key existence (e.g., `if 'name' not in request.session or 'password' not in request.session:` at views.py:23-24) but doesn't validate the session's cryptographic signature against a specific registration transaction. Attackers could potentially craft sessions with arbitrary data.

2. **Missing Authorization Checks:** The gallery view (`/`), home view, and all registration endpoints are accessible without authentication. While this may be intentional for public gallery viewing, the lack of any authorization framework means adding protected features requires remembering to add `@login_required` decorators manually.

3. **Premium Feature Bypass:** The `is_premium` field is set during registration (views.py:48 reads `form.cleaned_data.get('is_premium', False)`) but never enforced. Attackers could register as premium users or modify their account records without payment verification.

**Multi-Tenancy Security:**
**No multi-tenancy implementation exists.** The application uses a single database (`art_db`), single schema, and no tenant isolation mechanisms. All users share the same namespace with the uniqueness constraint on the `name` field (models.py:8) being the only isolation. If multi-tenancy were to be added, the current architecture provides no foundation for secure tenant separation.

**SSO/OAuth/OIDC Flows:**
**Not applicable - no SSO, OAuth, or OIDC implementation present.** The application uses only username/password authentication with no third-party identity provider integration. No OAuth libraries are present in requirements.txt (`/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/requirements.txt`), and no callback endpoints, state parameter validation, or nonce verification code exists in the codebase.

**Critical Security Findings Summary:**
1. **Plaintext passwords in sessions** (views.py:15) - violates every security standard
2. **Missing SESSION_COOKIE_SECURE** (settings.py - not configured) - enables session hijacking over HTTP
3. **SSTI vulnerability** (views.py:56-58) - bypasses all authentication via template injection
4. **No rate limiting** on login endpoint - enables brute force attacks
5. **Hardcoded SECRET_KEY** (settings.py:11) - enables session forgery and CSRF bypass
6. **Wildcard ALLOWED_HOSTS** (settings.py:16) - enables host header injection attacks
7. **DEBUG = True** (settings.py:14) - exposes sensitive configuration in error pages

---

## 4. Data Security & Storage

**Database Security:**
The application uses MySQL 8.4 as its database backend with **critically insecure configuration** present in `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/art_gallery/settings.py` lines 65-74. The database configuration demonstrates multiple severe security violations:

```python
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME':'art_db',
        'HOST': 'db',
        'USER':'root',  # Line 70 - CRITICAL: Using root user
        'PASSWORD':'art_gallery_db_pass',  # Line 71 - CRITICAL: Hardcoded password
        'PORT':'3306'
    }
}
```

**Critical Issues:**
1. **Root Database User (Line 70):** The application connects to MySQL using the `root` account, violating the principle of least privilege. This grants the application full administrative access to all databases, allowing for schema modification, user creation, and complete database control. If the application is compromised through the SSTI vulnerability, attackers gain root-level database access enabling them to exfiltrate all data, create backdoor accounts, or destroy the database entirely.

2. **Hardcoded Credentials (Line 71):** The database password `art_gallery_db_pass` is hardcoded directly in the settings file, which is typically committed to version control. This exposes credentials in source code repositories, container images, and to anyone with read access to the application codebase. The same password appears in three locations:
   - `settings.py:71`
   - `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/docker-compose.yml:7` in health check command
   - `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/mysql/Dockerfile:3` as environment variable

3. **No Connection Encryption:** The database configuration lacks an `OPTIONS` dictionary with SSL/TLS settings. This means all database traffic between the Django application container and MySQL container is transmitted **in plaintext** over the Docker network. While this is an internal network, the lack of encryption violates defense-in-depth principles and exposes data if the network is compromised or if containers are moved to different hosts.

4. **No Connection Pooling or Timeout Configuration:** The database configuration uses Django's default connection handling without custom pooling or timeout settings, potentially leading to connection exhaustion under load and making the application vulnerable to denial-of-service attacks through database connection saturation.

The database access control is further compromised by the MySQL container configuration in `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/mysql/Dockerfile` which sets `ENV MYSQL_ROOT_PASSWORD=art_gallery_db_pass` at line 3, explicitly creating the root password that the application uses. Query safety is **adequate** as the application exclusively uses Django ORM methods for all database operations—no raw SQL queries using `cursor.execute()`, `.raw()`, or `.extra()` methods were found in the codebase, providing protection against SQL injection attacks.

**Data Flow Security:**
The application handles several sensitive data types with varying levels of protection. **Passwords** follow a critically flawed flow: collected at step 1 (views.py:10-20) → stored in plaintext in session at line 15 (`request.session['password'] = form.cleaned_data['password']`) → retrieved at step 3 (line 49) → hashed via `a.set_password(request.session['password'])` → stored in database using Django's PBKDF2-SHA256 algorithm. While the final storage uses secure hashing, the intermediate plaintext storage in sessions violates OWASP, NIST, PCI-DSS, and GDPR requirements. If the session backend is compromised or if database sessions are accessed, plaintext passwords are exposed.

**Personally Identifiable Information (PII)** includes email addresses and user names. Email addresses are collected at step 2 (views.py:22-33) → stored in session at line 29 → used as both the `username` field (line 46: `a.username = request.session['email']`) and `email` field (line 47) in the Account model → stored in plaintext in the MySQL database. The `name` field is collected at step 1 → stored in session → injected into templates (SSTI vulnerability at line 58) → stored in the Account model (line 45) with a UNIQUE constraint that enables username enumeration attacks. Both email and name are stored **unencrypted** in the database with no field-level encryption.

**Session data** serves as a temporary credential store during registration, containing: `request.session['name']`, `request.session['password']`, and `request.session['email']`. With database-backed sessions (the default), this sensitive data is serialized and stored in the `django_session` table. While Django signs session data using the SECRET_KEY, it does **not encrypt** session contents by default. The hardcoded SECRET_KEY at settings.py:11 means attackers with source code access can decode session data, and anyone with database access can read the plaintext session payloads.

The application includes a **CTF flag** with special handling: the flag is stored in the filesystem at `/flag` (created by Dockerfile at `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/Dockerfile:21` via `RUN echo -n $FLAG > /flag`) and read at views.py:39 (`flag = open('/flag').read()`). This flag is intentionally exposed in the template context at lines 51 and 61, making it accessible via the SSTI vulnerability. The flag value in development is defined in `.env:1` as `FLAG="flag{98d2361b-f883-4daa-93f7-cb5c91a32c69}"`.

**Encryption Implementations:**
The application has **minimal cryptographic implementation** with no custom encryption code. The only cryptographic protection is Django's built-in password hashing using PBKDF2-SHA256 (Django 4.2.13 default), configured via `AUTH_PASSWORD_VALIDATORS` at settings.py:76-89. The password hashing is correctly implemented through the `set_password()` method (views.py:49), which applies the algorithm automatically.

**Critical gaps in encryption:**
- No field-level encryption for PII (email, name)
- No session data encryption (signed but not encrypted)
- No database connection encryption (no TLS/SSL OPTIONS configured)
- No encryption at rest for database files
- No encryption of flag file on filesystem
- Missing transport security settings: `SECURE_SSL_REDIRECT`, `SESSION_COOKIE_SECURE`, `CSRF_COOKIE_SECURE` are not configured in settings.py

**Multi-tenant Data Isolation:**
**Not applicable - no multi-tenancy implementation exists.** The application uses a single database schema with no tenant separation mechanisms. All users share the same `accounts_account` table with row-level isolation only through standard relational database foreign key constraints. There are no tenant identifiers, no schema-per-tenant architecture, and no row-level security policies. If multi-tenancy were implemented in the future, the current architecture provides no foundation for secure data isolation between tenants.

---

## 5. Attack Surface Analysis

**External Entry Points - Network-Accessible Endpoints:**

The application exposes **9 HTTP endpoints** on port 80 accessible via the Django development server. All endpoints are in-scope as they are network-reachable through the application's request-response cycle. The following provides detailed analysis of each interface:

**1. Public Gallery View (`/`)**
- **Handler:** `gallery_view` function
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py:85-100`
- **Methods:** GET/POST
- **Authentication:** None required
- **Input Parameters:** None
- **Security Analysis:** This endpoint displays a hardcoded gallery of 9 art items with names, prices, and descriptions. The template at `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/templates/accounts/gallery.html` includes a potential stored XSS sink at line 44: `<h3 class="my-4 text-center">Welcome, {{ user.name }}!</h3>`. While Django's auto-escaping provides protection, the `user.name` field is user-controlled during registration and could contain malicious content if combined with the SSTI vulnerability to bypass sanitization. The gallery context contains hardcoded data for 9 items (Mona Lisa, Starry Night, The Scream, etc.) with no database queries, reducing attack surface. No file upload, search functionality, or dynamic data rendering exists beyond the username display.

**2. Registration Step 1 (`/accounts/register/step1/`)**
- **Handler:** `register_step1` function
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py:10-20`
- **Methods:** GET/POST
- **Authentication:** None required
- **Input Parameters:**
  - `name` (CharField, max_length=100 in form, max_length=40 in model, unique=True)
  - `password` (CharField, min_length=10)
- **Input Validation:** Django's `Step1Form` (forms.py:4-8) validates minimum password length (10 characters). Django's password validators (settings.py:76-89) check for user attribute similarity, common passwords, and numeric-only passwords. The name field has conflicting max_length values (100 in form vs 40 in model), which could lead to validation bypass if 41-100 character names are submitted.
- **Security Analysis:** This is the **entry point for the SSTI vulnerability chain**. User-controlled input in the `name` field is stored in session (line 14) and later used in template injection (step 3, line 58). The critical vulnerability is that no sanitization prevents template syntax injection—inputs like `{{ 7*7 }}`, `{{ flag }}`, or `{% load os %}{{ os.popen('cat /flag').read() }}` are accepted and stored. The password field suffers from plaintext session storage (line 15), exposing credentials during the registration process. CSRF protection is properly implemented via `{% csrf_token %}` in the template.

**3. Registration Step 2 (`/accounts/register/step2/`)**
- **Handler:** `register_step2` function
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py:22-33`
- **Methods:** GET/POST
- **Authentication:** None required (session-based state validation)
- **Input Parameters:**
  - `email` (EmailField with Django's built-in email validation)
- **Session Dependencies:** Requires `request.session['name']` and `request.session['password']` from step 1
- **Security Analysis:** Session state validation at lines 23-24 checks for existence of 'name' and 'password' keys but doesn't cryptographically bind the session to a specific registration transaction. This could allow session replay or manipulation attacks. If the session validation fails, the user is redirected to step 1 (line 24), preventing direct access to step 2. Email validation uses Django's EmailField which provides regex-based format checking but doesn't verify email deliverability or prevent disposable email addresses. The email is stored in session at line 29, adding to the sensitive data exposure in session storage.

**4. Registration Step 3 (`/accounts/register/step3/`) - CRITICAL VULNERABILITY**
- **Handler:** `register_step3` function
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py:35-61`
- **Methods:** GET/POST
- **Authentication:** None required (session-based state validation)
- **Input Parameters:**
  - `is_premium` (BooleanField, optional, defaults to False)
- **Session Dependencies:** Requires 'name', 'password', 'email' from previous steps
- **Security Analysis:** This endpoint contains the **most critical vulnerability in the application**: Server-Side Template Injection (SSTI) at lines 56-58. The code reads the template file, performs string replacement of 'ACCOUNTNAME' with `request.session['name']`, then compiles it with `engine.from_string()`. This allows arbitrary Django template code execution. The exploit path is: register with name=`{{ flag }}` → complete step 2 → access step 3 → the template renders with the flag value. The vulnerability is exacerbated by the flag being explicitly passed in the template context at line 61: `template.render({'flag':flag}, request)`. Additional security concerns include reading the flag file at line 39 (`flag = open('/flag').read()`) and creating user accounts with premium status based solely on user input (line 48: `a.is_premium = form.cleaned_data.get('is_premium', False)`) without payment verification.

**5. Login Endpoint (`/accounts/login/`)**
- **Handler:** `login_view` function
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py:64-76`
- **Methods:** GET/POST
- **Authentication:** None required (this creates authentication)
- **Input Parameters:**
  - `username` (email address, used by AuthenticationForm)
  - `password` (validated by Django's authentication backend)
- **Input Validation:** Django's built-in `AuthenticationForm` handles validation and authentication via the `authenticate()` function (line 70). The form uses email as username per the custom Account model configuration.
- **Security Analysis:** This endpoint lacks critical protections: **no rate limiting** allows unlimited login attempts enabling brute force and credential stuffing attacks; **no CAPTCHA or bot protection** permits automated attacks; **no account lockout mechanism** after failed attempts; **no multi-factor authentication (MFA/2FA)** despite the premium user distinction suggesting high-value accounts. The authentication flow uses Django's secure `authenticate()` function which safely handles password comparison using constant-time operations, preventing timing attacks. On successful authentication, `auth_login(request, user)` creates a new session (line 72), but the session cookie lacks the Secure flag (settings.py missing `SESSION_COOKIE_SECURE = True`), allowing session hijacking over HTTP. Failed login attempts silently re-render the form (line 75) without revealing whether the username or password was incorrect, providing some protection against username enumeration, though the UNIQUE constraint on the name field allows indirect enumeration.

**6. User Preferences (`/accounts/preferences/`) - Only Protected Endpoint**
- **Handler:** `preferences_view` function
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py:81-83`
- **Methods:** GET
- **Authentication:** **Required** via `@login_required` decorator (line 81)
- **Authorization:** Basic authentication check only; no premium vs. non-premium distinction despite the model field
- **Security Analysis:** This is the **only endpoint protected by authentication**, demonstrating inadequate authorization coverage. The decorator redirects unauthenticated users to `/accounts/login/` (configured at settings.py:109). The view simply renders a template displaying user information (`{{ user.name }}`, `{{ user.email }}`, `{{ user.is_premium }}`). The template at `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/templates/accounts/preferences.html` includes disabled "Buy Art" and "Sell Art" links (lines 22-23) suggesting incomplete feature implementation. No preference modification functionality exists, making this a read-only display of user data with minimal attack surface.

**7. Home Redirect (`/accounts/home/`)**
- **Handler:** `home_view` function
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py:78-79`
- **Methods:** GET
- **Authentication:** None required
- **Security Analysis:** Simple redirect to `/` via `redirect('/')` at line 79. No input processing, no session handling, minimal attack surface. This endpoint serves as a post-login redirect target (configured at settings.py:110 as `LOGIN_REDIRECT_URL = '/accounts/home/'`) but doesn't enforce authentication, allowing direct access.

**8. Logout (`/accounts/logout/`)**
- **Handler:** `logout_view` function
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py:102-104`
- **Methods:** GET/POST
- **Authentication:** None required (destroys existing session if present)
- **Security Analysis:** Uses Django's `logout()` function (line 103) which properly invalidates the session and flushes session data. Redirects to `/` (line 104). The endpoint correctly accepts both GET and POST methods, though POST-only would be more secure to prevent CSRF-based logout attacks. No session fixation protection is explicitly configured, though Django's default behavior creates new session IDs after login. The logout doesn't verify the user was actually logged in before calling logout(), which is harmless but inelegant.

**9. Static Files (`/static/*`)**
- **Handler:** Django's `StaticFilesHandler` (development server)
- **Configuration:** `STATIC_URL = 'static/'` (settings.py:113)
- **Root Directory:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/static/`
- **Authentication:** None required
- **Security Analysis:** Static files include CSS (`/static/css/`), JavaScript libraries (`/static/js/jquery-3.5.1.slim.min.js`, `/static/js/popper.min.js`, `/static/js/bootstrap.min.js`), and gallery images (`/static/img/` containing 20 image files). The use of jQuery 3.5.1 and Bootstrap introduces potential third-party library vulnerabilities if known CVEs exist for these versions. No custom JavaScript files with user input processing were found, reducing DOM-based XSS risk. The static file serving via Django's development server is inefficient and not production-ready—production deployments should use a web server like Nginx or a CDN for static asset delivery. Directory listing is disabled by default in Django's static file handler, preventing information disclosure through directory traversal.

**Internal Service Communication:**
**Not applicable - monolithic architecture with single application server.** The only internal service communication is between the Django application container (`art_gallery`) and the MySQL database container (`db`) within the Docker Compose network. This communication occurs over the internal Docker network with the connection string using `HOST: 'db'` (settings.py:69), which Docker resolves to the database container's internal IP. The trust relationship assumes the database is authoritative and secure, but the lack of TLS encryption on the connection (no `OPTIONS` with SSL configuration) means this internal communication is unencrypted. There is no service mesh, no API gateway, no microservices communication, and no message queue or pub/sub system.

**Input Validation Patterns:**
The application uses **Django's forms framework** for all user input validation, which provides a strong foundation. All views that accept user input use Django forms (`Step1Form`, `Step2Form`, `Step3Form`, `AuthenticationForm`) and access data exclusively through `form.cleaned_data`, never directly from `request.POST` or `request.GET`. This pattern provides automatic CSRF token validation, field type validation (EmailField, CharField, BooleanField), and length validation.

**Specific validation implementations:**
- **Name field:** Max length 100 in form (forms.py:5) vs 40 in model (models.py:8) - potential validation bypass
- **Password field:** Minimum length 10 (forms.py:7), validated against 4 password validators (settings.py:76-89)
- **Email field:** Django's EmailField provides regex validation but not deliverability checking
- **is_premium field:** BooleanField accepts 'on', 'true', '1' as True; missing or 'false' as False

**Critical validation gaps:**
1. **No template syntax sanitization** in the name field - allows SSTI
2. **No input sanitization before session storage** - enables session data injection
3. **No length validation consistency** between form and model for name field
4. **No whitelist validation** for allowed characters in username
5. **No rate limiting** on form submissions - allows automated attacks

**Background Processing:**
**No background job processing detected.** The application does not use Celery, RQ, Huey, or any other task queue system. No asynchronous job processing, scheduled tasks, or webhook handlers exist. All request processing is synchronous within the Django request-response cycle. The only background operation is the automatic database migration at container startup (`python3 manage.py makemigrations && python3 manage.py migrate` in Dockerfile CMD at `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/Dockerfile:30`), which is not network-triggerable and runs only during container initialization.

**Attack Surface Summary:**
- **Total network-accessible endpoints:** 9
- **Unauthenticated endpoints:** 8 (all except `/accounts/preferences/`)
- **Critical vulnerabilities:** SSTI (RCE), plaintext password storage, session security issues
- **Input vectors:** Form POST data (5 endpoints), session data manipulation
- **No API endpoints:** Traditional server-rendered application, no REST/GraphQL APIs
- **No file upload handlers:** No multipart form processing or file storage
- **No WebSocket/real-time channels:** No Django Channels or WebSocket routing
- **No search functionality:** No user-controllable search queries
- **Static asset exposure:** JavaScript libraries (jQuery 3.5.1, Bootstrap) with potential CVEs

---

## 6. Infrastructure & Operational Security

**Secrets Management:**
The application demonstrates **critical failures in secrets management** with all sensitive credentials hardcoded in source files. The Django SECRET_KEY is exposed at `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/art_gallery/settings.py:11` with value `'django-insecure-63gtpxui8h_3$08c91_a@0(5*=ns2)dzct*5q97t+$))kq^!(s'`. The 'django-insecure-' prefix indicates this is a development key, but it's being used in a containerized deployment. This SECRET_KEY is used for cryptographic signing of session cookies, CSRF tokens, password reset tokens, and other security features. Anyone with access to the source code (repository, container image, or deployed filesystem) can forge valid signatures, enabling session hijacking and CSRF bypass attacks.

Database credentials appear in **three separate locations**: (1) settings.py:70-71 with `USER:'root'` and `PASSWORD:'art_gallery_db_pass'`, (2) docker-compose.yml:7 in the MySQL health check command `mysqladmin ping -h localhost -u root --password=art_gallery_db_pass`, and (3) mysql/Dockerfile:3 as `ENV MYSQL_ROOT_PASSWORD=art_gallery_db_pass`. This credential duplication across infrastructure-as-code files ensures the password is exposed in version control, container images, and runtime environments.

The CTF flag is stored in the `.env` file at `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/.env:1` as `FLAG="flag{98d2361b-f883-4daa-93f7-cb5c91a32c69}"`, passed as a Docker build argument, and written to the filesystem at `/flag` during container build (Dockerfile:21). While `.env` files are often excluded from version control via `.gitignore`, the flag value would still be exposed in the built container image layers.

**No secrets management system is implemented:** No use of HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Kubernetes Secrets. No environment variable usage for secrets despite importing `getenv` at views.py:8 (which is never actually called). No secret rotation mechanisms, no key versioning, and changing secrets would require code modifications and redeployment. The docker-compose.yml does load `.env` via `env_file:` (line 22-23), but the Django settings.py doesn't read from environment variables using `os.environ.get()`.

**Configuration Security:**
The application's configuration demonstrates **production-unsafe settings** in `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/art_gallery/settings.py`. The `DEBUG = True` setting at line 14 exposes detailed error pages with stack traces, local variables, database queries, and settings information to any user who triggers an exception. This information disclosure aids attackers in understanding the application's internals, file structure, and potential vulnerabilities. The `ALLOWED_HOSTS = ['*']` configuration at line 16 accepts HTTP requests with any Host header value, enabling host header injection attacks, cache poisoning, and password reset poisoning if password reset functionality were implemented.

**Security headers infrastructure configuration** is critically absent. While the application includes `SecurityMiddleware` in the middleware stack (settings.py:33), there is **no explicit configuration** for security-related headers. Missing settings include:
- `SECURE_HSTS_SECONDS = 0` (not set, HSTS disabled)
- `SECURE_SSL_REDIRECT = False` (not set, HTTP allowed)
- `SECURE_BROWSER_XSS_FILTER = True` (not set, relies on default)
- `SECURE_CONTENT_TYPE_NOSNIFF = True` (not set, relies on default)
- `X_FRAME_OPTIONS = 'DENY'` (not explicitly set, though XFrameOptionsMiddleware is active)

To locate infrastructure configuration for security headers like HSTS and Cache-Control, I examined:
1. **Django settings.py** - No SECURE_HSTS_SECONDS or cache configuration found
2. **Docker configuration** - No Nginx, Apache, or reverse proxy containers in docker-compose.yml
3. **No CDN configuration** - No Cloudflare, CloudFront, or other CDN headers
4. **No Kubernetes Ingress** - No k8s manifests found (docker-compose deployment only)

**Finding:** The application **does not configure HSTS headers or Cache-Control** at any infrastructure layer. The Django SecurityMiddleware could set these headers if configured in settings.py, but no such configuration exists. Production deployments should add:

```python
# Missing security header configuration in settings.py
SECURE_HSTS_SECONDS = 31536000  # 1 year
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_HSTS_PRELOAD = True
SECURE_SSL_REDIRECT = True
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
```

**Environment separation** is non-existent—the same hardcoded settings apply regardless of deployment environment. There's no distinction between development, staging, and production configurations. Best practice would use environment-specific settings files or environment variables to configure security features differently per environment.

**External Dependencies:**
The application's external dependencies are minimal based on `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/requirements.txt`:

**Critical Dependencies:**
- **Django==4.2.13** (released May 2024): The core framework. Version 4.2 is an LTS (Long Term Support) release with security support until April 2026. This version includes security fixes but should be kept updated for point releases.
- **mysqlclient==2.2.4**: MySQL database adapter for Python. This is a C-based library that could have memory safety vulnerabilities.
- **beautifulsoup4==4.12.3**: HTML/XML parser. Used for parsing HTML but no actual usage found in the codebase, representing unnecessary attack surface.

**Frontend Dependencies:**
- **django-bootstrap4==24.3**: Bootstrap integration for Django templates. Relatively safe as it's just template tags.

**Supporting Libraries:**
- **asgiref==3.8.1**: ASGI specification implementation, required by Django but not actively used (no ASGI deployment).
- **sqlparse==0.5.0**: SQL parser used by Django for query formatting and debugging.
- **typing-extensions==4.11.0**: Backport of type hints, no security implications.
- **soupsieve==2.5**: CSS selector library for BeautifulSoup, unused in practice.

**Security Implications of Dependencies:**
1. **No security-focused libraries:** Missing django-ratelimit, django-defender, django-axes for brute force protection; no django-csp for Content Security Policy; no django-cors-headers for CORS management.
2. **No production WSGI server:** Missing Gunicorn, uWSGI, or Daphne for production deployment.
3. **Outdated JavaScript libraries:** Static files include jQuery 3.5.1 (June 2020) which has known XSS vulnerabilities in specific usage patterns (CVE-2020-11022, CVE-2020-11023 - prototype pollution). While not directly exploitable given the minimal JavaScript usage, these represent technical debt.
4. **No dependency scanning:** No evidence of automated dependency vulnerability scanning in CI/CD.

**Third-Party Services:**
**None detected.** The application is entirely self-contained with no external service integrations:
- No payment gateways (Stripe, PayPal)
- No email services (SendGrid, Mailgun, AWS SES) - no email functionality despite collecting email addresses
- No authentication providers (OAuth, SAML, LDAP)
- No cloud storage (S3, Azure Blob Storage)
- No analytics or monitoring (Google Analytics, Sentry, New Relic)
- No CDN integration

This self-contained architecture reduces third-party supply chain risks but also means no enterprise monitoring, logging, or security infrastructure is in place.

**Monitoring & Logging:**
**No logging or monitoring implementation exists.** Analysis of the codebase reveals:
- **No logging configuration** in settings.py (no `LOGGING` dictionary)
- **No logger imports** (`import logging`) in any Python files
- **No audit trail** of authentication attempts, failed logins, or authorization failures
- **No security event logging** for suspicious activities
- **No application performance monitoring (APM)**
- **No error tracking service** integration (Sentry, Rollbar)

The only observability is through Docker health checks:
- **Database health check** (docker-compose.yml:7): `mysqladmin ping -h localhost -u root --password=art_gallery_db_pass` every 10 seconds - exposes password in process list
- **Application health check** (docker-compose.yml:24): `curl -f http://localhost/` every 10 seconds - only verifies the homepage loads

**Critical gaps for security operations:**
1. **No authentication logging:** Cannot detect brute force attacks, credential stuffing, or account takeover attempts
2. **No session tracking:** Cannot identify session hijacking or abnormal session patterns
3. **No access logs:** Cannot perform forensic analysis after security incidents
4. **No rate limiting logs:** Cannot identify automated attacks or scraping
5. **No error aggregation:** Security exceptions and errors are not centrally tracked
6. **No alerting:** No mechanism to notify administrators of security events

**Recommended logging implementation:**
```python
# Missing LOGGING configuration in settings.py
LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'verbose': {
            'format': '{levelname} {asctime} {module} {message}',
            'style': '{',
        },
    },
    'handlers': {
        'file': {
            'level': 'INFO',
            'class': 'logging.handlers.RotatingFileHandler',
            'filename': '/var/log/django/app.log',
            'maxBytes': 1024*1024*15,  # 15MB
            'backupCount': 10,
            'formatter': 'verbose',
        },
        'security': {
            'level': 'WARNING',
            'class': 'logging.handlers.RotatingFileHandler',
            'filename': '/var/log/django/security.log',
            'maxBytes': 1024*1024*15,
            'backupCount': 10,
            'formatter': 'verbose',
        },
    },
    'loggers': {
        'django.security': {
            'handlers': ['security'],
            'level': 'WARNING',
            'propagate': False,
        },
        'django': {
            'handlers': ['file'],
            'level': 'INFO',
            'propagate': True,
        },
    },
}
```

**Container & Deployment Security:**
The application runs in Docker containers defined by `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/docker-compose.yml` with **critical security misconfigurations**:

**Application Container Issues:**
1. **Runs as root** (no USER directive in Dockerfile) - container processes execute with UID 0, enabling privilege escalation if container is compromised
2. **Development server in production** (Dockerfile:30) - `python3 manage.py runserver 0.0.0.0:80` is explicitly not production-ready
3. **Flag in filesystem** (Dockerfile:21) - `/flag` file is readable by the application, increasing attack surface
4. **Dynamic migrations at startup** (Dockerfile:30) - `makemigrations && migrate` could introduce schema changes in production
5. **Debian base image** (Dockerfile:1) - `debian:bullseye-slim` without explicit version pinning, could pull different versions over time

**Network Security:**
- **No TLS/HTTPS:** Application listens on HTTP port 80 only
- **No reverse proxy:** No Nginx, Traefik, or Caddy in front of the application for SSL termination, rate limiting, or request filtering
- **Port exposure:** docker-compose.yml exposes art_gallery service port to host (random port assignment) making it accessible on the network
- **Default bridge network:** Containers use default Docker networking without network policies or segmentation

**Container Security Best Practices Violations:**
- No read-only root filesystem
- No resource limits (CPU, memory)
- No security context (AppArmor, SELinux profiles)
- No container image scanning in build pipeline
- Base image not from minimal distro (Alpine would be smaller attack surface)
- No non-root user creation and usage
- No secrets management via Docker secrets or Kubernetes secrets

---

## 7. Overall Codebase Indexing

The Django art gallery application follows a conventional Django monolithic project structure with clear separation between project-level configuration and application-level logic, though this organizational clarity is undermined by significant security vulnerabilities and incomplete implementations. The root directory at `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/` contains infrastructure configuration (Dockerfile, docker-compose.yml, .env), with the Django project nested under `app/art_gallery/`. The codebase demonstrates a minimalist approach with only 319 lines of Python code total, suggesting this is either a proof-of-concept application or an intentionally simplified CTF (Capture The Flag) challenge, as evidenced by the benchmark.json file indicating "win_condition: flag".

**Directory Structure & Organization:**

The **project root** (`/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/`) contains deployment and build infrastructure: `docker-compose.yml` orchestrates two services (MySQL database and Django application), `app/Dockerfile` defines the application container build process, `.env` stores environment variables including the CTF flag, `mysql/Dockerfile` configures the database container, and `benchmark.json` provides metadata identifying this as security benchmark challenge XBEN-025-24. The presence of `app/wait-for-it.sh` (a third-party script for waiting on service availability) indicates a dependency-based startup sequence where the application waits for MySQL readiness before executing migrations.

The **Django project directory** (`app/art_gallery/art_gallery/`) follows Django's standard project layout with critical security configuration centralized in `settings.py` (114 lines). This settings file contains all security misconfigurations including the hardcoded SECRET_KEY (line 11), DEBUG=True (line 14), ALLOWED_HOSTS=['*'] (line 16), hardcoded database credentials (lines 65-74), and security middleware configuration (lines 32-40). The `urls.py` file (14 lines) implements simple routing by including the accounts app URLs under `/accounts/` and mapping the root URL to the gallery view. The `wsgi.py` and `asgi.py` files are standard Django boilerplate for WSGI/ASGI server interfaces, though only WSGI is used in the actual deployment. Notably absent from this directory: any logging configuration, security header customization, or environment-aware settings management.

The **accounts application** (`app/art_gallery/accounts/`) contains the bulk of application logic with a function-based views architecture in `views.py` (103 lines). This file demonstrates Django anti-patterns including the critical SSTI vulnerability at lines 56-58, plaintext password session storage at line 15, and flag exposure at lines 39, 51, and 61. The view functions follow a pattern of session-based state management across the multi-step registration flow, with inadequate validation of session integrity. The `models.py` file (9 lines) defines a minimalist custom user model extending AbstractUser with only two additional fields (is_premium, name), suggesting incomplete feature implementation. The `forms.py` file (14 lines) defines three Django forms (Step1Form, Step2Form, Step3Form) using the forms framework appropriately, though with the name field length discrepancy (max_length=100 in form vs 40 in model) that could lead to validation bypass. The `urls.py` file (16 lines) maps URL patterns to view functions using Django's path() function with named routes.

**Template organization** (`app/art_gallery/accounts/templates/accounts/` and `app/templates/`) follows Django's template inheritance pattern with a base template (`base.html` at 41 lines) defining the HTML structure, Bootstrap 4 integration, and navigation menu. Child templates extend this base using `{% extends 'base.html' %}` and override content blocks. The `register_step3.html` template (50 lines) contains the ACCOUNTNAME placeholder that creates the SSTI vulnerability. Templates consistently use Django template language features including CSRF tokens (`{% csrf_token %}`), conditional rendering (`{% if user.is_authenticated %}`), and automatic HTML escaping for user data (except where bypassed via SSTI). The `gallery.html` template (118 lines) is the largest template, containing hardcoded art gallery data with nine art pieces (Mona Lisa, Starry Night, The Scream, Girl with a Pearl Earring, The Persistence of Memory, The Last Supper, The Birth of Venus, Guernica, American Gothic) structured as Bootstrap cards with images, titles, descriptions, and prices.

**Static assets** (`app/art_gallery/static/`) are organized into subdirectories: `static/css/` for stylesheets (though no custom CSS files were found), `static/js/` containing third-party JavaScript libraries (jquery-3.5.1.slim.min.js, popper.min.js, bootstrap.min.js), and `static/img/` with 20 image files for the gallery artwork. The reliance on CDN-style local copies of jQuery and Bootstrap (rather than actual CDN links) ensures functionality without external dependencies but introduces technical debt through potentially outdated library versions (jQuery 3.5.1 from June 2020 has known XSS CVEs).

**Build and deployment tooling** is minimal with no evidence of CI/CD pipelines, automated testing, linting, or security scanning. The Makefile exists but references an external `common.mk` that is not present in the repository, suggesting this is a partial codebase or that build tooling is managed externally. The Dockerfile uses a multi-command CMD that runs database migrations dynamically at container startup (`python3 manage.py makemigrations && python3 manage.py migrate && python3 manage.py runserver 0.0.0.0:80`), which is an anti-pattern for production as it can introduce schema changes in running environments.

**Code generation and frameworks**: The application uses Django's built-in code generation sparingly—there's evidence of Django's automatic migration system (`accounts/migrations/` directory exists per Django conventions, though migrations aren't included in the provided codebase), but no custom management commands, middleware, template tags, or advanced Django features. No code generation tools like Django REST Framework serializers, GraphQL schema generators, or API documentation generators are present.

**Testing infrastructure** is completely absent: no `tests.py` files, no `tests/` directories, no pytest configuration, no coverage tools, and no test fixtures. The `requirements.txt` contains only production dependencies with no test-specific libraries (pytest, pytest-django, factory-boy, faker). This absence of testing makes the security vulnerabilities particularly concerning as there's no automated verification of security properties or regression testing for vulnerability fixes.

**Security tooling gaps**: The codebase lacks modern security development tools including: no Bandit (Python security linter) configuration, no Safety/pip-audit for dependency vulnerability scanning, no pre-commit hooks for security checks, no SAST (Static Application Security Testing) integration, no secrets scanning to prevent credential commits, and no security-focused Django packages like django-security, django-ratelimit, or django-defender. The presence of beautifulsoup4 in requirements.txt but no usage in the codebase suggests dependency bloat and potential supply chain attack surface from unused libraries.

**Discoverability of security components** is hindered by the codebase's simplicity paradox: while the small size (319 Python LOC) makes the code easy to read, the absence of explicit security implementations means security researchers must understand what's *missing* rather than what's present. Critical security decisions are made through Django defaults rather than explicit configuration, requiring knowledge of Django 4.2.13's default behavior to understand the security posture. The middleware stack in settings.py provides the primary security indicator, but missing configurations (no LOGGING, no CACHES, no SESSION_* security settings) are harder to identify than present code. The hardcoded secrets in settings.py are discoverable through simple file reading, but the plaintext password in session storage requires tracing the multi-step registration flow across multiple view functions to understand the vulnerability.

**Organizational conventions** follow Django best practices for file naming (models.py, views.py, forms.py, urls.py) and URL routing (named routes like 'register_step1', 'register_step2'), making the codebase navigable for Django developers. However, security-specific conventions are absent: no security.py module for centralized security utilities, no validators.py for custom input validation, no permissions.py for access control logic, and no middleware/ directory for custom security middleware.

This organizational structure enables rapid initial understanding but obscures security weaknesses through absence rather than presence, requiring comprehensive code review to identify missing security controls, inadequate configurations, and dangerous patterns like the SSTI vulnerability that spans multiple files (session storage in views.py:14 → template injection in views.py:58 → template rendering in register_step3.html).

---

## 8. Critical File Paths

### Configuration Files
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/art_gallery/settings.py` - Django settings with hardcoded secrets, DEBUG=True, ALLOWED_HOSTS=['*'], database credentials, middleware configuration, password validators (lines 11, 14, 16, 65-74, 32-40, 76-89)
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/docker-compose.yml` - Docker Compose orchestration, service configuration, exposed ports, database credentials in health check (line 7)
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/Dockerfile` - Application container build, flag file creation (line 21), development server CMD (line 30), root user execution
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/mysql/Dockerfile` - Database container with root password environment variable (line 3)
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/.env` - Environment variables with CTF flag (line 1)

### Authentication & Authorization
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py` - All authentication logic, SSTI vulnerability (lines 56-58), plaintext password storage (line 15), flag exposure (lines 39, 51, 61), login view (lines 64-76), @login_required decorator (line 81)
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/models.py` - Custom Account model extending AbstractUser with is_premium and name fields (lines 5-9)
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/forms.py` - Form definitions with password min_length=10 (line 7), name max_length=100 vs model max_length=40 discrepancy (line 5)

### API & Routing
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/art_gallery/urls.py` - Root URL configuration, includes accounts URLs (lines 11-14)
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/urls.py` - Application URL patterns mapping all 8 accounts endpoints (lines 5-16)
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/art_gallery/wsgi.py` - WSGI application entry point

### Data Models & DB Interaction
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/models.py` - Account model with is_premium (line 8) and name (line 9) fields
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/art_gallery/settings.py` - Database configuration with hardcoded credentials (lines 65-74), AUTH_USER_MODEL setting (line 30)

### Dependency Manifests
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/requirements.txt` - Python dependencies including Django==4.2.13, mysqlclient==2.2.4, beautifulsoup4==4.12.3

### Sensitive Data & Secrets Handling
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/art_gallery/settings.py` - SECRET_KEY hardcoded (line 11), database password (line 71)
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/.env` - Flag storage (line 1)
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py` - Plaintext password in session (line 15), flag file read (line 39)

### Middleware & Input Validation
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/art_gallery/settings.py` - Middleware stack including SecurityMiddleware, CsrfViewMiddleware, XFrameOptionsMiddleware (lines 32-40)
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/forms.py` - Django forms providing input validation (lines 4-14)

### Logging & Monitoring
- **No logging configuration files exist** - critical gap in security monitoring

### Infrastructure & Deployment
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/docker-compose.yml` - Service orchestration, database and application containers, health checks (lines 7, 24)
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/Dockerfile` - Application container with root user, development server, flag creation
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/wait-for-it.sh` - Service dependency script for database readiness
- **No Nginx, Kubernetes, or infrastructure-as-code files** - no reverse proxy or orchestration configuration for security headers

### CTF Flag Storage
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/.env` - Flag environment variable (line 1): `FLAG="flag{98d2361b-f883-4daa-93f7-cb5c91a32c69}"`
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/Dockerfile` - Flag written to `/flag` file (line 21): `RUN echo -n $FLAG > /flag`
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py` - Flag read operation (line 39): `flag = open('/flag').read()`, flag exposure in templates (lines 51, 61)

### Templates (XSS/SSTI Vulnerability Context)
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/templates/accounts/register_step3.html` - SSTI vulnerability target template with ACCOUNTNAME placeholder (line 37), JavaScript context XSS sink
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/templates/accounts/gallery.html` - Stored XSS potential with user.name display (line 44)
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/templates/base.html` - Base template with jQuery 3.5.1 inclusion (line 38-40)

### Static Assets (Third-Party Library Vulnerabilities)
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/static/js/jquery-3.5.1.slim.min.js` - jQuery with known CVE-2020-11022, CVE-2020-11023
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/static/js/bootstrap.min.js` - Bootstrap JavaScript

---

## 9. XSS Sinks and Render Contexts

**Network Surface Focus:** This analysis covers only XSS sinks in network-accessible web pages. All identified sinks are reachable through HTTP endpoints exposed by the Django development server on port 80.

### Critical Finding: Server-Side Template Injection (SSTI) - Remote Code Execution

**Vulnerability Classification:** Server-Side Template Injection enabling XSS and RCE

**Location:**
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py`
- **Lines:** 56-58
- **Endpoint:** `/accounts/register/step3/` (POST)
- **Function:** `register_step3`

**Vulnerable Code:**
```python
engine = engines["django"]
template_str = open('accounts/templates/accounts/register_step3.html','r').read()
template = engine.from_string(template_str.replace('ACCOUNTNAME', request.session['name']))
```

**Sink Description:** This is a Server-Side Template Injection vulnerability where user-controlled input (`request.session['name']`) is directly interpolated into a template string via Python's `str.replace()` method before being compiled by Django's template engine using `from_string()`. This bypasses Django's normal template security because the user input becomes part of the template **syntax** rather than template **data**.

**Render Context:** Django template syntax execution context - the most dangerous render context as it allows arbitrary Python code execution through Django's template language. The injected code executes on the server with the privileges of the Django application (root user in the Docker container).

**User-Controllable Variable:**
- **Source:** Registration form at `/accounts/register/step1/`
- **Form Field:** `name` (CharField with max_length=100 in form, max_length=40 in model)
- **Storage:** `request.session['name']` (set at views.py:14)
- **Validation:** None for template syntax - accepts any characters including `{{`, `}}`, `{%`, `%}`

**Attack Vectors:**

1. **Flag Exfiltration (Trivial):**
   - Payload: `{{ flag }}`
   - Steps: Register with name=`{{ flag }}` → complete step 2 → access step 3
   - Result: Flag value rendered in the page: `flag{98d2361b-f883-4daa-93f7-cb5c91a32c69}`
   - Context: The flag is explicitly passed to the template at line 61: `template.render({'flag':flag}, request)`

2. **Configuration Disclosure:**
   - Payload: `{{ settings.SECRET_KEY }}`
   - Result: Exposes `django-insecure-63gtpxui8h_3$08c91_a@0(5*=ns2)dzct*5q97t+$))kq^!(s'`
   - Payload: `{{ settings.DATABASES }}`
   - Result: Exposes database credentials

3. **File System Access:**
   - Payload: `{% load static %}{% get_static_prefix as static %}{{ static }}`
   - Result: Reveals static file paths
   - Advanced: With sufficient Django version knowledge, can potentially read arbitrary files

4. **Remote Code Execution (Advanced):**
   - Django templates are sandboxed but not designed as security boundaries
   - Payload complexity depends on Django version and available template tags
   - Example research: Django template filter chaining for code execution

**Exploitability:** **CRITICAL (CVSS 9.9)**
- No authentication required
- Single HTTP request exploit
- Direct code execution path
- Flag accessible without complex exploitation
- Works reliably every time

**Related Sink - JavaScript Context XSS:**

**Location:**
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/templates/accounts/register_step3.html`
- **Line:** 37
- **Endpoint:** `/accounts/register/step3/`

**Vulnerable Code:**
```html
<script>alert("Hello ACCOUNTNAME. Just Now up to 50% OFF ")</script>
```

**Combined Vulnerability:** When the SSTI vulnerability in views.py:58 replaces `ACCOUNTNAME` with `request.session['name']`, the result is injected into this JavaScript context in the template. This creates a reflected XSS vulnerability as a consequence of the SSTI.

**Render Context:** JavaScript string literal inside `<script>` tag - requires breaking out of the string context.

**Attack Vector:**
- **Payload:** `"); alert(document.cookie); //`
- **Resulting JavaScript:** `alert("Hello "); alert(document.cookie); //. Just Now up to 50% OFF ")`
- **Impact:** Cookie theft, session hijacking, arbitrary JavaScript execution in user's browser

**Exploitability:** **HIGH (CVSS 8.1)**
- Simpler to exploit than full SSTI
- Reliable XSS with session stealing capability
- Works in victim's browser context

---

### HTML Body Context Sinks

**Sink #1: User Name Display in Gallery**

**Location:**
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/templates/accounts/gallery.html`
- **Line:** 44
- **Endpoint:** `/` (GET) - gallery view
- **Function:** `gallery_view` (views.py:85-100)

**Vulnerable Code:**
```html
<h3 class="my-4 text-center">Welcome, {{ user.name }}!</h2>
```

**Sink Description:** Stored XSS potential where `user.name` is rendered in an HTML context. The `name` field is user-controlled during registration and persists in the database, making this a stored (persistent) XSS rather than reflected.

**Render Context:** HTML body context within `<h3>` heading tag. Django's automatic HTML escaping **should** prevent XSS by converting `<`, `>`, `&`, `"`, `'` to HTML entities.

**User-Controllable Variable:**
- **Source:** `request.session['name']` from registration → `Account.name` in database
- **Database Field:** `models.CharField(unique=True, max_length=40)`
- **Current Protection:** Django auto-escaping (enabled by default)

**Exploitability Assessment:** **MEDIUM (CVSS 6.1)**

**Why exploitable despite auto-escaping:**
1. **SSTI Bypass:** The SSTI vulnerability at views.py:58 can be used to bypass auto-escaping by injecting `|safe` filter or `{% autoescape off %}` during registration
2. **Developer Error Risk:** If a developer later adds `{{ user.name|safe }}` or disables auto-escaping for styling reasons, XSS becomes trivial
3. **Secondary Attack Chain:** After exploiting SSTI to create account, that account's name appears unescaped to other users

**Proof of Concept (if auto-escaping bypassed):**
- **Payload:** `<img src=x onerror=alert(document.cookie)>`
- **Rendered HTML:** `<h3 class="my-4 text-center">Welcome, <img src=x onerror=alert(document.cookie)>!</h3>`
- **Impact:** Persistent XSS affecting all users who view the gallery while the attacker is logged in

**Current Status:** Protected by Django's default auto-escaping, but represents a security boundary that could be accidentally removed.

---

### JavaScript Context Sinks

**Sink #2: jQuery and Bootstrap Library Versions**

**Location:**
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/templates/base.html`
- **Lines:** 38-40
- **Endpoint:** All pages (base template included everywhere)

**Vulnerable Code:**
```html
<script src="/static/js/jquery-3.5.1.slim.min.js"></script>
<script src="/static/js/popper.min.js"></script>
<script src="/static/js/bootstrap.min.js"></script>
```

**Sink Description:** Third-party JavaScript libraries with known vulnerabilities. jQuery 3.5.1 (released June 2020) is affected by CVE-2020-11022 and CVE-2020-11023 (prototype pollution and XSS in htmlPrefilter).

**Render Context:** Global JavaScript execution context - these libraries are loaded on every page and can be exploited if user input reaches jQuery DOM manipulation methods.

**Exploitability Assessment:** **LOW (CVSS 4.3)**

**Why low severity in this application:**
1. **No Custom JavaScript:** No application-specific JavaScript code uses jQuery with user input
2. **No DOM Manipulation:** No `$()` selector usage with user-controllable data
3. **Library-Only Risk:** Vulnerabilities require specific usage patterns not present in the application

**Potential Attack Vector (if JavaScript were added):**
- **Vulnerable Pattern:** `$('<div>' + userInput + '</div>')`
- **jQuery CVE-2020-11022:** Allows XSS via specially crafted HTML strings
- **Current Risk:** None, as no such patterns exist in the codebase

**Recommendation:** Update to jQuery 3.6.0+ and Bootstrap 4.6.0+ for defense-in-depth even though not currently exploitable.

---

### Template Injection Sinks Summary

**Primary SSTI Sink (CRITICAL):**
- **File Path:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py:56-58`
- **Sink Type:** Django `from_string()` with user input
- **User Variable:** `request.session['name']`
- **Render Context:** Server-side Django template syntax execution
- **Exploitability:** Direct flag access via `{{ flag }}`, configuration disclosure, potential RCE
- **CVSS Score:** 9.9 (Critical)

**JavaScript Context XSS (HIGH):**
- **File Path:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/templates/accounts/register_step3.html:37`
- **Sink Type:** String interpolation in `<script>` tag
- **User Variable:** `request.session['name']` → ACCOUNTNAME placeholder
- **Render Context:** JavaScript string literal
- **Exploitability:** Cookie theft, session hijacking via `"); alert(document.cookie); //`
- **CVSS Score:** 8.1 (High)

**HTML Context Stored XSS (MEDIUM - Mitigated):**
- **File Path:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/templates/accounts/gallery.html:44`
- **Sink Type:** User name display in HTML
- **User Variable:** `user.name` from database
- **Render Context:** HTML body within `<h3>` tag
- **Current Protection:** Django auto-escaping
- **Exploitability:** Requires auto-escaping bypass via SSTI or developer error
- **CVSS Score:** 6.1 (Medium)

---

### SQL Injection Analysis

**Finding:** No SQL injection sinks detected in network-accessible components.

**Methodology:** Searched for dangerous query construction patterns:
- `cursor.execute()` - not found
- `.raw()` method - not found
- `.extra()` method - not found
- String concatenation in query building - not found
- `f-strings` or `%` formatting in database operations - not found

**Evidence of Safe Practices:**
- All database operations use Django ORM: `Account.objects.create()`, `authenticate()`, etc.
- No raw SQL in codebase
- File: `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py` - all DB operations via ORM
- File: `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/models.py` - model definitions only

**Conclusion:** Django ORM provides parameterized queries, making SQL injection not exploitable in this application's current codebase.

---

### Command Injection Analysis

**Finding:** No command injection sinks detected in network-accessible components.

**Methodology:** Searched for dangerous system execution patterns:
- `os.system()` - not found
- `subprocess.Popen()`, `subprocess.call()`, `subprocess.run()` - not found
- `eval()` or `exec()` with user input - not found (SSTI uses template engine, not eval)
- `__import__()` with user data - not found
- Shell command execution - not found

**File Operations (Safe):**
- Line 39: `open('/flag').read()` - hardcoded path, no user input
- Line 57: `open('accounts/templates/accounts/register_step3.html','r').read()` - hardcoded path

**Conclusion:** No command injection vulnerabilities in network-accessible endpoints.

---

### DOM-Based XSS Analysis

**Finding:** No DOM-based XSS sinks detected.

**Methodology:** Analyzed all JavaScript files:
- **No custom JavaScript files present** - only third-party libraries (jQuery, Bootstrap, Popper)
- No `innerHTML`, `outerHTML`, `document.write()` usage with user input
- No `eval()` or `Function()` constructor usage
- No `location.href` manipulation with user data
- No client-side template rendering frameworks (React, Vue, Angular)

**Conclusion:** No DOM-based XSS attack surface exists in the current application.

---

### XSS Summary Statistics

| Sink Category | Count | Severity | Exploitable |
|---------------|-------|----------|-------------|
| **Server-Side Template Injection** | 1 | CRITICAL | Yes - Direct flag access |
| **JavaScript Context XSS** | 1 | HIGH | Yes - Session hijacking |
| **HTML Context XSS (Stored)** | 1 | MEDIUM | No (auto-escaping) |
| **SQL Injection** | 0 | N/A | N/A |
| **Command Injection** | 0 | N/A | N/A |
| **DOM-Based XSS** | 0 | N/A | N/A |
| **Third-Party Library CVEs** | 1 | LOW | No (no usage pattern) |

**Attack Priority for Penetration Testing:**
1. **SSTI Vulnerability** (views.py:56-58) - Exploit with payload `{{ flag }}` to retrieve flag
2. **JavaScript XSS** (register_step3.html:37) - Exploit with payload `"); alert(document.cookie); //`
3. **Stored XSS** (gallery.html:44) - Test auto-escaping bypass via SSTI

---

## 10. SSRF Sinks

**Network Surface Focus:** This analysis covers only SSRF sinks in network-accessible web pages and publicly facing components. Local-only utilities, build scripts, developer tools, and CLI applications have been excluded from scope.

**Finding:** **No SSRF (Server-Side Request Forgery) sinks detected in network-accessible components.**

---

### HTTP(S) Clients Analysis

**Methodology:** Searched for HTTP client library usage in all Python files within the network-accessible application scope.

**Libraries Searched:**
- `requests` library (requests.get, requests.post, requests.request) - **NOT FOUND**
- `urllib`, `urllib2`, `urllib3` (urlopen, urlretrieve) - **NOT FOUND**
- `httplib`, `http.client` - **NOT FOUND**
- `httpx`, `aiohttp`, `tornado.httpclient` - **NOT FOUND**
- `curl` via subprocess - **NOT FOUND**

**Evidence:**
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/requirements.txt`
- **Analysis:** No HTTP client libraries in dependencies. Only Django, mysqlclient, bootstrap, and beautifulsoup4 present. BeautifulSoup is for HTML parsing, not HTTP requests.
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py`
- **Imports:** `from django.shortcuts import render, redirect`, `from django.contrib.auth import authenticate, login as auth_login, logout`, `from django.contrib.auth.decorators import login_required`, `from django.template import engines`, `from django.http import HttpResponse`, `from os import getenv`, `from .models import Account`, `from .forms import Step1Form, Step2Form, Step3Form`, `from django.contrib.auth.forms import AuthenticationForm`
- **Analysis:** No HTTP client imports detected

**Conclusion:** Application does not make any outbound HTTP/HTTPS requests from network-accessible endpoints.

---

### Raw Sockets & Connect APIs Analysis

**Methodology:** Searched for low-level network connection APIs.

**Libraries Searched:**
- `socket.socket`, `socket.connect` - **NOT FOUND**
- `telnetlib` - **NOT FOUND**
- `ftplib` - **NOT FOUND**
- `smtplib` - **NOT FOUND** (no email sending functionality)
- `ssl.wrap_socket`, `ssl.SSLContext` - **NOT FOUND**

**Evidence:**
- No socket programming in views.py, models.py, or any application code
- Database connections use Django ORM with mysqlclient driver (internal to MySQL connection, not user-controllable)

**Conclusion:** No raw socket operations accessible via network endpoints.

---

### URL Openers & File Includes Analysis

**Methodology:** Searched for file operations that could accept URLs or user-controlled paths.

**File Operations Found:**
1. **Line 39 in views.py:** `flag = open('/flag').read()`
   - **Path:** Hardcoded `/flag` - NO user input
   - **Context:** CTF flag reading in register_step3 view
   - **SSRF Risk:** None - static file path

2. **Line 57 in views.py:** `template_str = open('accounts/templates/accounts/register_step3.html','r').read()`
   - **Path:** Hardcoded template path - NO user input
   - **Context:** Template file reading for SSTI vulnerability
   - **SSRF Risk:** None - static file path
   - **Note:** While this is part of the SSTI vulnerability, the file path itself is not user-controllable

**Libraries Searched:**
- `urllib.urlopen()` - **NOT FOUND**
- `urllib.request.urlopen()` - **NOT FOUND**
- `codecs.open()` with URLs - **NOT FOUND**
- `requests.get().content` for file downloads - **NOT FOUND**

**Dynamic Import Analysis:**
- No `__import__()` with user input
- No `importlib.import_module()` with user data
- No dynamic module loading

**Conclusion:** All file operations use hardcoded paths. No URL-based file loading mechanisms.

---

### Redirect & "Next URL" Handlers Analysis

**Methodology:** Analyzed all redirect operations for user-controllable destination parameters.

**Redirect Locations in views.py:**

| Line | Function | Redirect Target | User-Controllable? |
|------|----------|-----------------|-------------------|
| 17 | `register_step1` | `redirect('register_step2')` | **NO** - Named route |
| 24 | `register_step2` | `redirect('register_step1')` | **NO** - Named route |
| 30 | `register_step2` | `redirect('register_step3')` | **NO** - Named route |
| 37 | `register_step3` | `redirect('register_step1')` | **NO** - Named route |
| 60 | `register_step3` | `redirect('register_step1')` | **NO** - Named route |
| 73 | `login_view` | `redirect('home')` | **NO** - Named route |
| 79 | `home_view` | `redirect('/')` | **NO** - Hardcoded path |
| 104 | `logout_view` | `redirect('/')` | **NO** - Hardcoded path |

**Parameter Analysis:**
- **No "next" parameter:** Login view (line 64-76) doesn't check for `request.GET.get('next')` or `request.POST.get('next')`
- **No "return_url" parameter:** No redirect destination parameters accepted in any view
- **No "continue" or "redirect_to" parameters:** All redirects use hardcoded targets
- **No URL validation functions:** No code validates external URLs because none are accepted

**Django's Built-in Redirect Safety:**
- All `redirect()` calls use Django's named URL pattern resolution
- Named routes (`'register_step2'`, `'home'`, etc.) defined in urls.py are inherently safe
- No user input reaches `redirect()` function

**Conclusion:** No open redirect vulnerabilities. All redirect destinations are hardcoded or use named routes.

---

### Webhook/Callback Handlers Analysis

**Methodology:** Searched for webhook notification, callback verification, and event delivery functionality.

**Searched Patterns:**
- "webhook" in code - **NOT FOUND**
- "callback" in code - **NOT FOUND**
- "notify" or "notification" endpoints - **NOT FOUND**
- Outbound HTTP POST requests - **NOT FOUND**
- Event delivery systems - **NOT FOUND**
- Payment gateway webhooks (Stripe, PayPal) - **NOT FOUND**

**Endpoint Analysis:**
- No `/webhook/` or `/callback/` URLs in urls.py
- No view functions accepting callback URLs as parameters
- No background task processing (Celery, RQ) for async webhooks

**Conclusion:** No webhook or callback functionality exists in the application.

---

### External API Integrations Analysis

**Methodology:** Searched for third-party service integrations that might make outbound requests.

**Searched Services:**
- **Payment Gateways:** No Stripe, PayPal, Square integration
- **Authentication Providers:** No OAuth, SAML, LDAP (confirmed in Section 3)
- **Email Services:** No SendGrid, Mailgun, AWS SES, SMTP configuration
- **Cloud Storage:** No S3, Azure Blob, GCS integration
- **Analytics:** No Google Analytics API, Mixpanel, Segment
- **Monitoring:** No Sentry, Datadog, New Relic API calls
- **Social Media APIs:** No Twitter, Facebook, Instagram integration
- **Geocoding/Maps:** No Google Maps API, Mapbox
- **SMS/Phone:** No Twilio, Nexmo integration

**Evidence:**
- **requirements.txt:** Only Django, mysqlclient, bootstrap, beautifulsoup4 - no third-party API client libraries
- **settings.py:** No API keys, no third-party service configuration sections
- **views.py:** No API client instantiation or usage

**Conclusion:** Application is entirely self-contained with no external API integrations.

---

### Media Processors & Document Generators Analysis

**Methodology:** Searched for media processing libraries that could fetch external resources.

**Libraries Searched:**
- **Image Processing:** No Pillow, ImageMagick, GraphicsMagick
- **PDF Generation:** No wkhtmltopdf, WeasyPrint, ReportLab, Puppeteer
- **Video Processing:** No FFmpeg, OpenCV integration
- **Document Conversion:** No Pandoc, LibreOffice headless usage

**File Upload Analysis:**
- **No file upload handlers:** No `request.FILES` usage in views.py
- **No FileField or ImageField:** models.py contains no file storage fields
- **Static images only:** Gallery images are pre-loaded static files in `/static/img/`

**Conclusion:** No media processing functionality that could be exploited for SSRF.

---

### Link Preview & Unfurlers Analysis

**Methodology:** Searched for URL metadata extraction and link preview generation.

**Searched Patterns:**
- **oEmbed integration:** NOT FOUND
- **OpenGraph metadata fetching:** NOT FOUND
- **Twitter Card generation:** NOT FOUND
- **URL preview functionality:** NOT FOUND
- **BeautifulSoup usage:** Library present in requirements.txt but **NOT USED** in any code

**Evidence:**
- **File:** `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py`
- **Analysis:** No `import bs4` or `from bs4 import BeautifulSoup` despite beautifulsoup4 being in requirements.txt
- **Conclusion:** Dependency bloat - library installed but unused

**Conclusion:** No link preview or URL unfurling functionality.

---

### SSO/OIDC Discovery & JWKS Fetchers Analysis

**Methodology:** Searched for OAuth, OIDC, and federated authentication implementations.

**Searched Patterns:**
- **OpenID Connect discovery:** No `.well-known/openid-configuration` fetching
- **JWKS fetching:** No JSON Web Key Set retrieval from external providers
- **OAuth metadata:** No authorization server metadata fetching
- **SAML metadata:** No SAML IdP metadata retrieval
- **JWT libraries:** No PyJWT, python-jose, or jwcrypto in requirements.txt

**Evidence:**
- **Confirmed in Section 3:** No OAuth/OIDC implementation exists
- **No third-party auth libraries:** requirements.txt contains only Django's built-in auth

**Conclusion:** No SSO/OIDC/SAML implementation, therefore no JWKS or metadata fetching.

---

### Importers & Data Loaders Analysis

**Methodology:** Searched for data import and remote file loading functionality.

**Searched Patterns:**
- **"Import from URL" functionality:** NOT FOUND
- **CSV/JSON/XML remote loaders:** NOT FOUND
- **RSS/Atom feed readers:** NOT FOUND
- **API data synchronization:** NOT FOUND
- **Configuration fetching:** All config in settings.py, no remote config

**Data Flow Analysis:**
- **Data Input:** Only via HTML forms (registration, login)
- **Data Storage:** MySQL database only
- **No data import endpoints:** No `/import/`, `/upload/`, `/sync/` URLs
- **No file parsing:** No CSV, JSON, or XML parsing of uploaded files

**Conclusion:** No data import or remote loading functionality.

---

### Cloud Metadata Helpers Analysis

**Methodology:** Searched for cloud instance metadata access patterns.

**Searched Patterns:**
- **AWS metadata:** No `http://169.254.169.254/` access
- **GCP metadata:** No `http://metadata.google.internal/` access
- **Azure metadata:** No `http://169.254.169.254/metadata/` access
- **Cloud SDK usage:** No boto3, google-cloud-*, azure-sdk-for-python in requirements.txt
- **Container orchestration API:** No Kubernetes API client usage

**Evidence:**
- **Deployment:** Docker Compose only (not ECS, EKS, GKE, AKS)
- **No cloud provider libraries:** requirements.txt contains no cloud SDKs
- **No metadata access:** No HTTP requests to 169.254.169.254 or metadata endpoints

**Conclusion:** No cloud metadata access patterns exist.

---

### SSRF Summary & Conclusion

**Comprehensive Finding:** **ZERO SSRF sinks detected in network-accessible components.**

**Reasoning:**
1. **No HTTP Client Libraries:** Application doesn't include or use requests, urllib, httpx, or any HTTP client
2. **No Outbound Connections:** Application makes no external HTTP/HTTPS requests
3. **Hardcoded Redirects:** All redirect destinations use named routes or hardcoded paths
4. **No Webhooks:** No callback URL functionality
5. **No External APIs:** No third-party service integrations
6. **No Media Processing:** No image/PDF generation from URLs
7. **No Link Previews:** No URL metadata fetching
8. **No SSO/OIDC:** No external identity provider integration
9. **No Data Import:** No remote file loading functionality
10. **No Cloud Metadata:** No cloud provider metadata access

**Files Analyzed:**
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/views.py` - All endpoint logic
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/requirements.txt` - Dependency analysis
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/accounts/models.py` - Data model analysis
- `/Users/khaushik/keygraph/pentest/shannon/repos/XBEN-025-24/app/art_gallery/art_gallery/settings.py` - Configuration analysis

**Attack Surface for SSRF:** **None**

The application is entirely inward-facing with respect to network requests - it accepts inbound HTTP connections but makes no outbound connections based on user input or otherwise. This significantly reduces the attack surface for SSRF-class vulnerabilities.

**Note for Penetration Testers:** While SSRF testing is typically a critical part of web application penetration testing, this application's architecture makes SSRF attacks non-viable. Testing efforts should focus on the identified SSTI vulnerability (views.py:56-58) and XSS sinks instead.

---

**END OF CODE_ANALYSIS DELIVERABLE**