Skip to Content.
Sympa Menu

freetds - Re: hints for writing a proxy?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT umcc.ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: hints for writing a proxy?
  • Date: Tue, 23 Feb 1999 20:09:08 -0500 (EST)



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





Archive powered by MHonArc 2.6.24.

Top of Page