Avoid “OR 1=1” in SQL Injections

Despite its popularity as an SQL injection example, we argue that “OR 1=1” presents more risks than rewards. It may work for login bypasses occasionally, but its reliability is questionable, and better alternatives exist. We explore the drawbacks, from database overloads to data manipulation. We recommend using “OR 1=1” cautiously as a last-resort option in cybersecurity assessments.

I want to clarify upfront that when I mention “OR 1=1” here, I’m really talking about “OR <true>.” It’s not about the values 1 or equality but about using the logical operator OR with a condition that’s always true. I use “OR 1=1” for simplicity and recognition. If you were to conduct a Google search on “SQL Injection,” you’d discover that nearly every resource discussing this technique uses “OR 1=1” as the primary example.

The celebration of “OR 1=1” injection mainly revolves around two scenarios: login bypass and search function exploitation. While it can be effective in these cases, I believe it falls short of reliability. In this post, I argue that the associated risks outweigh the rewards, and it should be a last-resort option in security assessments.

Regarding login bypasses, consider the typical SQL statement for checking credentials:

In the initial statement, a row is returned only if it matches “admin” and “letmein.” With our injection, the “--” comment effectively removes the password requirement, retrieving rows with an empty username or when 1 equals 1. Since 1 always equals 1, all rows are retrieved.

While this injection may occasionally result in a successful login, one must consider the developer’s perspective. If a developer expects only one matching row for valid credentials, they would code the login check accordingly. Thus, the reliability of “OR 1=1” injections in login scenarios is uncertain. It might work sometimes but not always.

Nonetheless, there exists an injection that guarantees success every time (assuming it aligns with our SQL example): ' -- -. The caveat here is that you must possess one valid piece of data to match, such as the username. For a legitimate penetration tester, acquiring such data from the client should be a straightforward task.

The unreliability of the “OR 1=1” login bypass is just the tip of the iceberg; there are more perilous consequences associated with this injection. As demonstrated in the login SQL statement, it retrieves all rows from the table. While this may not be an issue for small tables, large databases could experience performance problems, potentially crashing the database server.

Developers may not include a LIMIT clause if the query is expected to return a limited number of rows. Given this, using payloads that could overload the database server is irresponsible.

The most alarming outcome of “OR 1=1” injection occurs when used in an UPDATE or DELETE statement. Many applications execute multiple SQL statements during a single request, and while most are SELECT queries, the application occasionally updates or deletes data based on user input.

Similar to how “OR 1=1” can flood a SELECT query with all rows of data, it can also wreak havoc on an UPDATE or DELETE statement. For instance, consider the following statement for a password reset: