Can I avoid all SQL-injection attacks by using parameters?
And don't worry about any thing in SQL injection in this case?
Or are there some types of these attacks which require more care on the part of the programmer?
No, you can't avoid all SQL injection attacks by using parameters. Dynamic SQL is the real issue, and this can occur in stored procedures as well as in your application code.
E.g., this is prone to a SQL injection attack: your parameterized query passes a username to a stored procedure, and within the stored procedure the parameter is concatenated to a SQL command and then executed.
For an example of many kinds of SQL injection attacks, see this SQL Injection Cheat Sheet. You will see that simply escaping single quotes is just scratching the surface, and that there are many ways around that.
Yes and no. Yes, if all of your SQL statements are indeed static and use only parameters, then you're 100% protected from SQL injection attacks.
The problem comes when the parameters themselves are used to construct dynamic SQL statements. An example would be a stored procedure that generates a SQL statement dynamically for querying a multitude of different options, where a single monolithic statement would be impractical. While there are better solutions to this problem, this is a common one.
Yes you can avoid all SQL-injection attacks by using parameters, as long as you use parameters exclusively all the way down the call stack. For example:
Your app code calls a stored procedure or dynamic SQL in the database. That must use parameters to pass all values.
The stored procedure or dynamic SQL internally constructs a call to another stored procedure or dynamic SQL statement. That must also use parameters to pass all values.
Repeat ad-infinitum until you run out of code.
If you are programming in SQL Server, you can use sp_executesql to execute dynamic SQL, and it will let you define and pass parameterised values to the statement being executed.
If you are going to build a dynamic sql query with those parameters (passed to a stored procedure, for example) then there's a chance of sql injection if precautions are not taken.
You can always minimize the risk of SQL injection by using prepared statements, provided your database engine supports them.
Anyway, prepared statements is probably the most secure way of blocking SQL injections.
The problem is building the SQL statement dynamically.
For example, you might want to order the result based on the column the user selected. In most databases, you can't use parameters here ("ORDER BY ?" doesn't work). So you have to "ORDER BY " + column. Now, if "column" is a String, then the user of your web-application could inject code there (which is not easy, but possible).
Related
In the go sql package, I understand that each statement should be closed after execution.
Why would someone use prepared statements instead of just the raw Query or Exec methods?
Prepared statement already bound to concrete connection to DB, contains low-level driver.Stmt and can be used concurrently by multiple go-routings. So it's quite handy to prepare and use, and things work faster.
I think the best answer comes from the wikipedia article on Prepared Statements.
Quoting:
The overhead of compiling and optimizing the statement is incurred
only once, although the statement is executed multiple times. Not all
optimization can be performed at the time the prepared statement is
compiled, for two reasons: the best plan may depend on the specific
values of the parameters, and the best plan may change as tables and
indexes change over time.`enter code here
Prepared statements are resilient against SQL injection, because
parameter values, which are transmitted later using a different
protocol, need not be correctly escaped. If the original statement
template is not derived from external input, SQL injection cannot
occur.
I work in a project where the UI has direct access to the database through SQL code. The company has a framework where we create UI pages in xml and after that it is parsed and creates FLEX pages. If we want some data from the DB (Oracle) we add a sql query in the xml (instead of databinding with a datacontext object like we could do with WPF). If we want to add some logic, there is no code behind, we call store procedures. After we have the data we need the parser does the job.
The new requirements are to use the framework and create a new product that will be compatible with SQL Server and the thoughts are to start transforming the (Oracle)SQL queries to ANSI SQL.
Can somebody tell me the benefits and mainly the problems that we are going to face doing that?
Do you think there is a better way?
Note: The framework is really big and there are a lot of products built on that so managers are not keen to just throw it away(I tried but.. :))
Each dialect of SQL is different. You could use ANSI SQL but a) not all of ANSI SQL is implemented by most DBMS and b) most DBMS's have implementation-specific optimisations which will perform better for some cases.
So I'd say, don't go for ANSI SQL. It won't always work and sometimes it will work slower than taking advantage of a vendor's non-standard implementations.
Specifically, Oracle requires a StoredProcedure to return a REF_CURSOR from a stored procedure to fill a DataSet. SQL Server doesnt; the SP returns what the sp SELECTed. You're going to have to change your SP's to get rid of the returned REF_CURSOR.
Date handling is quite different: Oracle needs a to_date to turn a string into a date in where clauses etc; SQL Server just takes the string and converts it for you. And so on and so on. (I'm not at all sure what the ANSI Standard is, or even if it covers this!) To avoid changing your SQL you could add create SQL Server function called to_date, but this is now going to slow up your SQL.
If you have much PL/SQL in stored procedures, you have a big job converting it to T-SQL. They are quite different.
Good luck!
As far as I know, PHP applications are prone to SQL injections when they require user input on a webpage form to send to a variable like $POST or $GET or $REQUEST. Does that mean if my application/htmlpage has no user input forms, it is completely free from SQL injections?
No, ANY user input can cause SQL injections. Say, for example that you perform a SQL query with parameters from the query string. If you haven't sanitized these parameters, you are still prone to SQL injection.
The best thing you can do is to never trust user input and always sanitize
To protect against SQL injection use prepared statements and parameterized queries
see : http://php.net/manual/en/book.pdo.php
On one of my customers sites I think I've found a big security issue.
I found out that when I entered an semicolon ' in the search box, the script threw an sql error. So I started playing...
Entering the SQL command below in the searchbox executes the query:
'+AND+product_description.description+LIKE+'%Computers%
The query is executed on the database!
Is it safe to say that a hacker can do harm with executing selects, inserts and delete queries too? Based on the fact that my query is executed I'm almost sure it should be possible to do harm... Am I right?
Yes, you're right. You should always sanitize the input and not use it directly in such a way, or it's sooner or later will be compromised by SQL injection attacks.
Yes, you are right. This code is open for sql injection attacks.
That definitely is a form of SQL injection, and you're correct in being worried.
However, that alone is not enough to tell whether or not you can do things other than alter the query parameters in unexpected ways. The query might for example be altered to retrieve data from tables not listed in the original query, which might well be bad enough.
I strongly recommend to avoid using string concatenation in building SQL queries, but instead using "prepared statements" which only allow to replace provided placeholders with the user-selected data values. Even there the application would be wise to check the values for at least some sanity before passing them on to the database-
Your site is open to SQL injection attacks, and there is a lot you can do to protect it, but first short term thing I would recommend is create a user-id with only read-rights and use this ID for all queries. Hackers will still be able to extract data from your database, but won't be as easy to update or delete rows or tables...
What is a dynamic SQL query, and when would I want to use one? I'm using SQL Server 2005.
Here's a few articles:
Introduction to Dynamic SQL
Dynamic SQL Beginner's Guide
From Introduction to Dynamic SQL:
Dynamic SQL is a term used to mean SQL code that is generated programatically (in part or fully) by your program before it is executed. As a result it is a very flexible and powerful tool. You can use dynamic SQL to accomplish tasks such as adding where clauses to a search based on what fields are filled out on a form or to create tables with varying names.
Dynamic SQL is SQL generated by the calling program. This can be through an ORM tool, or ad-hoc by concatenating strings. Non-dynamic SQL would be something like a stored procedure, where the SQL to be executed is predefined. Not all DBA's will let you run dynamic SQL against their database due to security concerns.
A dynamic SQL query is one that is built as the program is running as opposed to a query that is already (hard-) coded at compile time.
The program in question might be running either on the client or application server (debatable if you'd still call it 'dynamic') or within the database server.