Explain OR 1=1.

660 Asked by makram_8714 in Web-development , Asked on Oct 17, 2022

Recently I came across a SQL Injection Cheat Sheet which contains this particular cheat sheet which I am confused by ' or 1=1/*

Assuming I am testing it on this server-side code below.

SELECT * FROM users WHERE login='$login' AND password='$password';

Well I can't seem to bypass it with that cheat sheet. I am just curious why do they include it as a cheat sheet instead? How is that particular cheat sheet used?

Answered by Donna Chapman

There are a few considerations here, first is to explain how this is supposed to work:

SQL injections are a very old kind of hack that should not affect modern SQL implementations. Back before you could use prepared statements, SQL queries were normally made using concatenated strings. This meant that whatever your input was would become part of the executed sql like this:

$login = "John";

$password = "' OR 1=1 --";

$myIP = '555.555.555.555';

$sql = "SELECT * FROM users WHERE login='" . $login . "' AND password='" . $password . "' AND userip = '" . $myIP . "'";

echo $sql;

OUTPUT: SELECT * FROM users WHERE login='John' AND password='' OR 1=1 -- AND userip = '555.555.555.555'

That first ' will close the string quote to keep the syntax valid. Then, because 1 always equals 1, you create a select statement that is always true. That means that you will select the user "John" allowing you to log in as him with no knowledge of his password. Then -- is the SQL syntax to remark anything that comes after it. This is used to eliminate any other conditions that might prevent your successful login such as IP validation or something of that nature.

The second thing here is the /*. This will actually break a 1=1 injection because that is invalid transact SQL syntax. That said, /* can be used in an execution level attack. Many developers put too much trust in prepared statements. Just because it does not execute input at the SQL transaction does not mean it can't contain stuff that can be executed later.

For example, if you have an input box on a website, and you want to test to see if the site is vulnerable to JS-XSS attacks, you could input "[removed] /*". This means that when your program goes to take this from your database and run it, you'll execute a JavaScript that remarks the remainder of your page, then it will kill your program when you try to load the output of that information.

In short your source is mixing up remarking syntax for 2 different kinds of attacks, but they are both legitimate concerns given the right vulnerabilities.

Explain OR 1=1.

Your Answer