# Statt rohem SQL: SELECT * FROM books WHERE author_id = 1
books = Book.objects.filter(author_id=1)

# Bücher mit Autoren verknüpfen, aber nur aktive Autoren
Book.objects.annotate(
    active_author=FilteredRelation('author', condition=Q(author__is_active=True))
).select_related('active_author')

# Benutzer möchte nach verschiedenen Kriterien suchen
search_field = request.POST.get('field_name')  # Benutzereingabe: "title", "author", etc.

# Dynamische Felderstellung mittels **kwargs
queryset.annotate(**{
    search_field: FilteredRelation('some_relation')
})

# So sieht angreifbarer Code aus:
user_input = request.POST.get('search_field')  # Angreifer kontrolliert dies

# Die Schwachstelle liegt hier – Benutzereingabe wird zum SQL-Spaltenalias
queryset.annotate(**{
    user_input: FilteredRelation("author")  # ❌ GEFÄHRLICH
})

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

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

# views.py – Typisches angreifbares Muster
def search_books(request):
    search_field = request.POST.get('search_by')  # "author", "title", "category"
    search_value = request.POST.get('search_value')
    
    # Entwickler denkt, das sei sicher – IST ES NICHT!
    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())})

# Angreifer sendet diese POST-Anfrage:
curl -X POST http://example.com/search/ \
  -d "search_by=author'; DROP TABLE auth_user; --" \
  -d "search_value=anything"

# NIEMALS SO MACHEN – Direkte Benutzereingabe als Dictionary-Schlüssel
user_field = request.POST.get('field')
queryset.annotate(**{
    user_field: FilteredRelation('relation')  # SQL-Injection!
})

# SICHER – Whitelist-Validierung verwenden
ALLOWED_FIELDS = ['author', 'category', 'publisher']

user_field = request.POST.get('field')
if user_field not in ALLOWED_FIELDS:
    raise ValidationError("Ungültiges Feld")

queryset.annotate(**{
    user_field: FilteredRelation('relation')  # Jetzt sicher
})

# SICHER – Statische Feldnamen verwenden
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'))

-- Sensible Daten extrahieren
'; SELECT username, password FROM auth_user; --

-- Daten ändern
'; UPDATE auth_user SET is_superuser = true WHERE id = 1; --

-- Systembefehle ausführen (PostgreSQL mit entsprechenden Erweiterungen)
'; 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"Feld '{field_name}' nicht erlaubt")
    
    return queryset.annotate(**{
        field_name: FilteredRelation('relation')
    })

# Statt dynamischer Feldnamen bedingte Logik verwenden
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("Ungültiger Suchtyp")

# Die angreifbare Django-Anwendung ausführen
docker-compose up

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