null Bangalore January meet

1. Web Application Security - The pitfalls and the brick
walls
A developer’s perspective – SQL Injection

2. about me
 Engineering in Computer science
 Working as Sr. Software engineer for KPIT Technologies
 Web application developer for more than 4 years
 Primary interest in C#.net, SQL server and JavaScript
 I’m not here representing anyone, except of course myself

3. talk about…
 A brief introduction about authentication & authorization
 SQL Injection
 What is SQL Injection
 Types of SQL injection
 Injection using escape characters
 Injection caused by incorrect type handling
 Injection through data truncation
 Blind SQL Injection and inference
 Inference through timing attacks

4. What is SQL Injection ?

5. No seriously, what is SQL injection ?
 It’s a technique used to inject unwarranted SQL code into a vulnerable
application’s authorized SQL statements through an un-sanitized input
parameter
 It is a vulnerability caused mostly due to the use of un-sanitized user input
being used to generate dynamic SQL queries

6. An example might help
 string query = "SELECT * FROM EMPLOYEE WHERE Name='" + employeeName + "'";
 When we use the above query as is, the variable employeeName may cause a
vulnerability in our application, if the value of the same is taken from user generated
data and used without sanitizing it
 If the value of the variable can be manipulated by the user, then malicious user may
try and compromise the system by providing carefully crafted SQL queries as the
value for the said variable
 If the value of the variable is set to Test';DELETE FROM EMPLOYEE;-- the
attacker would be able to delete all the records in the employee table,
given there are enough permissions for the db account under which the
query is executed
 Even if there are no permissions for delete on db, the attacker still may
access data, to which he might not have access to
 Lets see some code 

7. How does parameterization help ?
 Basic data validation against type and length
 Parameterized input are never treated as part of the SQL code, but as
mere values

8. Pitfalls and the brick walls
 Developer oversight and/or lack of awareness
 Unwarranted use of dynamic SQL, even when there is no need for the
same
 Little or no server side validation for user input
 Unjustified access permissions for database accounts configured to be
used by the application

9. Just about to roundup
 Dynamic SQL only to be used when absolutely required
 Parameterization should be used instead of dynamic SQL
 All user input should be validated on the server side before being passed
into the database engine for execution
 Unwarranted permissions for database accounts used by the application
should be revoked

10. “Inspiration” for this talk
 http://technet.microsoft.com/en-us/library/ms161953(v=sql.105).aspx
 http://en.wikipedia.org/wiki/SQL_injection
 https://www.owasp.org/index.php/SQL_Injection
 http://www.worldofhacker.com/2013/09/complete-reference-guide-to-sqlihow-to.html
 http://www.websec.ca/kb/sql_injection
 http://www.ijcnis.org/index.php/ijcnis/article/view/364/115
 http://technet.microsoft.com/en-us/library/cc512676.aspx