
WebApp Sec mailing list archives
RE: SQL Injection
From: "Imperva Application Defense Center" <adc () imperva com>
Date: Wed, 2 Jun 2004 09:54:01 +0200
Hi,
What if their name was O'Henry? Security must be paramount to the developer, but invisible to the client. Best choice: parameterized queries. Second best: have a stored procedure make the modification. Third: filter IN good characters. Forth: filter OUT bad characters.
Agreed (with one reservation about the stored procedures - I'll explain below). If you go back to the original reference in the question to our Evasion Techniques paper, you will see that trying to predict how an SQL injection attack looks like can be very very risky. I do agree that if you decide to disallow all special characters, and allow only alphanumerical characters, then the solution is safe. However, it is a big functionality issue, and usually requires being developed per field, as some fields will HAVE to allow some strings (such as St. John's Street, which required both a quote and a period). Using parameterized queries or prepared statements is the easiest way to take all that off your head. It's spending, one time, a few hours on learning how to use this, and changing your habits so that all SQL queries will be done like that and not with string queries. And once you are done with this, SQL Injection is simply no longer an issue. About Stored Procedures - using stored procedures CAN be safe and can be very dangerous. Many people call stored procedure as part of a string query: Sqlstr = "exec sp_mysecurelogin (" & Username & "," & Password & ");" If I can inject characters in the password, I can naturally terminate the call for the SP myself, and start doing other things (like ; shutdown -- ). Moreover, I have seen programmers who use stored procedures, and do string concatenation inside the stored procedure itself. So the call to the SP is safe, but then inside it, there is the same old problem where you can put OR 1=1 (or UNION SELECT in other places...) I have therefore stopped recommending my customers to use stored procedure - they can be badly implemented as well. Using prepared statements, however, proves itself as the right solution. --- Ofer Maor Application Defense Center Manager Imperva(tm) Inc. http://www.imperva.com/adc/
Current thread:
- SQL Injection Emanuele Zattin (May 31)
- Re: SQL Injection windo (Jun 01)
- RE: SQL Injection V. Poddubniy (Jun 01)
- Re: SQL Injection Serg B. (Jun 01)
- Re: SQL Injection RSnake (Jun 01)
- Re: SQL Injection Paul (Jun 01)
- <Possible follow-ups>
- RE: SQL Injection Scovetta, Michael V (Jun 01)
- Re: SQL Injection David Cameron (Jun 02)
- RE: SQL Injection Imperva Application Defense Center (Jun 02)
- RE: SQL Injection stevenr (Jun 02)
- Re: SQL Injection Steven M. Christey (Jun 03)
- Re: SQL Injection The Crocodile (Jun 04)
- RE: SQL Injection stevenr (Jun 06)
- RE: SQL Injection The Crocodile (Jun 06)
- Re: SQL Injection Jeff Williams (Jun 08)
- Re: SQL Injection saphyr (Jun 09)
- RE: SQL Injection The Crocodile (Jun 06)
- Request for comments - French readers saphyr (Jun 08)
- Re: SQL Injection Steven M. Christey (Jun 08)
- RE: SQL Injection Michael Howard (Jun 09)