Scribd Logo
Upload

Welcome to Scribd!

  • 18 views

    SQL Injection

    Uploaded by

    N i n j a
    SQL injection is a type of code injection attack where SQL commands are inserted into an entry field for execution by a backend database. It allows an attacker to view data, modify databases, execute administration operations, and recover usernames and passwords. The document discusses how SQL injection occurs, examples of vulnerable code, and how to prevent it using prepared statements and parameterized queries.

    Copyright:

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

    SQL Injection

    Uploaded by

    N i n j a
    18 views12 pages
    SQL injection is a type of code injection attack where SQL commands are inserted into an entry field for execution by a backend database. It allows an attacker to view data, modify databases, execute administration operations, and recover usernames and passwords. The document discusses how SQL injection occurs, examples of vulnerable code, and how to prevent it using prepared statements and parameterized queries.

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    SQL injection is a type of code injection attack where SQL commands are inserted into an entry field for execution by a backend database. It allows an attacker to view data, modify databases, execute administration operations, and recover usernames and passwords. The document discusses how SQL injection occurs, examples of vulnerable code, and how to prevent it using prepared statements and parameterized queries.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    18 views12 pages

    SQL Injection

    Uploaded by

    N i n j a
    SQL injection is a type of code injection attack where SQL commands are inserted into an entry field for execution by a backend database. It allows an attacker to view data, modify databases, execute administration operations, and recover usernames and passwords. The document discusses how SQL injection occurs, examples of vulnerable code, and how to prevent it using prepared statements and parameterized queries.

    Copyright:

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

    SQL Injection

    The Voluntary Vulnerability


    1. Injection
    2. Broken Authentication and Session
    Management
    3. Cross-Site Scripting (XSS)
    4. Insecure Direct Object References
    5. Security Misconfiguration
    6. Sensitive Data Exposure
    OWASP Top 10 7. Missing Function-Level Access
    Control
    8. Cross-Site Request Forgery
    (CSRF)
    9. Using Components With Known
    Vulnerabilities
    10.Unvalidated Redirects and
    Forwards
    Injection

    ● A type of data execution flaw

    ● Occurs when input isn’t properly separated from instructions

    ● Potentially affects any subsystem that executes text commands

    ○ OS shell, Regular Expressions, XPath queries, SQL, etc..

    ● Crafted inputs change the meaning of instructions


    SQL Injection

    ● Input into an improperly-constructed SQL statement can change


    its meaning

    ● Allows data manipulation and theft

    ● Responsible for numerous password breaches

    ● Totally voluntary

    ● ..but as many as 1 in 5 applications are still vulnerable*


    Seen code like this?
    (It’s the most popular way to opt in)
    Normal values (Bob) work about how you’d expect:
    Imagine the SELECT * FROM User WHERE name = 'Bob'
    possibilities!
    However, crafted values (Bob'; DROP TABLE User;--) can add
    destructive DDL statements:

    SELECT * FROM User WHERE name = 'Bob'; DROP TABLE User;--'

    Or union in entire queries to steal data (' UNION SELECT


    PasswordHash, PasswordSalt, Name, Username FROM User
    WHERE Username = 'administrator')

    SELECT * FROM User WHERE name = '' UNION SELECT


    PasswordHash, PasswordSalt, Name, Username FROM User
    WHERE Username = 'administrator'
    ..By using your data access frameworks as
    So, how do intended.
    you avoid ● Prepared statements/parameter binding are
    it? recommended for performance and readability
    ○ ..And also maintain that separation

    ● Higher-level data access frameworks (like


    ORMs) offer other options
    Parameter binding in ADO.NET

    It’s not that different.

    Instead of doing this..

    ..you can simply do this:

    Other data access technologies will vary, but all support some
    variation on parameters.
    If it’s so much better, why
    doesn’t everyone do it?

    ● Not everyone knows about it

    ● There are some limitations:

    ○ Bound parameters can only be used for values.

    ■ Not object names or keywords

    ○ Extra steps required to pass collections of values

    ○ Conditional logic can be more complex


    ORMs are also safe..when used properly..and
    What about address some of these limitations
    ORMs (ie: EF ● Data and instructions can be separated
    or automatically

    Hibernate)? ● Can be more flexible than prepared statements


    because commands can be built incrementally
    ● They’re not magic - any APIs are subject to
    misuse/abuse (ie: splicing values into abstract
    query language statements)
    ● Things are getting better
    So, where
    does that
    ○ Merit-based forums like StackOverflow favor better
    examples, which means better developer education

    leave us? ○ ORMs allow developers to work with data in a more


    abstract way (and deal less with the details)

    ● ..but SQLi is still prevalent in our industry


    ○ Some developers don’t seem to know that prepared
    statements exist

    ○ ..And others don’t seem to understand how they work

    ○ ..Or even believe that they do

    ● ..and the only way to fight it is with knowledge.


    So, don’t
    wait to meet
    Bobby
    Tables..
    https://xkcd.com/327/

    ..Spread the word, inspect your code, talk to your


    developers, and make sure no one you know is
    opting in for the #1 vulnerability in our Top 10.

    You might also like