According to Florian Hars: > On Fri, Oct 19, 2001 at 09:22:00AM -0500, Gilles Detillieux wrote: > > I have to disagree with you on this point. Whether the default syntax > > is insecure or not depends totally on the context in which the template > > variable is used, and how that template variable is generated. > > No, it doesn't depend on the context. The default syntax passes client > supplied data unchanged and untested to the result page. This is something > that should never happen, under no circumstance.
OK, so assuming you use what you call the default syntax (i.e. $(var)) on a template variable that contains untested client data, does that mean that client data could compromise security in any context. Perhaps, although the exploit might have to be adapted to the particular context. So, maybe context is irrelevant as far as security is concerned. However, it's not irrelevant as far as choice of encoding is concerned. E.g. you don't use hex encoding in the middle of HTML text, but you can use it in a URL inside an <a ...> tag. > Things like STARSLEFT are totally different, they do not use client > supplied information and so are not vulnerable to cross site scripting > attacs. WORDS is. This is the main point I was trying to get across. Different variables have to be used in different ways! If we changed the behaviour of $(var) to SGML encode everything, it MIGHT make every exisiting template out there more secure, but it would almost CERTAINLY make them all unusable. I don't see this as the lesser of two evils. If we were to make a design decision of deliberately breaking any old template files out there to force users to adopt a more secure configuration, why not be honest about it and adopt an entirely new syntax for all template variable substitutions? As someone who ends up answering over 50% of the support requests on this list (many from people who never so much as glance at the FAQ), I'm not about to add to my workload by taking such a radical step. The default template files all use the correct syntax for the variables they use and the context in which they're used. So, for a fresh 3.1.5 or later installation, without old template files, you should be safe from cross-site scripting attacks. As distributed, htsearch is secure by default, regardless of what we choose to call the "default syntax". For sites that don't want to update their templates, that's their choice. Given the number of users I've seen on this list that are are still using pre-3.1.5 versions, which are far more blatently insecure than 3.1.5 with old templates, it's pretty clear that a lot of users don't see security issues as a big problem for their sites. I'm not about to make that my problem. If you feel so strongly about this issue, that under no circumstance should we release htsearch as it is, I suggest you volunteer your time as a developer, put the issue to a vote among the developers, implement it as you see fit if the vote passes, and stick around to deal with the fallout. As I often say, this isn't a one-man show. -- Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil Dept. Physiology, U. of Manitoba Phone: (204)789-3766 Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930 _______________________________________________ htdig-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/htdig-dev
