Sunteți pe pagina 1din 17

SQL Injection

The ability to inject SQL


commands into the database
engine
through an existing application

What is SQL
Injection?
2

*SQL injectionis acode injectiontechnique that

exploits asecurity vulnerabilityoccurring in


thedatabaselayer of anapplication. The
vulnerability is present when user input is either
incorrectly filtered forstring literalescape
charactersembedded inSQLstatements or user
input is notstrongly typed. This allows
alteration of, for example, a hyperlink, which
would then cause a false positive query result
from the database and grant you access.

*What is SQL
Injection?

*Many web applications take user input from a form


*Often this user input is used literally in the
construction of a SQL query submitted to a
database. For example:
*SELECT product data FROM table WHERE
product name = user input product name;
*A SQL injection attack involves placing SQL
statements in the user input

*What is SQL
Injection?

Using SQL injections, attackers can:

* Add new data to the database

*Perform an INSERT in the injected SQL


*Modify data currently in the database
* Perform an UPDATE in the injected SQL

* Often can gain access to other users system


capabilities by obtaining their password

*injection possibilities

Common vulnerable login query


SELECT * FROM users
WHERE login = 'victor'
AND password = '123'

(If it returns something then login!)


ASP/MS SQL Server login syntax
var sql = "SELECT * FROM users
WHERE login = '" + formusr +
"' AND password = '" + formpwd + "'";

*How does SQL

Injection work?
6

*It is probably the most common Website

vulnerability today!
*It is a flaw in "web application" development,
it is not a DB or web server problem

* Most programmers are still not aware of this problem


* A lot of the tutorials & demo templates are vulnerable
* Even worse, a lot of solutions posted on the Internet are
not good enough

*In pen tests over 60% of web applications are


vulnerable to SQL Injection

*How common is it?


7

* Almost all SQL databases and programming languages are


potentially vulnerable

* MS SQL Server, Oracle, MySQL, Postgres, DB2, MS Access, Sybase,


Informix, etc

* Accessed through applications developed using:

* Perl and CGI scripts that access databases


* ASP, JSP, PHP
* XML, XSL and XSQL
* Javascript
* VB, MFC, and other ODBC-based tools and APIs
* DB specific Web-based applications and APIs
* Reports and DB Applications
* 3 and 4GL-based languages (C, OCI, Pro*C, and COBOL)
* many more

*Vulnerable

Applications
8

*' or " character String Indicators


*-- or # single-line comment
multiple-line comment
*/**/
*+ addition, concatenate (or space in url)
*|| (double pipe) concatenate
*% wildcard attribute indicator
*?Param1=foo&Param2=bar URL Parameters
*PRINT useful as non transactional command
*@variablelocal variable
*@@variable global variable
*waitfor delay '0:0:10' time delay

*SQL Injection
Characters

* The SQL statement you pass to prepare is parsed

and compiled by the database server.


* By specifying parameters (either a ? or a named
parameter like :name) you tell the database engine
what to filter on.
* Then when you call execute the prepared
statement is combined with the parameter values
you specify.

*How does this

prevent an attack?

*It works because the parameter values are


combined with the compiled statement,
not a SQL string.

SQL injection works by tricking the script into


including malicious strings when it creates SQL to
send to the database. So by sending the actual
SQL separately from the parameters you limit
the risk of ending up with something you didn't
intend.

*How does this

prevent an attack?

*If possible, use bound variables with


prepared statements

*Many libraries allow you to bind inputs to


variables inside a SQL statement

*Best defence

*Use provided functions for escaping strings

*Many attacks can be thwarted by simply using the

SQL string escaping mechanism


* \ and \
*mysql_real_escape_string() is the preferred function
for this

*Will not guard against all attacks

*Consider:
*SELECT fields FROM table WHERE id = 23 OR 1=1
*No quotes here!

*Other Defenses

*Use provided functions for escaping strings

*Many attacks can be thwarted by simply using the

SQL string escaping mechanism


* \ and \
*mysql_real_escape_string() is the preferred function
for this

*Will not guard against all attacks

*Consider:
*SELECT fields FROM table WHERE id = 23 OR 1=1
*No quotes here!

*Other Defenses

*Check syntax of input for validity

*Many classes of input have fixed languages


*Email addresses, dates, part numbers, etc.
*Verify that the input is a valid string in the language
*Some languages allow problematic characters (e.g., * in
email); may decide to not allow these
*Exclude quotes and semicolons
*Not always possible: consider the name Bill OReilly
*Want to allow the use of single quotes in names

*Have length limits on input

*Many SQL injection attacks depend on entering long strings

*More Defenses

*Scan query string for undesirable word

combinations that indicate SQL statements

*INSERT, DROP, etc.


*If you see these, can check against SQL syntax to see
if they represent a statement or valid user input

*Limit database permissions and segregate users


*If youre only reading the database, connect to

database as a user that only has read permissions


*Never connect as a database administrator in your
web application

*Even More Defenses

THANK YOU

S-ar putea să vă placă și