Home page logo

bugtraq logo Bugtraq mailing list archives

Re: All the recent SQL vulnerabilities
From: ksoze () OBSCURITY ORG (Keyser Soze)
Date: Tue, 29 Feb 2000 20:58:43 -0800


SQL has identities and most of the SQL games could be stopped by using a
sharply limited indentity to query the database (column, table and database
access control is included in standard SQL). Obviously this is not a
substitute for programming it properly in the first place but could limit the

Agreed. You can think of your server software as just another database
client. Like any other client, it shouldn't be trusted more than it has to

If your database supports it, triggers can be very useful for creating an
audit trail in another tablespace. This way even if an attacker is able to
run his own SQL statements you are keeping track of what he did. It
doesn't help you if the he drops your tables, (and as you already said,
your application probably shouldn't have permission to do that anyway) but
it can save you if he updates some specific data - such as an account
balance. Oracle does this well.

In particular the code that can be manipulated to change prices in multiple
shopping carts (ISS X-Force, 3rd of February) does not need an identity that
can change the prices. I suspect the wwwthreads code, RFP2K01 (also 3rd of
February), does not need write access for its intended results. Am I missing
something or are the database queries not doing the moral equivilent of
running everything as root and hoping the, usually sadly lacking, input
validation saves the system?

Don't give developers DBA access! 99.99% of the time they will cut
corners. Make them ask you for specific permissions and make them justify
those requests. If you are a developer, then don't test your software with
DBA access. Think about what access you grant your application's user.


Version: 2.6.3a
Charset: noconv


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]