> > 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! http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103407759808238&w=2 > > I refer to the pdf > > > > http://www.nextgenss.com/papers/advanced_sql_injection.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 not. page1.html - request accepts attribute "sid" being a number page2.html - request accepts attribute "aid" being a regexpr [...] (but not sid) ... 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 blocker. Although we could sell it as security fix ;-) Comments? -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
