[thelist] The URL SemiColon Exploit

[Eric Engelmann]

	<snip>
	there's a way to pass any SQL Server command via
	the URL by simply adding a semicolon at the end of
	the address, followed by the SQL command.
	</snip>

To be clear for any newbie-types that might misconstrue that, your
ASP/CF/PHP/Whatever script has to be using a URL variable in a SQL
statement. Just typing this type of stuff in any old URL won't do anything
to your SQL Server.

	<snip>
	while the other DSN was unlimited in ability - but only available to
administrative pages.
	</snip>

Is there ANY reason why ANY web-based user should have admin rights to drop
tables, etc? Most web apps don't ever need this power. Removing DROP, DELETE
etc. from any web-accessible user privilege can help minimize damage, but
UPDATE is almost as powerful.

	<snip>
	Does this sound like a good way to defeat the use of the semicolon exploit?
	</snip>

Not really.

The problem is mostly sloppy coding as Matt points out.

Additional Problems:
--------------------
* There are other characters, too, that can be used (though I don't recall
the list exactly, I think the pipe char |, apostrophes and semicolons were
common ways to try to mess with various dbs and SQL strings). You might also
have to check for the various encoded versions of these characters, like %36
or whatever the encoded chars might be.
* Not just querystring, although this is easiest. Its possible to do the
same thing via a Form, Cookie or any other user-input mechanism if you've
coded your site to use those input methods.
* this is not just SQL Server. It will work, I think, with any SQL database
if you're executing dynamically constructed SQL statements created by script
and the user has the proper permission level.

You can prevent this, in general, by:
-------------------------------------
* Don't concatenate SQL Strings in your script and execute them!!! Use
stored procedures, pass typed parameters.
* Validating all input (e.g. if you expect an integer, make sure you get
one)
* Keeping your server patched (e.g. if you are vulnerable to file read
vulnerabilities in IIS, for example, your DSN info or logic in
application.cfm may be visible, passwords if they're in there, to script
kiddies)
* Turn off error display to end users. (e.g. Why tell your hacker friends
your SQL syntax:

	SQL=select headline from tblnews where itemid=123a
	Line 1: Incorrect syntax near 'a'.

)
* Never use .inc as a file extension (or any other non-parsed ext)  for any
db/script stuff unless you map it to cold fusion, ASP etc. Its SO easy to
hunt down db logic in random text-based files that aren't parsed. This gives
the hacker your db structure, SQL statements, and possibly connection info.
* Modifying SQL permissions so that the Internet user only has SELECT,
UPDATE or INSERT rights, as needed.
* Cache db info in RAM, so users aren't actually hitting the db, and cache
updates happen programmatically, not in response to user request (depends on
your application, may not be an option).
* Protecting your server with a filter (if you're using IIS, install the
URLScan utility, alone or as part of the lockdown wizard:

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/
tools/tools.asp )

<sidenote related="kinda">
Its scary to have IIS with URLScan on a freshly formatted box, and watch
within minutes of plugging it into the 'net how many Code-Red-type variants
ping your box looking for vulnerabilities! Typically hundreds of them in the
first couple of hours. IIS deserves its reputation, and URLScan has been a
much needed tool.
</sidenote>

I'm not sure that checking every URL is the best way to do this, sounds like
a performance drain (if that's what you're doing, I'm not a CF-type guy).
Instead, as Matt says, just run a CheckInput function that cleans up any
provided input from QueryString, Form, cookie or other variables ONLY on the
pages that would use it. There's lots of reasons you might pass a semicolon
in the URL in day-to-day web programming.

Sorry this turned into such a book! Hope its helpful.

- Eric