I forgot to mention it here, but I built my proof of concept context-aware output encoding. You can find more about it here:
http://blog.ivanristic.com/2010/09/introducing-canoe-context-aware-output-encoding-for-xss-prevention.html It's a standalone tool, but I also have a Velocity interface layer. At the current level of maturity, the tool is useful for two reasons: 1) It controls where input data can be written, in an HTML page. This is important because not all output variants are safe. For example, writing to a HTML context is safe, but if you're writing into a JavaScript context, there are ways to execute JavaScript no matter what. 2) Correctly encode the output in the safe contexts from #1, above. I do think the tool can be made foolproof, but that would require a JavaScript parser, which is too much work for me. I am happy as it is, restricting output to the safe locations. On Fri, Apr 23, 2010 at 9:17 AM, Ivan Ristic <[email protected]> wrote: > Thanks for all your suggestions. Here's what I have found out so far. > > My first attempt was to use a custom ResourceManager, which was > straightforward. I inherited from the existing implementation and > gained access to the parsed document tree. However, it is only then > that I realised that working with templates may not produce accurate > results when there is a lot of conditional logic involved. Templates > may contain many output pieces, of which only some will end up in > output. I had doubts that I would be able to correctly parse HTML, > JavaScript and CSS in that situation. > > My second attempt was thus aimed at seeing the output. I haven't > implemented this approach yet, although (after some testing) I think I > figured out how to do it. It goes something like this: > > MyWriter writer = new MyWriter(); > writer.setContentType("text/html"); > MyReferenceInsertionHandler insertionHandler = new > MyReferenceInsertionHandler(writer); > > EventCartridge ec = new EventCartridge(); > ec.addReferenceInsertionEventHandler(insertionHandler); > ec.attachToContext(velocityContext); > > template.merge(velocityContext, writer); > > The idea is to have a Writer instance that parses output in real time. > There's only one insertion handler associated with a template merge. > It's job is simply to retrieve the actual insertion handler from the > writer instance. The writer will know which output escaping strategy > to use because it has parsed the output. A workaround could be added > to allow for unescaped output. > > Setting the above up is easy, but finding good HTML, JavaScript and > CSS parsers requires more work. I wonder what the performance impact > will be. Having to parse output at real-time is certainly not ideal, > but my goal in this exercise was to arrive at something truly > foolproof. > > I am done with this for the time being, but I hope to revisit it as > some point in the future. > > -- > Ivan Ristic > ModSecurity Handbook [http://www.modsecurityhandbook.com] > SSL Labs [https://www.ssllabs.com/ssldb/] > -- Ivan Ristic ModSecurity Handbook [http://www.modsecurityhandbook.com] SSL Labs [https://www.ssllabs.com/ssldb/] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
