SQL Injection By Adam Reagan New York State Insurance Department Systems Bureau April 2009
Definition <ul><li>The injection of code that exploits a security vulnerability at the database layer of an application </...
The Basic Idea <ul><li>With SQL Injection, we rely on user-supplied input to build queries </li></ul><ul><li>For example, ...
The Basic Idea (Continued) <ul><li>If the user name and password are entered as expected, the query should execute with no...
The Attack <ul><li>Using the same code to verify that the user name and password exist in the database, what if the follow...
The Attack (Continued) <ul><li>In many SQL databases, “--” is a comment delimiter </li></ul><ul><li>Anything following “--...
The Solution <ul><li>Use  PreparedStatements </li></ul><ul><li>Modify the code to verify that the user exists to look like...
The Solution (Continued) <ul><li>By using a prepared statement, each parameter is explicitly defined upon execution </li><...
Other Tips <ul><li>Set the  maxlength  attribute in HTML input textfields to limit the amount of allowable user input </li...
Summary <ul><li>SQL Injection attacks are considered one of the most dangerous types of attacks in web application securit...
Upcoming SlideShare
Loading in...5
×

SQL Injection

606

Published on

SQL Injection is one of the most common ways to hack into login-based web applications. This presentation defines SQL Injection, discusses why it is dangerous, and how to prevent these types of attacks.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
606
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
41
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

SQL Injection

  1. 1. SQL Injection By Adam Reagan New York State Insurance Department Systems Bureau April 2009
  2. 2. Definition <ul><li>The injection of code that exploits a security vulnerability at the database layer of an application </li></ul><ul><li>Sometimes referred to as the “buffer overflow” of web applications </li></ul><ul><li>Takes advantage of gaps in developer-managed memory and often allows for arbitrary remote code execution </li></ul><ul><li>Often considered the most dangerous attacks in application security </li></ul>
  3. 3. The Basic Idea <ul><li>With SQL Injection, we rely on user-supplied input to build queries </li></ul><ul><li>For example, if a user were to enter a username and password in a logon page, the following lines of code might be used to verify that the user exists: </li></ul>
  4. 4. The Basic Idea (Continued) <ul><li>If the user name and password are entered as expected, the query should execute with no problems </li></ul><ul><li>Example: </li></ul><ul><ul><li>userName = “bob” </li></ul></ul><ul><ul><li>password = “secret1” </li></ul></ul><ul><li>The resulting query from the previous slide would look like this: </li></ul>
  5. 5. The Attack <ul><li>Using the same code to verify that the user name and password exist in the database, what if the following parameters were entered by the user at the logon page: </li></ul><ul><ul><li>userName = bob’ OR ‘1’ = ‘1’ -- </li></ul></ul><ul><ul><li>password = “whocares” </li></ul></ul><ul><li>In this case, the query to be executed would look like this: </li></ul>
  6. 6. The Attack (Continued) <ul><li>In many SQL databases, “--” is a comment delimiter </li></ul><ul><li>Anything following “--” is commented out and not executed </li></ul><ul><li>Therefore, we don’t even need to know what the password is, for it won’t be included in the query </li></ul><ul><li>Also note that ‘1’ = ‘1’ will always be true </li></ul><ul><li>That being said, the query from the previous slide will return a result set containing ALL rows from the USERS table, regardless of what user name is entered </li></ul><ul><li>This is sometimes referred to as the “ 1 equals 1 ” attack </li></ul><ul><li>Keep in mind that this type of attack isn’t just limited to logon pages, but ANYWHERE user input is embedded in an SQL statement </li></ul><ul><li>Also, by entering a ‘;’ (or several semi-colons) in the user name field, an attacker could potentially execute multiple queries on the database, including malicious queries that could do some SERIOUS damage (i.e. inserts, updates, deletes) </li></ul>
  7. 7. The Solution <ul><li>Use PreparedStatements </li></ul><ul><li>Modify the code to verify that the user exists to look like this: </li></ul>
  8. 8. The Solution (Continued) <ul><li>By using a prepared statement, each parameter is explicitly defined upon execution </li></ul><ul><li>Now, if the “1 equals 1” attack is attempted, an run-time error will occur (code should be written to handle these errors) </li></ul><ul><li>Thus, we have prevented the attacker from obtaining all of the data from the USERS table </li></ul>
  9. 9. Other Tips <ul><li>Set the maxlength attribute in HTML input textfields to limit the amount of allowable user input </li></ul><ul><li>Validate the user’s input in your java class before query execution </li></ul><ul><ul><li>In some of our Licensing web applications, the logon page requires a license number and password, both strictly numeric values </li></ul></ul><ul><ul><li>Apply the Integer.parseInt() method </li></ul></ul><ul><ul><li>A NumberFormatException will be thrown if the “1 equals 1” attack is attempted </li></ul></ul>
  10. 10. Summary <ul><li>SQL Injection attacks are considered one of the most dangerous types of attacks in web application security </li></ul><ul><li>Applications rely on user-supplied input to build certain queries </li></ul><ul><li>This input must be validated before being used in a query </li></ul><ul><ul><li>Check for malicious input (i.e. escape characters) </li></ul></ul><ul><li>Use PreparedStatements instead of injecting user-supplied input into a string variable to build a query </li></ul><ul><li>By explicitly defining the parameters of a prepared statement, attacks such as the “1 equals 1” attack are prevented </li></ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×