Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Django, a Python web framework, contains an Object Relational Mapper (ORM). This is a set of APIs for performing data storage that uses SQL under the hood but doesn't actually require the writing of SQL. There is a set of QuerySet methods that interact with an underlying database. From a security perspective, this is great because it should prevent SQL injection from the beginning.

When interacting with the QuerySet methods, there are mandatory and optional parameters. An example QuerySet method is get(), which can be used with specific parameters. In Python, using the syntax func(**var) in a function call will treat var as a key/value pair where the key is the named parameter to use a particular value.

After reviewing the code of the QuerySet APIs, they noticed that two parameters, _connector and _negated, were not being filtered adequately for SQL injection. The thing is, these aren't usually controllable values.

The ability to set internal parameters to a function call is fine. But, this is where the **var syntax comes into play. If an attacker could control the contents of **var being used in one of the vulnerable functions, they can control the parameters vulnerable to SQL injection! They claim this can lead to authentication bypasses, data exfil and privilege escalation, which is true but context-dependent.

This is labeled as critical with a CVSS score of 9.1. Personally, I find the post slightly exaggerated in terms of impact. Yes, there's a SQL injection (which is a good find), but how many applications follow the pattern above? Probably not a lot. Showing the impact of libraries is hard because there are no direct things at risk; it all depends on how people use them.