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.
