BugTraq
SQL-injection defensively Sep 02 2003 05:48PM
Alumni (alumni ok kz)


Copyright 2003 (c) Alumni

SQL-injection defensively

Questa materia fu mandato a memoria del giusto movimento,

"La Resistenza" di nome, del popolo italiano contro il fascismo,

anche a quel tempo durante la seconda guerra mondiale.

I. Problem stress:

While evaluating input data which being formed intentionally, the SQL-

processor (NB: vendor criteria is omitted here) can provoke execution of

inadeqaute statement (such occurence is enlightened well by various

security anlaysis). Oddly enough, our goal is to reduce the probability of

successful attack.

II. Solution(s):

1. The 1st one and very primitive on my point of view is to organize a

collection of numeric indexation.

Thus:

<input> -> convertation -> <input = [numeric]> ~ <the index table

corresponding given index>

As you see, this works as if it would be a filter which excludes the

symbols not belonging to given set of chars.

Besides, the index corresponding can be complex, it means that several

input numbers being converted such way that result remains unique (so-

called collide prevention).

Ex:

NO_MORE_SQL_INJECTION({1,2,3},55) = 1*55^2+2*55^1+3 (the upper bound of

index is 55).

2. The next solution is based on unicode scheme. The idea is in how to

avoid, as mentioned above, `inadeqaute SQL-statement execution`. Normally,

the input string can alter processing request:

SQL: select 'A' from X;

Input: A = ' from NULL; select * from Y--

Provoked: select '' from NULL; select * from Y--' from X;

Let's filter the incoming data, converting them into unicode:

Logically it can be figured as:

[input: A] -> [UNICODE(A)] -> [SQL-processing] -> [^UNICODE(A)] -> [DATA

PROCESSOR].

Thus,

SQL: select 'A' from X;

Input: A = ' from NULL; select * from Y--

Unicode:%27%20%66%72%6F%6D%20%4E%55%4C%4C%3B%20%73%65%6C%65

%63%74%20%2A%20%66%72%6F%6D%20%59%2D%2D

Processing: select '%27%20%66%72%6F%6D%20%4E%55%4C%4C%3B%20%73%65%6C%65

%63%74%20%2A%20%66%72%6F%6D%20%59%2D%2D' from X;

Data processor: possibly, entry "' from NULL; select * from Y--" cannot be

found in table X (the light in the end - attack stopped).

Thus, the method described above can be achieved in one occassion by

providing the `black` box architecture which gives a capability from

programmers side to manipulate data transmissions in spite of vendor's

license of distribution.

I'd be glad to see more debates on this issue, that's why I've posted it

to public newsletters, so that feel free to propose critical notions.

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus