Task 2 : Technical Details

Django's Object-Relational Mapping (ORM) layer allows developers to build database queries using familiar Python syntax instead of raw SQL. Queries are usually constructed with methods such as filter(), exclude(), and get(), which accept keyword arguments (**kwargs) to define conditions. For example, calling User.objects.filter(username='admin') generates an SQL statement that searches for a user named admin.

This flexibility can become dangerous when untrusted input is expanded directly into these ORM calls. Some developers take request parameters from the client, convert them into a dictionary, and pass them into the ORM. For example, User.objects.filter(**request.GET.dict()). While this shortcut may seem convenient, it allows attackers to supply not only legitimate field names but also Django's internal query arguments.

Before the security patch, two of these internal parameters (_connector and _negated) were not properly restricted.

• The _connector parameter defines how multiple query conditions are joined, such as AND or OR. By manipulating this, an attacker could change the logical relationship between clauses. For example, turning a strict login check into an OR condition that always returns true.

• The _negated parameter inverts a query, allowing an attacker to flip a filter's meaning. For example, a query meant to return non-admin users could be inverted to return only admin users.

When these internal parameters are supplied by user input, the ORM no longer enforces the intended query logic. As a result, attackers can craft malicious requests that bypass authentication, extract data, or alter records they should not have access to.

The official fix prevents connector and negated from being accepted through external input. Django now validates these values at the QuerySet layer and ensures that _connector is only set internally on Q objects. Patched releases include all maintained versions of Django—developers should upgrade immediately to a secure version to mitigate this issue.

Task 3 : Exploitation

Answer the questions below :

What is the title of the post by “DevOps Engineer”?

Monitoring Django Apps - Advanced

Browse to http://MACHINE_IP:8000/poc/employees. What is the name of the employee whose hire date is “June 5, 2022”?

David Rodriguez

Task 4 : Conclusion

This vulnerability only requires an application pattern that expands untrusted request parameters into ORM calls (e.g. filter(**request.GET.dict())) - no exotic privileges are needed. The exploit is subtle and can resemble normal traffic, making detection difficult. Upgrade Django to a patched release (for affected maintained branches) as the primary fix; if upgrading immediately is infeasible, block or log requests containing the internal keys (_connector, _negated) at the edge (WAF/proxy) or add application middleware that rejects those parameters and enforce a whitelist for allowed filter fields.