FreeTDS Development Group

[Brian Bruns <camber AT umcc.ais.org>]

On Tue, 23 Feb 1999, Greg Beeley wrote:

> Hi all,
>
> One very useful thing to do is to monitor the SQL statements sent via the
> proxy so that such statements can be limited to, for example, small result-
> set select statements and no inserts/updates/deletes/select-into/etc.  That
> can _help_ prevent, for example, someone from SELECTing your entire database
> who shouldn't be able to do that (for example, online address book; you want
> people to be able to look up someone based on certain criteria that they
> already know, but want to make it very hard for someone to grab the whole
> database by entering no or too few criteria into the query form).  And, if
> you've got a firewall, that's a very good place to put some extra security
> assurance for this issue.
As far as limiting results returned, this could be accomplished by
sticking a call to 'set rowcount' between the login and the first query,
easy enough to do. Much else and you pretty much need a full sql parser to
figure out what they are doing (ie 'select into' is an update :)

> 
> I could see the possibility of using the existing FreeTDS code in a modified
> form to keep track of the 'state' of the TDS connection.  I've looked mostly
> at the JDBC driver; anyone have ideas about how easy it would be to pull the
> protocol analysis parts of the FreeTDS code out without having to use the 
> parts of the code which must be 'instructed' on what to do?  (i.e., you
> can keep track of the status of a proxied result set, but you don't want to
> have to tell the TDS code what the query was before it will listen for that
> result set).
Theoretically, you could process only the return results (the library
doesn't really care/know what the query was in the first place). So you
could do upstream as a passthrough and put filters in the downstream code.
This is actually something I've considered as a means to implement row
level security.

The opposite is much harder to do though (again, need a parser that
understands T-SQL). Even then, who knows what a stored proc is doing.
> 
> --------
> Greg.Beeley AT LightSys.org
> 

Brian