SQL Injection in Django QuerySet.order_by

This repository is not a standalone exploit against a remote third-party target; it is an intentionally vulnerable Django/PostgreSQL lab application designed to demonstrate and exercise a family of Django ORM SQL injection and query-manipulation issues. The core logic is in app/vulnapp/views.py, where multiple HTTP GET parameters are passed directly into ORM constructs that expect SQL identifiers or special keyword arguments rather than safely parameterized values. The app exposes separate routes for each candidate sink, including order_by(), annotate alias expansion, Trunc/Extract kind selection, values()/values_list() field selection, JSONField key transforms, explain() option names, FilteredRelation aliasing, dates()/datetimes() kind, distinct(*fields), in_bulk(field_name=), and unsafe filter(**request.GET.dict()) handling. Repository structure is compact: Dockerfile and docker-compose.yml build a reproducible environment with Django 3.2.4 and PostgreSQL; entrypoint.sh performs migrations, seeds the database, and launches the server; app/vulnapp/models.py defines Category and Person models; app/vulnapp/management/commands/seed.py populates sample records and creates a default admin user; app/vulnproj/urls.py maps the vulnerable routes; and app/vulnproj/settings.py configures PostgreSQL connectivity and permissive ALLOWED_HOSTS. The seeded data and JSON responses are intentionally designed to provide row content and differential behavior useful for testing boolean/error-based or data-extraction-oriented SQLi techniques. Main exploit capabilities provided by the application include: exposing multiple web-reachable SQLi-like primitives in Django ORM identifier contexts; enabling response-based calibration through returned rows and counts; demonstrating access-control impact via the /scoped/ endpoint where attacker-controlled _connector can weaken a pinned filter; and supporting extraction experiments via /list/ where a plain listing avoids count()-related column-count constraints. Because the repository is a vulnerable target/lab rather than a packaged offensive exploit script, there is no embedded shell payload or callback infrastructure, but it is clearly exploit-oriented and operational as a testbed for HTTP-based exploitation of the listed CVEs and related patterns.

This repository is a deliberately vulnerable Django-based CTF lab centered on CVE-2021-35042, plus a working exploit script. The application code lives under ctf_blog/ and blog/, with templates/, static/, Dockerfile, and docker-compose.yml providing a runnable lab environment backed by MySQL. The vulnerable logic is in blog/views.py: posts_list() reads request.GET['sort'] and passes it directly into QuerySet.order_by(sort_param), explicitly documenting the intentional CVE-2021-35042 condition for Django 3.2.4. The vulnerable route is exposed at /posts/ in blog/urls.py, and the template templates/posts_list.html renders sql_error back to the client, which is essential for exploitation. The main exploit capability is implemented in exploit_dump.py, a Python requests-based error-based SQLi dumper. It targets http://localhost:8000/posts/ and injects into the sort parameter using a prefix of blog_post.id+ followed by a MySQL extractvalue() payload. Returned XPATH error text is parsed from the HTML response and used to exfiltrate arbitrary SQL query results in chunks. The script supports database fingerprinting (version, current DB, current user), table enumeration via information_schema, column enumeration, and row dumping for selected tables. It prioritizes sensitive application tables such as blog_post, blog_comment, and user-related tables, making it a practical operational exploit rather than a mere detector. The repository also includes sqlmap_guide.sh, which documents equivalent exploitation using sqlmap against the same /posts/ endpoint with the sort parameter and MySQL-specific settings. Supporting files such as seed_data.py and init.sql populate the lab with realistic content, users, and a private post containing a secret_flag value intended as the exfiltration target. Overall, this is a self-contained vulnerable training environment with an included exploit and exploitation guide, designed to demonstrate and weaponize Django ORM order_by() SQL injection against a MySQL-backed application.

This repository provides a proof-of-concept (POC) exploit environment for CVE-2021-35042, a SQL injection vulnerability in Django applications that use unsanitized user input in QuerySet.order_by(). The repository includes a minimal Django project (cve202135042) with a vulnerable /users/ endpoint, which takes the 'order_by' GET parameter directly from user input and passes it to the ORM without sanitization. This allows an attacker to inject arbitrary SQL via the 'order_by' parameter. The environment is containerized using Docker and docker-compose, with a PostgreSQL backend. The README provides setup instructions and highlights the vulnerable endpoint. The main exploit capability is SQL injection via a network-accessible HTTP endpoint. No weaponized payload is included; the repository is intended for demonstration and testing of the vulnerability.