views:

126

answers:

2

What is all about the second level SQL Injection.. This is with reference to the question http://stackoverflow.com/questions/1819377/use-of-parameters-for-mysqlquery.. and a part of one of the answers had this term...

+2  A: 

I'm not exactly sure but I thought it was 'defined' in the post: http://stackoverflow.com/questions/1819377/use-of-parameters-for-mysqlquery/1819417#1819417

Excerpt (see point 2):

magic_quotes_gpc automatically escapes things you receive in requests from clients... but it cannot detect so-called second-level injections:

  1. You get a malicious query from a client and store its contents in the database. magic_quotes_gpc prevents SQL injection; the malicious string gets stored correctly.
  2. Later on, you fetch this string from the database and include it in another query. Now the string didn't come out of a request, so magic_quotes_gpc doesn't escape the string. Voilà, SQL injection; your data is now probably gone.

Here's another I've googled (http://www.osix.net/modules/article/?id=624):

Beware that variables inside a stored procedure aren't always immune to SQL Injection either. If the stored procedure contains constructs that add a second level of parsing, such as EXEC on a string in MS SQL Server, you will have to handle metacharacters again. This time inside the stored procedure.

o.k.w
A: 

If you just never assume ANY data is "safe" to put into a query, then you shouldn't have any problems with SQL Injection. Even if <insert religious icon> him/herself hands you piece of data and tells you to insert it into SQL query... you should still verify it! xD

It's a good idea to try to always use Parameterized Statements when executing queries. That way the database driver itself is responsible for escaping potentially harmful data, vastly reducing the risk of any type of SQL injection.

Atli