The document discusses SQL injection attacks and how they work. SQL injection occurs when user input is inserted directly into an SQL query string without proper validation or escaping. This allows attackers to alter the structure of the intended SQL query and potentially gain unauthorized access to sensitive data or make unauthorized changes to the database. The document provides examples of vulnerable queries and how attackers can exploit them to inject malicious SQL code. It also lists some common techniques used in SQL injection attacks and provides recommendations for preventing SQL injection vulnerabilities.

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