bugtraq - SQL-injection defensively

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20030902174839.21134.qmail@sf-www1-symnsj.securityfocus.com>
Date: 2 Sep 2003 17:48:39 -0000
From: Alumni <alumni@...kz>
To: bugtraq@...urityfocus.com
Subject: 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.