1. The document discusses SQL injection attacks and provides an overview of how to prevent them. It explains that SQL injection occurs when unsanitized user input is executed as part of a SQL query, allowing attackers to perform unintended actions. 2. It notes that preventing SQL injection requires a multi-layered approach including validating, sanitizing, and escaping user input, limiting the privileges of database execution accounts, and using software to proactively test for vulnerabilities. 3. The document aims to dispel common misconceptions about SQL injection, such as thinking obfuscated table names or ORM tools prevent attacks, or that attacks only target important targets. It emphasizes the shared responsibility of developers and DBAs to implement

1. SQL Injection Attacks:
Is Your Data Secure?
| Bert Wagner | March 16, 2018

2. Objective
SQL injection prevention does not have an “easy” solution

3. Disclaimers
• Try this at home
• Not at work
• Not on other people’s systems

4. Background
• Business Intelligence Developer
• Tech security enthusiast
• Saw my first injection attempts in ~2001 – MySQL logs
Demo code and slides available at bertwagner.com

5. Overview
1. Importance of SQL injection protection
2. Dynamic SQL
3. What does SQL injection look like?
4. Common misconceptions
5. Preventing SQL injection

6. • Data Leaks
• Data Validity
• Server Availability

7. Dynamic SQL
“Just because you can, doesn’t mean you should.”
• Can’t parameterize
everything
• Adaptable Queries
• Performance
However…

8. What is SQL Injection?
• Dynamic string execution
• Unsanitized input (could be from a column or parameter)
• Performing something the query wasn’t originally intended to do

9. What is SQL Injection?
SQL injection can occur without concatenated parameters too

10. Let’s go back to 1998…

11. OWASP 2004

12. OWASP – Present Day

13. Common Misconceptions
“The structure of my
database isn’t public”
You don’t have a Users table? Products?
Inventory? etc...
“The Amazing Bert”

14. Common Misconceptions
“I obfuscate my table names”
sys.objects? Errors displayed in app?
Logs, emails, social engineering…?

15. Common Misconceptions
“The developers should validate, restrict output”
True. But multiple layers of security are better than one.
Front end validation doesn’t stop malicious users Server side validation stops some

16. Common Misconceptions
“I’m not important enough to get hacked”
Automated injection tools target everyone
https://github.com/sqlmapproject/sqlmap/wiki/Techniques

17. Common Misconceptions
“I use an ORM to code my SQL queries”
ORMs are still vulnerable if you need to pass an argument that can’t be
parameterized by SQL Server or if you use a vulnerable stored procedure
ORMs are vulnerable other ways too:
https://bertwagner.com/2018/03/06/2-5-ways-your-orm-will-allow-sql-injection/

18. Protecting Against SQL Injection
Must take a multi-layered approach.
Demos:
• Don’t write dynamic SQL
• sp_executesql
• QUOTENAME()
• REPLACE()
• EXECUTE AS
• Limit inputs
• Homoglyph attacks
• Proactively find injection vulnerabilities

19. Recap
• No easy, single-approach solution
• Validate, sanitize, escape
• Developers and DBAs both responsible
• Limit executing account privileges
• Use other software to help test, find vulnerabilities

20. Thank you!
@bertwagner
bertwagner.com
youtube.com/c/bertwagner
bert@bertwagner.com
20
New posts and videos
every Tuesday!