1. *
HEMENDRA KUMAR
(0806413042)

2. The ability to inject SQL
commands into the database
engine
through an existing application
*
2

3. * 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 productdata FROM table WHERE productname =
„user input product name‟;
* A SQL injection attack involves placing SQL statements
in the user input
*

4. * 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
*
4

5. * 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 API‟s
* Reports and DB Applications
* 3 and 4GL-based languages (C, OCI, Pro*C, and COBOL)
* many more
*
5

6. 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 + "'";
*
6

7. formusr = ' or 1=1 – –
formpwd = anything
Final query would look like this:
SELECT * FROM users
WHERE username = ' ' or 1=1
– – AND password = 'anything'
*
7

8. * It closes the string parameter
* Everything after is considered part of the SQL
command
* Misleading Internet suggestions include:
* Escape it! : replace ' with ' '
* String fields are very common but there are
other types of fields:
* Numeric
* Dates
*
8

9. SELECT * FROM clients
WHERE account = 12345678
AND pin = 1111
PHP/MySQL login syntax
$sql = "SELECT * FROM clients WHERE " .
"account = $formacct AND " .
"pin = $formpin";
*
9

10. $formacct = 1 or 1=1 #
$formpin = 1111
Final query would look like this:
SELECT * FROM clients
WHERE account = 1 or 1=1
# AND pin = 1111
*
10

11. * ' 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
* @variable local variable
* @@variable global variable
* waitfor delay '0:0:10' time delay
*
11

12. * 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 user‟s system
capabilities by obtaining their password
*

13. * Use provided functions for escaping strings
* Many attacks can be avoided by simply using the SQL
string escaping mechanism
* „  ‟ and “  ”
* mysql_real_escape_string() is the preferred function for
this
* No quotes
* Consider:
* SELECT fields FROM table WHERE id = 23 OR 1=1
* No quotes here!
*

14. * 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
* Sometime languages allow problematic characters (e.g., „*‟ in
email addresses); may decide to not allow these
* If you can exclude quotes and semicolons that‟s good
* Not always possible: consider the name Bill O‟Reilly
* Want to allow the use of single quotes in names
* Have length limits on input
* Many SQL injection attacks depend on entering long strings
*

15. * 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 you‟re 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
*

16. *Configure database error reporting
* Default error reporting often gives away information
that is valuable for attackers (table name, field name,
etc.)
* Configure so that this information is never exposed to a
user
*If possible, use bound variables
* Some libraries allow you to bind inputs to variables
inside a SQL statement
*

17. *