• What is SQL Injection?
• How to find SQL Injection using sqlmap (vulnerable url)
• How to avoid SQL Injection in rails?
• How to avoid SQL Injections in general?

Video

• SQL Injection is where malicious code is inserted into strings that are later passed to an instance of SQL Server. So what happens is that we manipulate basic SQL logic to get the SQL server to tell us more about itself and then once we have enough information to break it, we crack it using it's own logic and get into the database.
• We will now see a demo of SQL injection using kali linux and the DVWA repository. DVWA stands for Damn Vulnerable Web Application which I'll be using to demonstrate most of the attacks and how you can find them and attack them. We will then see how to fix SQLI issues in rails. Note that DVWA is not a ruby on rails application but I will show some ruby on rails related sqlmap commands which I've used in my penetration testing and explain them so that the concept is clear.

sqlmap -u "localhost/DVWA-master/vulnerabilities/sqli_blind/?id=2&Submit=Submit#" --cookie="security=low; PHPSESSID=71fro0lrbhfegegtijrt11q0pg" --dbs

end of part 1 - stop recording

• Parameterized queries separate the SQL Query from the dynamic and often untrusted data. You could replace the string interpolated value with the following query and effectively separate the query from untrusted data:
• As seen above, the attack is the successful inclusion of an OR operator which helped us return all the records from database. More advanced queries could easily be crafted from this point onward. Let's take a look at the injection-proof version.
• SQL Injection is not possible when using the above, because the first element of the array is a template and the latters are parameters to that template.
• Again, this is free from SQL Injection, because column name is set explicitly to the 'name' and the external input set to the value of it.
• Usually a web application includes access control. The user enters their login credentials and the web application tries to find the matching record in the users table. The application grants access when it finds a record. However, an attacker may possibly bypass this check with SQL injection. The following shows a typical database query in Rails to find the first record in the users table which matches the login credentials parameters supplied by the user.
  • User.**find_by**("login = '#{params[:name]}' AND password = '#{params[:password]}'")
  • If an attacker enters ' OR '1'='1 as the name, and ' OR '2'>'1 as the password, the resulting SQL query will be
  • SELECT ***** FROM users WHERE login **=** '' OR '1'**=**'1' AND password **=** '' OR '2'**>**'1' LIMIT 1
  • This will simply find the first record in the database, and grants access to this user.
• The UNION statement connects two SQL queries and returns the data in one set. An attacker can use it to read arbitrary data from the database. Let's take the example from above:
• Project.**where**("name = '#{params[:name]}'")
• And now let's inject another query using the UNION statement
• ') UNION SELECT id,login AS name,password AS description,1,1,1 FROM users --
• This will result in the following SQL query
• SELECT ***** FROM projects WHERE (name **=** '') UNION SELECT id,login AS name,password AS description,1,1,1 FROM users *--'*