Web App Security - A Developers Perspective: Part 1 - SQL Injection

  • 2,925 views
Uploaded on

null Bangalore January meet

null Bangalore January meet

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,925
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • A few of these topics might sound childish, but are needed to establish the rest of the talk
  • http://xkcd.com/327/

Transcript

  • 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