Path Traversal in Django with Cockroachdb

Path Traversal occurs when an application uses attacker-controlled data to build file system paths, allowing access to files outside the intended directory. In Django with Cockroachdb, the database itself does not directly cause path traversal, but Django code that mishandles user input to construct file paths — for example when storing or retrieving files whose metadata or paths are persisted in Cockroachdb — can expose the vulnerability. If file paths or user-supplied identifiers are stored in Cockroachdb and later used to read files without strict validation, an attacker can manipulate these values to traverse directories (e.g., using sequences like ../../../) and access sensitive files such as application source code, configuration, or credentials.

Consider a Django view that saves an uploaded file and records its path in Cockroachdb using Django ORM. If the file path is later retrieved from Cockroachdb and passed to filesystem operations without sanitization, a malicious actor can exploit insecure direct object references or insufficient path sanitization to reach arbitrary files. Cockroachdb, being a PostgreSQL-compatible database, stores the path strings exactly as provided by Django; it does not validate or sanitize them. Therefore, if Django writes user-influenced paths into Cockroachdb, the database becomes a persistence layer for attacker-controlled path data that can be used in subsequent traversal attempts.

Common patterns that increase risk include dynamically building file paths with string concatenation, using user input for directory names, or failing to resolve paths to a canonical absolute base directory. Since Django’s FileField and ImageField store paths as strings in Cockroachdb, developers must ensure these values are never directly used in filesystem operations. Even when using Django’s default_storage, improper configuration or custom storage backends can inadvertently introduce traversal risks when combined with unchecked user input.

Remediation focuses on strict input validation, path normalization, and avoiding direct use of stored paths in filesystem operations. Always resolve user-supplied paths against a secure base directory and use Django’s built-in utilities to handle file paths safely. Below are concrete examples using Cockroachdb as the backend with Django ORM.

1. Secure file upload with path validation

Use Django’s FileField with a custom upload path function that normalizes and restricts file locations. Do not trust any user-controlled component in the path.

import os
from django.core.files.storage import FileSystemStorage
from django.db import models

class SecureFileStorage(FileSystemStorage):
    def get_valid_name(self, name):
        # Remove path components and only keep the base filename
        return os.path.basename(name)

    def get_available_name(self, name, max_length=None):
        # Ensure deterministic behavior and avoid directory traversal
        name = self.get_valid_name(name)
        return super().get_available_name(name, max_length=max_length)

storage = SecureFileStorage(location='/srv/app/uploads')

class Document(models.Model):
    file = models.FileField(upload_to='documents/', storage=storage)
    # Other fields persisted in Cockroachdb
    title = models.CharField(max_length=255)

The SecureFileStorage ensures that filenames are stripped of directory components before being stored or written. The path stored in Cockroachdb will be a clean relative path under documents/, eliminating traversal risks during retrieval.

2. Safe file retrieval and serving

When serving files, always resolve the final path against a predefined base directory and avoid using raw values from Cockroachdb for filesystem access.

import os
from django.http import HttpResponse
from django.conf import settings
from .models import Document

def serve_document(request, document_id):
    doc = Document.objects.get(id=document_id)
    # Build path using storage backend, not raw string from Cockroachdb
    storage = doc.file.storage
    full_path = storage.path(doc.file.name)
    # Ensure the resolved path is within the allowed directory
    if not full_path.startswith(os.path.abspath(settings.MEDIA_ROOT)):
        raise SuspiciousOperation('Path traversal attempt detected')
    with open(full_path, 'rb') as f:
        content = f.read()
    return HttpResponse(content, content_type='application/octet-stream')

This pattern ensures that even if Cockroachdb stores a potentially malicious path, the resolved absolute path is verified to remain within MEDIA_ROOT. The check prevents directory traversal regardless of what was originally stored.

3. Using Django’s os.path utilities for user input

Normalize and validate any user input that may influence paths before it reaches Cockroachdb. Use os.path.normpath and reject paths containing traversal sequences.

import os
from django.core.exceptions import ValidationError

def validate_safe_path(path):
    # Normalize and ensure no leading directory traversal
    normalized = os.path.normpath(path)
    if normalized.startswith('..') or os.path.isabs(normalized):
        raise ValidationError('Invalid path: traversal not allowed')
    return normalized

# Example usage in a form or serializer
clean_path = validate_safe_path(user_supplied_path)
# Proceed to store clean_path in Cockroachdb via Django model

By normalizing before persistence, you ensure that Cockroachdb does not store values that could later be used to compromise the filesystem.