cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: A case of SQL injection
Date Tue, 05 Nov 2002 10:52:09 GMT
> > 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 know
> > about this security hasard, and your webapp uses SQL, you are through
> > inaction placing your information, and thereby your users, at the mercy
> > of competent (and not so competent) hackers!

Ok, guys - that's exactly what I feared to happen!

> > I refer to the pdf
> >
> >
> >
> > for more information. Be aware that more than simple removal of 'bad
> > characters' is needed in order to protect oneself fully -- ample examples
> > and reasons are given in the paper.
> >
> > My question, finally: Could future versions of Cocoon protect against
> > this type of 'database rape' -- for example in the class
> 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.

> Another important aspect is not to compose a query from strings but
> use PreparedStatements for that. This way the driver takes care that a
> parameter is just a parameter and not a command. All the database
> actions do that. ESQL does that, too, if the <esql:parameter/> tags
> are used.

You are true most ESQL pages are save due to the use of prepared statements.
But I doubt people use in only it that way. This should at least stated in the 
docs explicitly. I know we cannot make it save against every abuse - but we 
can make it harder for every unaware user.

But we encounter this problem (not only SQL related) everywhere. That's now 
even worse since be provide an easier way to incorporate external variables 
into the sitemap. That's exactly where the Filter proposal was aiming at! 

> I don't see what could be done further.

We could even filter at Request level! But that's kind of problematic since we 
the Request has almost a per page page context of what is allowed and what is 

  page1.html - request accepts attribute "sid" being a number
  page2.html - request accepts attribute "aid" being a regexpr [...] (but not 
  and even combinations!

So I that's why I though the InputModules are now the preferred way to include 
such facility. If every external variable would come from an input module we 
could easily force security with them.

Of course the closer to request the saver it is... since then there is no way 
around it. But this would need incompatible changes - which most likely a 
Although we could sell it as security fix ;-)


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

View raw message