Re: SQL Problem

[CRPence <CRPbottle@xxxxxxxxx>]

  IMO SQL injection is defined better as "to embed extra text", not 
"to embed extra statements".  At least two examples of injection 
given on this list were DDL and\or dependent not only on a semicolon 
being interpreted as a statement separator, but also that the data 
following the semicolon would then be executed as an additional 
statement.  That probably depends too heavily on the full string 
being parsed first and then prepared as multiple distinct 
statements, and that the variable is a long enough string to hold 
multiple statements; i.e. unlikely in typical programming, since 
most programs will not be implementing a statement processor.?  Thus 
injection as I am aware, is almost never related to /additional/ 
statements, but to undesirable modifications to the intent of one 
dynamic statement which will be used in both PREPARE and EXECUTE.

  So more likely the injection attack is going to enable DML beyond 
what is intended, even with only a short character string variable. 
 So in the given case, if the user could compose the input noted as 
variable inFld2Value, then they will be presented with all data in 
the table irrespective of the attempt to effect an equivalence test 
on /fld2/, using the following quoted string: "'or 1=1"   Such an 
example allows the variable to be a very short char(7) string, and 
without any requirement of the program to parse semicolon delimited 
statements.  Change the given select statement to include an 
additional predicate fld1=USER ANDed prior to the predicate 
involving fld2 [i.e. obviously trying to limit the data visible to 
that specific USER].  That should make the negativity of the results 
for the injection of "' or 1=1" in the statement more obvious; i.e. 
user no longer limited to only data tagged as theirs, according to 
the value in fld1:
   select * from XYZ where fld1=USER AND fld2=''or 1=1

Regards, Chuck

Brian Piotrowski wrote:
> An injection attack occurs when you embed additional SQL commands
> into an external SQL statement.  Taking Charles' example, if you
> have:
>
> wSQL = 'select * from XYZ where fld2 = ' + QUOTE + inFld2Value +
> QUOTE;
>
> An injection attack could occur by adding additional commands
> within the inFld2Value parameter.  So if inFld2Value had a value
> of "a';DROP TABLE users; select * from users where t='", it would
> have the potential to not find anything in the first statement
> and then attempt to drop a table named users and then attempt to
> query the users table.