' OR 1=1/* SQL Injection Login Bypass Question

Question

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?

What I am guessing and using my logic is there is only possibility of this cheat sheet usage is where the programmer mistakenly placed the ending comment tag */ behind the SQL query as shown in the server-side code below.

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

Feel free to explain the usage and also possibly verify my own understanding of this particular cheat sheet's usage instead.

Edited : For misunderstandings , what I meant for */ at the end of the code as mentioned if a programmer mistakenly put it is shown below.

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

Answer 1

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 "<script> /*". 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.