SQL injection is one of the most common ways that hackers gain access to your SQL server. Do you know how to protect your data from malicious users?
This session will provide an overview of how SQL injection works as well as T-SQL examples and techniques to protect against it. We’ll also take a look at why some commonly used techniques aren’t as secure as many people think.
If you ever write or maintain dynamic SQL queries then this session is for you.
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
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
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
Hard to pin point exactly who first discovered SQL injection. DO know that in 1998 already appearing in hacker zines.
This examples is showing a SQL query that’s variabalized in some app code
- Web 2.0, shiny buttons and every company trying to make money online.
Problem was, no one knew how to do security. Unless you had a really security conscious developer, you were out of luck.
Open Web Application Security Project was formed because a group of people realized needed to create education, information about the types of attacks out there.
Put together top 10 list
In the initial years, these ranked by guessing/first hand experience – no statistics available
SQL and other injection attacks ranked as #6.