Scribd Logo
Upload

Welcome to Scribd!

  • 3 views

    SQ L Injection 1

    Uploaded by

    2205101260039

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd

    SQ L Injection 1

    Uploaded by

    2205101260039
    3 views26 pages

    Original Title

    Sq l Injection 1

    Copyright

    © © All Rights Reserved

    Available Formats

    PPTX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    3 views26 pages

    SQ L Injection 1

    Uploaded by

    2205101260039

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    of 26

    Database Administrator

    SQL Injection

    Topic

    1. What are injection attacks?
    2. How SQL Injection Works
    3. Exploiting SQL Injection Bugs
    4. Prevent SQL Injection
    5. Other Injection Attacks
    Injection


    Injection attacks trick an application into including unintended commands in
    the data send to an interpreter.
     Interpreters
     Interpret strings as commands.
     Ex: SQL, shell (cmd.exe, bash)
     Key Idea
     Input data from the application is executed as code by the interpreter.
    What is SQL Injection

     SQL injection (SQLi) is an application security weakness that allows attackers to
    control an application’s database
     letting them access or delete data, change an application’s data-driven behavior, and
    do other undesirable things
     by tricking the application into sending unexpected SQL commands

     One of the most dangerous issues in terms of data confidentiality and integrity in
    web applications is a vulnerability called SQL injection.
    SQL Injection
    1. App sends form to user.
     Form

    2. Attacker submits form with SQL User


    exploit data.
    Pass ‘ or 1=1--
    3. Application builds string with
    exploit data.
    4. Application sends SQL query to
    Firewall
    DB.
    5. DB executes query, including
    exploit, sends data back to
    application.
    6. Application returns data to user.
    DB Server
    SQL Injection Attack #1

     Unauthorized Access Attempt:
    password = ’ or 1=1 --
     SQL statement becomes:
    select count (*) from users where username = ‘user’ and password =
    ‘’ or 1=1 –
    Checks if password is empty OR 1=1, which is always true, permitting
    access.
    SQL Injection Attack #2

    Database Modification Attack:
    password = foo’; delete from table users
    where username like ‘%

    DB executes two SQL statements:


    select count(*) from users where username = ‘user’ and password = ‘foo’
    delete from table users where username like ‘%’
    Finding SQL Injection Bugs

    Submit a single quote as input.
    • If an error results, app is vulnerable.
    • If no error, check for any output changes.
    Submit two single quotes.
    • Databases use ’’ to represent literal ’
    • If error disappears, app is vulnerable.
    Try string or numeric operators.
     Oracle: ’||’FOO  2-2
     MS-SQL: ‘+’FOO  81+19
     MySQL: ’-’FOO  49-ASCII(1)
    Injecting into INSERT
     Creates a new data row in a table.

    INSERT INTO table (col1, col2, ...)
    VALUES (val1, val2, ...)
     Requirements
     Number of values must match # columns.
     Types of values must match column types.
     Technique: add values until no error.
     foo’)--
     foo’, 1)--
     foo’, 1, 1)--
    Injecting into UPDATE

     Modifies one or more rows of data.
    UPDATE table
    SET col1=val1, col2=val2, ...
    WHERE expression
     Places where input is inserted
    SET clause
    WHERE clause
     Be careful with WHERE clause
    ’ OR 1=1 will change all rows
    More Example (1)

     Application authentication bypass using SQL injection.
     Suppose a web form takes userID and password as input.
     The application receives a user ID and a password and authenticate the user by
    checking the existence of the user in the USER table and matching the data in
    the PWD column.
     Assume that the application is not validating what the user types into these two
    fields and the SQL statement is created by string concatenation.
    More Example (2)

     The following code could be an example of such bad practice:

    sqlString = “select USERID from USER where USERID = `” & userId & “` and PWD = `” & pwd & “`”
    result = GetQueryResult(sqlString)

    If(result = “”) then


    userHasBeenAuthenticated = False
    Else
    userHasBeenAuthenticated = True
    End If
    More Example (3)

     User ID: ` OR ``=`
     Password: `OR ``=`
     In this case the sqlString used to create the result set would be as
    follows:
    select USERID from USER where USERID = ``OR``=``and PWD = `` OR``=``
    select USERID from USER where USERID = ``OR``=``and PWD = `` OR``=``
    TRUE TRUE
     Which would certainly set the userHasBenAuthenticated variable
    to true.
    More Example (4)

    User ID: ` OR ``=`` --



    Password: abc

    Because anything after the -- will be ignore, the injection will work even without
    any specific injection into the password predicate.
    More Example (5)

    User ID: ` ; DROP TABLE USER ; --
    Password: `OR ``=`

    Select USERID from USER where USERID = `` ; DROP TABLE USER ; -- ` and PWD =
    ``OR ``=``

    I will not try to get any information, I just wan to bring the application down.
    Impact of SQL Injection

     Leakage of sensitive information.
     Reputation decline.
     Modification of sensitive information.
     Loss of control of db server
     Data loss.
     Denial of service.
    The Cause: String Building


    Building a SQL command string with user input in any language is dangerous.
     String concatenation with variables
     String format functions like sprintf().
     String templating with variable replacement.
    Mitigating SQL Injection
     Ineffective Mitigations

     Blacklists
     Stored Procedures

     Partially Effective Mitigations


     Whitelists
     Prepared Queries
    Blacklists

     Filter out or Sanitize known bad SQL meta-characters, such as single quotes.

     Problems:
    1. Numeric parameters don’t use quotes.
    2. URL escaped metacharacters.
    3. Unicode encoded metacharacters.

     Though it's easy to point out some dangerous characters, it's harder to point to
    all of them.
    Stored Procedures
     Stored Procedures build strings too:

    CREATE PROCEDURE dbo.doQuery(@id nchar(128))
    AS
    DECLARE @query nchar(256)
    SELECT @query = ‘SELECT cc FROM cust WHERE id=‘’’ + @id + ‘’’’
    EXEC @query
    RETURN It's always possible to write a stored procedure that itself constructs a
    query dynamically: this provides no protection against SQL Injection.
    It's only proper binding with prepare/execute or direct SQL statements
    with bound variables that provide protection.
    Whitelist

     Reject input that doesn’t match your list of safe characters to accept

     Identify what is good, not what is bad.


     Reject input instead of attempting to repair.
     Still have to deal with single quotes when required, such as in
    names.
    Prepared Queries

     bound parameters, which are supported by essentially all database programming interfaces. In this
    technique, an SQL statement string is created with placeholders - a question mark for each parameter
    - and it's compiled ("prepared", in SQL parlance) into an internal form. Later, this prepared query is
    "executed" with a list of parameters.
    Example in Perl:
    $sth = $dbh->prepare("SELECT email, userid FROM members WHERE email = ?;");
    $sth->execute($email);

     $email is the data obtained from the user's form, and it is passed as positional parameter #1 (the first
    question mark), and at no point do the contents of this variable have anything to do with SQL
    statement parsing. Quotes, semicolons, backslashes, SQL comment notation - none of this has any
    impact, because it's "just data". There simply is nothing to subvert, so the application is be largely
    immune to SQL injection attacks.
    Prepared Queries
     Bound parameters in Java

    Insecure version
    Statement s = connection.createStatement(); ResultSet rs = s.executeQuery("SELECT email FROM
    member WHERE name = " + formField);
    // *boom*

    Secure version
    PreparedStatement ps = connection.prepareStatement( "SELECT email FROM member
    WHERE name = ?");
    ps.setString(1, formField);
    ResultSet rs = ps.executeQuery();

     There also may be some performance benefits if this prepared query is


    reused multiple times (it only has to be parsed once), but this is minor
    compared to the enormous security benefits. This is probably the single
    most important step one can take to secure a web application.
    Other Injection Types

     Shell injection.
     Scripting language injection.
     File inclusion.
     XML injection0.
     XPath injection.
     LDAP injection.
     SMTP injection.
    SQL injection Conclusion

     SQL injection is technique for exploiting applications that use relational
    databases as their back end.
     All databases can be a target of SQL injection and all are vulnerable to this
    technique.
     SQL injection use the fact that many of these applications concatenate the
    fixed part of SQL statement with user-supplied data that forms WHERE
    predicates or additional sub-queries.
     The vulnerability is in the application layer outside of the database, and the
    moment that the application has a connection into the database.

    Thank You!

    You might also like