I am new to MYSQL, and I have a school task that says this:
This is the PhP code that shows how users are authenticated:
$input_uname = $_GET[’username’];
$input_pwd = $_GET[’Password’];
$hashed_pwd = sha1($input_pwd);
...
$sql = "SELECT id, name, eid, salary, birth, ssn, address, email,
nickname, Password
FROM credential
WHERE name= ’$input_uname’ and Password=’$hashed_pwd’";
$result = $conn -> query($sql);
// The following is Pseudo Code
if(id != NULL) {
if(name==’admin’) {
return All employees information;
} else if (name !=NULL){
return employee information;
}
} else {
Authentication Fails;
}
I have tried so many different things like this:
SELECT * FROM credential WHERE name= 'admin';
SELECT * FROM credential WHERE name= 'admin' and Password= 'xyz';
and I put this statement in the username box and xyz in the password box.
I am not sure if I am even approaching this correctly. The SQL statement should in the username box, correct? Is the Password box left empty? My professor hasn't covered this in class. Can someone please clarify how this is done? I have seen examples online and they all look somewhat similar to the above. But, I get the same error every single time:
`There was an error running the query [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'admin' and password= "xyz"; and Password= da39a3ee5e6b40d3255bfe95601890afd80 at line 3]\n`
Thank you all in advance!
I don't agree that the question is meant to teach people how to hack. It is meant to teach backend developer to sanitize input in order to avoid sql injection or other type of attacks.
To answer your question, you can leave the password field empty and just use the user name.
You can see on the server code that no control is made on the input as the input is taken as is and put on the sql statement. So in order to make the sql statement do what you are looking for, the field can has the following value:
admin'; --
The hyphens are sql comments that allow you to disable the last part of the select statement to not have to provide the password. And the quote and ; will close the statement. Result, you'll login as admin ;-)
Turns out this is what worked for me:
Admin’ or ‘1=1
I’m not completely sure why this also works but it does:
Admin’ or ‘
So for a school project I have to make a site with a log-in system. It has a username and password field, and a submit button. It compares the username and password with those in a MySQL database. If the combination is in the database, the user may proceed, else they are redirected to the log-in page. I use prepared PDO statements for my database connection.
Now my teacher wants me to test the safety by performing sql attacks on the log-in system. Unfortunately I have no idea what to put in these boxes, and what would be the outcome. For example, I have tried putting values in both username and password fields that will return true, like this:
1==1, 1===1, 0 is null
But I do not know whether or not I have succeeded and if attackers may access or truncate my database by these sort of statements.
Html code:
<form method="post" action="includes/login.php">
<input type="text" name="gebruikersnaam" >
<input type="password" name="wachtwoord" >
<input type="submit" value="login">
</form>
Php authentication:
$myusername=$_POST['gebruikersnaam'];
$mypassword=$_POST['wachtwoord'];
$sql="SELECT * FROM leerling WHERE leerlingnummer='$myusername' and wachtwoord='$mypassword'";
$sql2="SELECT * FROM lop WHERE gebruikersnaam='$myusername' and wachtwoord='$mypassword'";
$statement2=$conn->prepare($sql2);
$statement2->execute();
$count2=$statement2->rowcount();
if($count2==1){proceed}
$statement = $conn->prepare($sql);
$statement->execute();
$count= $statement->rowcount();
if($count==1){proceed}
else {deny access}
Imagine this query:
SELECT id FROM users WHERE email=? AND password=? LIMIT 1
Now imagine the values would be foo#bar.hello and an empty string for password:
SELECT id FROM users WHERE email='foo#bar.hello' AND password='' LIMIT 1
This would not be harmful if these credentials are not in your database. Now lets give different input:
For email we fill in an empty string, and for password we insert ' OR 1=1 (Note the first apostrophe)
Your teacher wants you to find out whether this means your SQL server will execute the following query:
SELECT id FROM users WHERE email='' AND password='' OR 1=1 LIMIT 1
SQL is a declarative language with which you declare the expectations you have for your result. If your server would interpret our input as stated above, the first users id would be considered correct, simply because one is equal to one.
As it is, it is susceptible to SQL injection
The thing to look at when trying to inject is can I close the statement I'm in right now and add more to the end.
so if you enter username = 123456' -- the SQL statement becomes SELECT * FROM leerling WHERE leerlingnummer='123456' --' and wachtwoord='unimortant'
the -- starts a comment so all it does is select whatever student number is entered ignoring the password.
PDO has good alternatives to prevent this from happening called Prepared Statements. You declare your SQL queries and only enter where user infromation is going to be entered by using a ? or :lable and then bind user input to those points. The page does a way better job at explaining it. This way all user data is clearly seperated from the rest of the command and will be treated as a litteral string rather than a command. Stopping SQL injection.
$sql="SELECT * FROM users WHERE username = '{$_REQUEST['username']}' AND password = '{$_REQUEST['password']}";
Write query in such format will avoid sql injection.
$sql = 'SELECT * FROM users WHERE username = ? AND password = ?';
$query = $db->prepare($sql);
$query->bindParam(1, $_REQUEST['username']);
$query->bindParam(2, $_REQUEST['password']);
Or pass the parameter to mysql_real_escape_string function and then pass to queries.
$username=mysql_real_escape_string($_REQUEST['username']);
$password=mysql_real_escape_string($_REQUEST['password']);
At school, I believe I work with Oracle SQL Developer when writing SQL. And in this I can type:
SELECT Book_Title, Auth_ID
FROM book
WHERE Auth_ID = '&Enter ID';
This will then display a little message box where the user can enter an ID number to see all the books written by an author with that ID number.
I want to know if there is a way to do this in MySQL. I have looked and the nearest thing I can find is setting a variable before hand, which is not quite what I'm looking for:
SET #EnterID := 2;
select Book_Title, Auth_ID
from book
where Auth_ID = #EnterID;
The above statement in MySQL will return all the books with author ID of 2, but only because I set it to that previously. I want the user to be able to enter the variable.
Thanks.
Oracle has the concept of interactive queries, those that as you said you can run by adding the '&' before your variables names, that is a variable substitution, this concept doesn't exist in MySql, MySql is not interactive and requires the user to enter the values in the variables by using the keyword 'SET' and # (instead of & like in Oracle).
So, no, you cannot do what you are looking for since this is not a client-side implementation either.
BTW, I just noticed this was asked so many years ago, amazing that this is still not added as a feature in mysql.
For a prompt, you must put the char ':' followed by the name of the variable
Example :
select *
from YOUR_TABLE
where YOUR_COLUMN = :your_var
mysql is to run SQL queries .SQL is a query language, it is not for user interaction
See : How to ask MySQL to prompt for values in a query?
Just looking at:
(Source: https://xkcd.com/327/)
What does this SQL do:
Robert'); DROP TABLE STUDENTS; --
I know both ' and -- are for comments, but doesn't the word DROP get commented as well since it is part of the same line?
It drops the students table.
The original code in the school's program probably looks something like
q = "INSERT INTO Students VALUES ('" + FNMName.Text + "', '" + LName.Text + "')";
This is the naive way to add text input into a query, and is very bad, as you will see.
After the values from the first name, middle name textbox FNMName.Text (which is Robert'); DROP TABLE STUDENTS; --) and the last name textbox LName.Text (let's call it Derper) are concatenated with the rest of the query, the result is now actually two queries separated by the statement terminator (semicolon). The second query has been injected into the first. When the code executes this query against the database, it will look like this
INSERT INTO Students VALUES ('Robert'); DROP TABLE Students; --', 'Derper')
which, in plain English, roughly translates to the two queries:
Add a new record to the Students table with a Name value of 'Robert'
and
Delete the Students table
Everything past the second query is marked as a comment: --', 'Derper')
The ' in the student's name is not a comment, it's the closing string delimiter. Since the student's name is a string, it's needed syntactically to complete the hypothetical query. Injection attacks only work when the SQL query they inject results in valid SQL.
Edited again as per dan04's astute comment
Let's say the name was used in a variable, $Name. You then run this query:
INSERT INTO Students VALUES ( '$Name' )
The code is mistakenly placing anything the user supplied as the variable. You wanted the SQL to be:
INSERT INTO Students VALUES ( 'Robert Tables` )
But a clever user can supply whatever they want:
INSERT INTO Students VALUES ( 'Robert'); DROP TABLE Students; --' )
What you get is:
INSERT INTO Students VALUES ( 'Robert' ); DROP TABLE STUDENTS; --' )
The -- only comments the remainder of the line.
As everyone else has pointed out already, the '); closes the original statement and then a second statement follows. Most frameworks, including languages like PHP, have default security settings by now that don't allow multiple statements in one SQL string. In PHP, for example, you can only run multiple statements in one SQL string by using the mysqli_multi_query function.
You can, however, manipulate an existing SQL statement via SQL injection without having to add a second statement. Let's say you have a login system which checks a username and a password with this simple select:
$query="SELECT * FROM users WHERE username='" . $_REQUEST['user'] . "' and (password='".$_REQUEST['pass']."')";
$result=mysql_query($query);
If you provide peter as the username and secret as the password, the resulting SQL string would look like this:
SELECT * FROM users WHERE username='peter' and (password='secret')
Everything's fine. Now imagine you provide this string as the password:
' OR '1'='1
Then the resulting SQL string would be this:
SELECT * FROM users WHERE username='peter' and (password='' OR '1'='1')
That would enable you to log in to any account without knowing the password. So you don't need to be able to use two statements in order to use SQL injection, although you can do more destructive things if you are able to supply multiple statements.
No, ' isn't a comment in SQL, but a delimiter.
Mom supposed the database programmer made a request looking like:
INSERT INTO 'students' ('first_name', 'last_name') VALUES ('$firstName', '$lastName');
(for example) to add the new student, where the $xxx variable contents was taken directly out of an HTML form, without checking format nor escaping special characters.
So if $firstName contains Robert'); DROP TABLE students; -- the database program will execute the following request directly on the DB:
INSERT INTO 'students' ('first_name', 'last_name') VALUES ('Robert'); DROP TABLE students; --', 'XKCD');
ie. it will terminate early the insert statement, execute whatever malicious code the cracker wants, then comment out whatever remainder of code there might be.
Mmm, I am too slow, I see already 8 answers before mine in the orange band... :-) A popular topic, it seems.
TL;DR
-- The application accepts input, in this case 'Nancy', without attempting to
-- sanitize the input, such as by escaping special characters
school=> INSERT INTO students VALUES ('Nancy');
INSERT 0 1
-- SQL injection occurs when input into a database command is manipulated to
-- cause the database server to execute arbitrary SQL
school=> INSERT INTO students VALUES ('Robert'); DROP TABLE students; --');
INSERT 0 1
DROP TABLE
-- The student records are now gone - it could have been even worse!
school=> SELECT * FROM students;
ERROR: relation "students" does not exist
LINE 1: SELECT * FROM students;
^
This drops (deletes) the student table.
(All code examples in this answer were run on a PostgreSQL 9.1.2 database server.)
To make it clear what's happening, let's try this with a simple table containing only the name field and add a single row:
school=> CREATE TABLE students (name TEXT PRIMARY KEY);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "students_pkey" for table "students"
CREATE TABLE
school=> INSERT INTO students VALUES ('John');
INSERT 0 1
Let's assume the application uses the following SQL to insert data into the table:
INSERT INTO students VALUES ('foobar');
Replace foobar with the actual name of the student. A normal insert operation would look like this:
-- Input: Nancy
school=> INSERT INTO students VALUES ('Nancy');
INSERT 0 1
When we query the table, we get this:
school=> SELECT * FROM students;
name
-------
John
Nancy
(2 rows)
What happens when we insert Little Bobby Tables's name into the table?
-- Input: Robert'); DROP TABLE students; --
school=> INSERT INTO students VALUES ('Robert'); DROP TABLE students; --');
INSERT 0 1
DROP TABLE
The SQL injection here is the result of the name of the student terminating the statement and including a separate DROP TABLE command; the two dashes at the end of the input are intended to comment out any leftover code that would otherwise cause an error. The last line of the output confirms that the database server has dropped the table.
It's important to notice that during the INSERT operation the application isn't checking the input for any special characters, and is therefore allowing arbitrary input to be entered into the SQL command. This means that a malicious user can insert, into a field normally intended for user input, special symbols such as quotes along with arbitrary SQL code to cause the database system to execute it, hence SQL injection.
The result?
school=> SELECT * FROM students;
ERROR: relation "students" does not exist
LINE 1: SELECT * FROM students;
^
SQL injection is the database equivalent of a remote arbitrary code execution vulnerability in an operating system or application. The potential impact of a successful SQL injection attack cannot be underestimated--depending on the database system and application configuration, it can be used by an attacker to cause data loss (as in this case), gain unauthorized access to data, or even execute arbitrary code on the host machine itself.
As noted by the XKCD comic, one way of protecting against SQL injection attacks is to sanitize database inputs, such as by escaping special characters, so that they cannot modify the underlying SQL command and therefore cannot cause execution of arbitrary SQL code. This can be done at the application level, and some implementations of parameterized queries operate by sanitizing input.
However, sanitizing inputs at the application level may not stop more advanced SQL injection techniques. For example, there are ways to circumvent the mysql_real_escape_string PHP function. For added protection, many database systems support prepared statements. If properly implemented in the backend, prepared statements can make SQL injection impossible by treating data inputs as semantically separate from the rest of the command.
Say you naively wrote a student creation method like this:
void createStudent(String name) {
database.execute("INSERT INTO students (name) VALUES ('" + name + "')");
}
And someone enters the name Robert'); DROP TABLE STUDENTS; --
What gets run on the database is this query:
INSERT INTO students (name) VALUES ('Robert'); DROP TABLE STUDENTS --')
The semicolon ends the insert command and starts another; the -- comments out the rest of the line. The DROP TABLE command is executed...
This is why bind parameters are a good thing.
A single quote is the start and end of a string. A semicolon is the end of a statement. So if they were doing a select like this:
Select *
From Students
Where (Name = '<NameGetsInsertedHere>')
The SQL would become:
Select *
From Students
Where (Name = 'Robert'); DROP TABLE STUDENTS; --')
-- ^-------------------------------^
On some systems, the select would get ran first followed by the drop statement! The message is: DONT EMBED VALUES INTO YOUR SQL. Instead use parameters!
The '); ends the query, it doesn't start a comment. Then it drops the students table and comments the rest of the query that was supposed to be executed.
In this case, ' is not a comment character. It's used to delimit string literals. The comic artist is banking on the idea that the school in question has dynamic sql somewhere that looks something like this:
$sql = "INSERT INTO `Students` (FirstName, LastName) VALUES ('" . $fname . "', '" . $lname . "')";
So now the ' character ends the string literal before the programmer was expecting it. Combined with the ; character to end the statement, an attacker can now add (inject) whatever sql they want. The -- comment at the end is to make sure any remaining sql in the original statement does not prevent the query from compiling on the server.
FWIW, I also think the comic in question has an important detail wrong: if you sanitize your database inputs, as the comic suggests, you're still doing it wrong. Instead, you should think in terms of quarantining your database inputs, and the correct way to do this is via parameterized queries/prepared statements.
The writer of the database probably did a
sql = "SELECT * FROM STUDENTS WHERE (STUDENT_NAME = '" + student_name + "') AND other stuff";
execute(sql);
If student_name is the one given, that does the selection with the name "Robert" and then drops the table. The "-- " part changes the rest of the given query into a comment.
The ' character in SQL is used for string constants. In this case it is used for ending the string constant and not for comment.
This is how it works:
Lets suppose the administrator is looking for records of student
Robert'); DROP TABLE STUDENTS; --
Since the admin account has high privileges deleting the table from this account is possible.
The code to retrieve user name from request is
Now the query would be something like this (to search the student table)
String query="Select * from student where username='"+student_name+"'";
statement.executeQuery(query); //Rest of the code follows
The resultant query becomes
Select * from student where username='Robert'); DROP TABLE STUDENTS; --
Since the user input is not sanitized, The above query has is manipulated into 2 parts
Select * from student where username='Robert');
DROP TABLE STUDENTS; --
The double dash (--) will just comment out remaining part of the query.
This is dangerous as it can nullify password authentication, if present
The first one will do the normal search.
The second one will drop the table student if the account has sufficient privileges (Generally the school admin account will run such query and will have the privileges talked about above).
You don't need to input form data to make SQL injection.
No one pointed this out before so through I might alert some of you.
Mostly we will try to patch forms input. But this is not the only place where you can get attacked with SQL injection. You can do very simple attack with URL which send data through GET request;
Consider the fallowing example:
show something
Your url would look
http://yoursite.com/show?id=1
Now someone could try something like this
http://yoursite.com/show?id=1;TRUNCATE table_name
Try to replace table_name with the real table name. If he get your table name right they would empty your table! (It is very easy to brut force this URL with simple script)
Your query would look something like this...
"SELECT * FROM page WHERE id = 4;TRUNCATE page"
Example of PHP vulnerable code using PDO:
<?php
...
$id = $_GET['id'];
$pdo = new PDO($database_dsn, $database_user, $database_pass);
$query = "SELECT * FROM page WHERE id = {$id}";
$stmt = $pdo->query($query);
$data = $stmt->fetch();
/************* You have lost your data!!! :( *************/
...
Solution - use PDO prepare() & bindParam() methods:
<?php
...
$id = $_GET['id'];
$query = 'SELECT * FROM page WHERE id = :idVal';
$stmt = $pdo->prepare($query);
$stmt->bindParam('idVal', $id, PDO::PARAM_INT);
$stmt->execute();
$data = $stmt->fetch();
/************* Your data is safe! :) *************/
...
I'm not exactly sure on the correct technical wording, so excuse my title, but here's the problem. I have a MySQL database, and in the user table I have *user_name*, a *password_salt*, and an md5 password containing the password then salt. In a program, users connect and I get one query to send to validate a user.
When a user connects I need a way of selecting their user_name, and comparing the given password to the stored password, which requires retrieving the salt somewhere in the WHERE statement (I guess).
This is my hypothetical "example":
SELECT user_name
FROM users
WHERE user_name='$nick' AND
password = md5(CONCAT('$md5pass', md5((select password_salt FROM users where user_name='$nick'))))
LIMIT 1
Resolution Update: Got it working, thanks for the suggestions, a normal select sufficed, the problem was that the sql-auth api wasn't receiving the password unless the port was specified.
Actually you can freely use any column from table declared in "FROM" clause not only in "SELECT" clause, but also in "WHERE" clause, so I don't see a need to subquery here. Let it be simply:
SELECT user_name
FROM users
WHERE user_name='$nick' AND
password = md5(CONCAT('$md5pass', md5(password_salt)))
LIMIT 1
This way a row is selected only if it matches both:
- user name is correct
- the password in row matches given password
I am not sure though if I used md5() functions correctly. I copied your example.
SELECT user_name
FROM users
WHERE user_name='$nick' AND
password = md5(CONCAT('$md5pass', password_salt))
LIMIT 1
Try this instead:
SELECT user_name
FROM users
WHERE user_name='$nick' AND
password = md5(CONCAT('$md5pass', md5(password_salt)))
LIMIT 1