> 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
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
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(
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
>> > 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
>> 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
> > 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
17 matches
Mail list logo
