5. Actual use case
$sql = “SELECT * FROM ARTICLES WHERE id = “ . $_GET[“id”];
//executed query - SELECT * FROM ARTICLES WHERE ID = 1234
$result = mysql_query($sql);
5
6. SQL injected input
$sql = “SELECT * FROM ARTICLES WHERE id = “ . $_GET[“id”];
//executed query - SELECT * FROM ARTICLES WHERE ID = 1234; DROP
TABLE ARTICLES
$result = mysql_query($sql);
6
9. There are queries for that too…
http://www.site.com/articles.php
?id=1234 UNION SELECT
group_concat(schema_name),2,3,4,
5,6,7,8,9,10,11,12,13,14,15,16,1
7,18,19,20,21,22,23,24 from
information_schema.schemata --
9
10. There are queries for that too…
http://www.site.com/articles.php
?id=1234 UNION SELECT
group_concat(table_name),2,3,4,5
,6,7,8,9,10,11,12,13,14,15,16,17
,18,19,20,21,22,23,24 from
information_schema.tables where
table_schema=database()--
10
12. SQL Attack steps
• Searching for a vulnerable point
• Fingerprinting the backend DB
• Enumerating or retrieving data of interest –
table dumps, usernames/passwords etc.
• Eventual exploiting the system once the
information is handy
– OS take over, data change, web server take over
etc.
12
13. It is a very serious problem
• The attacker can delete, modify or even
worse, steal your data
• Compromises the safety, security & trust of
user data
• Compromises a company’s competitiveness or
even the ability to stay in business
13
14. How to mitigate the risk
• Escape all user supplied input
• Always validate input
• Use prepared statements
– For PHP+MySQL – use PDO with strongly typed
parameterized queries (using bindParam())
• Code reviews
• Don’t store password in plain text in the DB
– Salt them and hash them
14
15. Escape & Validate input
• Escape all input
– Whether supplied via the URL or via POST data
– Even for internal APIs
– Anything that goes to the DB is escaped
• Validate all input - Validating a Free Form Text Field for
allowed chars (numbers, letters, whitespace, .-_)
– ^[a-zA-Z0-9s._-]+$ (Any number of characters)
– ^[a-zA-Z0-9s._-]{1-100}$ (This is better, since it limits this
field to 1 to 100 characters)
• source https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet
15
16. Least privilege
• To minimize the potential damage of a
successful SQL injection attack, you should
minimize the privileges assigned to every
database account in your environment.
• Do not assign DBA or admin type access rights
to your application accounts.
• Don't run your DBMS as root or system!
16
17. URL rules
• No parentheses or angular brackets in the URLs
– While saving or generating remove from the URLs
– If you really need to have parentheses or angular brackets
in the URL, then encode them
• URL should not end with two or more dashes “--“
– While saving or generating remove these from the URLs
• URL should not end with “/*”
– While saving or generating remove these from the URLs
• No schema, table or column names should be part of
your URL
• These rules should be followed even for AJAX/JSON
URLs
17
18. Quick fixes
• For companies that have a large setup or a lot
of legacy code that will take a long time to
audit and fix, put some SQL injection
detection patterns in your Load Balancer itself
• Enable mod_security on Apache
• Run the RIPS scanner on your PHP code for
detecting vulnerabilities -
http://sourceforge.net/projects/rips-scanner/
18
19. Common (My)SQL injection URL
patterns
• ending with “--”
• ending with “/*”
• containing UNION, (ALL), SELECT and FROM
• BENCHMARK
• Containing “information_schema”
• Containing “load_file”
19
20. Further reading
• SQL attacks by example -
http://www.unixwiz.net/techtips/sql-
injection.html
• OWASP -
https://www.owasp.org/index.php/SQL_Inject
ion
20