cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya A. Kriveshko" <>
Subject Re: R: R: A case of SQL injection
Date Tue, 05 Nov 2002 21:44:29 GMT

Antonio Gallardo Rivera wrote:

>El Martes, 05 de Noviembre de 2002 15:16, Torsten Curdt escribió:
>>On Tue, 2002-11-05 at 18:43, Antonio Gallardo Rivera wrote:
>>>El Martes, 05 de Noviembre de 2002 09:28, Ilya A. Kriveshko escribió:
>>>>Okay, modify my statement to read:
>>>>Not everyone uses $$$ DBs or PostgreSQL.
>>>>The general though is preserved though. :-)
>>>Sorry for the question, but: Why Cocoon must do the work of "DBMS"?
>>Sorry - I lost the context... what do you think is the work of "DBMS"
>>that cocoon is not supposed to do?
>It was about the use of "stored procedures" in the DBMS (Database Relational 
>Managment System) or "Databa Engine". Some one before called that MySQL have 
>not support of that. Then my answer was to respond of that. :-D

I do not see my statement as implying that Cocoon must do anything extra.
All my reply meant to indicate was that stored procedures were not always
an available functionality, and therefore this alleged "better" choice 
may not
even be a choice.

DB programming is not my specialty, so I don't know what the
consensus is among the specialists on the proper method of
checking supplied data and constructing dynamic queries (which
was the subject of the thread).

I find that most of the time using PreparedStatements and using
client-assembled dynamic queries has always fit the design and
implementation criteria in all applications that I have developed.
Therefore I do not have practical experience with stored procedures,
although I'm familiar with the concept.

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.

Also, why would you be sorry about asking a question? ;-)

To unsubscribe, e-mail:
For additional commands, email:

View raw message