> 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
