cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: R: R: A case of SQL injection
Date Tue, 05 Nov 2002 22:34:03 GMT
> With my limited knowledge of this subject (BTW, I'm not insecure -
> I'm polite) I don't see data checking as the job of the DBMS. DBMS
> simply maintains the data, executes queries that the client provides,
> returns the results and ensures that proper side-effects occur.
> If DBMS executes a malicious query that the client application
> mis-constructed, then the client app is to blame. If the client
> application relied on some infrastructure to help it ensure security
> of the operation, then where I'd place the blame would depend
> on the "contract" between the infrastructure and the client - including
> any explicit documentation and API.

It actually is pretty common to wrap all database access in stored
procedures.  Mainly for three reasons:

1) isolation of the database implementation from the client code;

2) security;

3) performance

All of these would seem to have some appeal to the average Cocoon developer.
However, until one can be assured of the implementation of ANSI standard
stored procedures I also don't see how a cross platform tool like Cocoon can
move such issues down to the database...

Coincidentally enough this was a topic in eWeek's latest "openHack":

	http://www.eweek.com/article2/0,3959,643205,00.asp 

MS's approach was to use stored procedures to secure the SQL server used in
the challenge.  Quoting from the article: "It's a lot easier to guard
against SQL injection attacks because the database strongly types the data"

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message