On Tue, 5 Nov 2002, Ilya A. Kriveshko wrote:
> 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 pro
> I do not see a possibility of the aforementioned "DROP TABLE" exploit in
> this case. The only "unverified" data here is "id" and it is making its way
> into the query via two mechanisms that would ensure its safety:
>
> 1) Integer.parseInt()
> 2) PreparedStatement.setInt() that is generated by
> 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 ma
Antonio Gallardo Rivera wrote:
Just a question. Please dont take it wrong
Can you send a "DROP TABLE mytable" in the following example of a XSP page? I
am using mod-db stuff too.
I do not see a possibility of the aforementioned "DROP TABLE" exploit in
this case. The only "unverified" data here
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
Just a question. Please dont take it wrong.
Can you send a "DROP TABLE mytable" in the following example of a XSP page? I
am using mod-db stuff too.
SELECT * FROM mytable
WHERE mytable_id=
Integer.parseInt(
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
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:
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"?
Antonio Gallardo.
--
I just tried it. Logging in as
Donald Ball'; DROP TABLE employee;
does exactly what you think it would. It drops the
table and the next time you try to log in, the table
is gone and logins fail (DOH - does the hsql db get
regenerated automatically somehow?)
I have to run out but will put t
On Tue, 2002-11-05 at 19:53, Geoff Howard wrote:
> Speaking of protecting against SQL injection - is it
> generally known that DatabaseAuthenticatorAction.java
> is not using PreparedStatement? I wonder what logging
> in as
> Donald Ball'; DROP TABLE user_table;
>
> would do...?
Do you mind try
Speaking of protecting against SQL injection - is it
generally known that DatabaseAuthenticatorAction.java
is not using PreparedStatement? I wonder what logging
in as
Donald Ball'; DROP TABLE user_table;
would do...?
Geoff Howard
__
Do you Yahoo!
> For things like SQL, transformers and the sitemap simple filtering
> should do it. We just need to make sure each individual parameter is ok.
> Everything else is up to the webapp's decision. Plain filtering would
> solve problems where we cannot supply webapp-like logic. Your example is
> defini
> > That way is ok. But it doesn't really *enforce* security. It will just
> > give user that are already aware of the security hazards an easy way of
> > securing their system.
> > But IMHO that's the not the best way. We should enforce security as
> > default and only explicitly remove it for ce
> > String p = request.getParameter("id","id-filter");
> >
> > So filtering would be very easy and as close as possible to the request
> > but not really forced - it would be an option we should document and
> > promote very well.
> >
> > What do guys think?
>
> Torsten,
>
> call me boring, but
>> > As you say - it's crucicial. I think we should force this in any way.
>>
>> I can't think of a one-size-fits-all solution. There are areas where
>> input validation is impossible and unnessary, too.
>
> What areas do you have in mind? I could think of the whole webapp/forms
> area. Anything e
Okay, modify my statement to read:
Not everyone uses $$$ DBs or PostgreSQL.
The general though is preserved though. :-)
--
Ilya
Luca Morandini wrote:
Not everyone uses $$$ DBs. We, the lowest common denominator, get offended
when not taken care of... :-)
Ilya, you might be oblivious of th
TECTED]
> -Messaggio originale-
> Da: Ilya A. Kriveshko [mailto:ilya@;kaon.com]
> Inviato: martedì 5 novembre 2002 16.05
> A: [EMAIL PROTECTED]
> Oggetto: Re: R: A case of SQL injection
>
>
> Luca Morandini wrote:
>
> >Torsten,
> >
> >call
>> String p = request.getParameter("id","id-filter");
>>
>> So filtering would be very easy and as close as possible to the request
>> but not really forced - it would be an option we should document and
>> promote very well.
>>
>> What do guys think?
>
> Torsten,
>
> call me boring, but, wouldn
Luca Morandini wrote:
Torsten,
call me boring, but, wouldn't it be better using stored procedures over
dynamic SQL ?
Our aim is to have stored procedures implemented in MySQL Server
around version 5.0.
Not everyone uses $$$ DBs. We, the lowest common denominator, get offended
when not tak
> -Messaggio originale-
> Da: Torsten Curdt [mailto:tcurdt@;dff.st]
> Inviato: martedì 5 novembre 2002 15.25
> A: [EMAIL PROTECTED]
> Oggetto: Re: A case of SQL injection
> String p = request.getParameter("id","id-filter");
>
> So filtering wo
> > As you say - it's crucicial. I think we should force this in any way.
>
> I can't think of a one-size-fits-all solution. There are areas where
> input validation is impossible and unnessary, too.
What areas do you have in mind? I could think of the whole webapp/forms
area. Anything else?
>
On 05.Nov.2002 -- 11:52 AM, Torsten Curdt wrote:
> > As the document points out, input validation is crucial. Cocoon offers
> > input validation through XMLForms and the *ValidatorActions,
> > e.g. the FormValidatorAction.
>
> As you say - it's crucicial. I think we should force this in any way.
On Tuesday 05 November 2002 12:26, Leo Sutic wrote:
> > From: Christian Haul [mailto:haul@;dvs1.informatik.tu-darmstadt.de]
> >
> > Another important aspect is not to compose a query from
> > strings but use PreparedStatements for that.
>
> IMO, input validation is a bad patch and *this* is the cor
> From: Christian Haul [mailto:haul@;dvs1.informatik.tu-darmstadt.de]
>
> Another important aspect is not to compose a query from
> strings but use PreparedStatements for that.
IMO, input validation is a bad patch and *this* is the correct
solution.
The fundamental security flaw is the mixin
> > Today I have been thinking about what would really patch the security
> > hole. What we're talking about here, by the way, is a phenomenon called
> > 'SQL Injection', a term which should be familiar to every developer of
> > web applications that interface with an SQL database. If you don't kno
[EMAIL PROTECTED] wrote:
[snip]
>I refer to the pdf
>
>http://www.nextgenss.com/papers/advanced_sql_injection.pdf
Wow, very interesting read. I for one wasn't aware of this problem. It's really nice
to have a sysadmin sharing his experiences. Us
On 05.Nov.2002 -- 12:26 AM, Carl M?sak wrote:
[...]
> Today I have been thinking about what would really patch the security
> hole. What we're talking about here, by the way, is a phenomenon called
> 'SQL Injection', a term which should be familiar to every developer of web
> applications that in
Hello you list people,
I joined this list just a few minutes ago in order to ask you all a
question. I have not read the archives of the list discussion, so I might
be completely off topic. In that case, sorry for my being clumsy. On the
other hand, I might be asking a very common or often discuss
29 matches
Mail list logo
