TUCoPS :: Web :: Apps :: bt989.txt

SQL-injection defensively




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.

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH