views:

140

answers:

1

Castle Project is full of features, includes some awesome subprojects, and developing with it has been a pleasure.

My team is almost ready to deliver a custom made EAM and we are polishing our system. We tried some basic XSS attacks and guess: They all worked.

Even though it will be running in a Intranet environment, we wouldn't like users to accidentally break the whole system, and we are studying solutions to handle XSS problems.

NVelocity by default doesn't escape anything, so this code:

${entity.Field}

with Field containing things like:

<script>alert('xss!')</script>

would give us a nice xss alert.

Microsoft's AntiXSS library looks good: handles several types of possible XSS vectors, and so. We ran into AndyPike's helper, but this solution would make us refactor some couple thousand lines. Yeah, not good. And this wouldn't handle ActiveRecord/NVelocity auto bind when editing existing entities.

The question is: Using output encoding techniques, is it possible/recommended to patch Castle Project's NVelocity engine? Just like they did with Brail? Anyone has a better idea?

Thanks!

PS.: Stackoverflowers using Castle Project would use such patch?

A: 

NVelocity by default doesn't escape anything

Oh dear. Then you've got a lot of code-fixing to do.

Failing to escape text being put into HTML is not a failing you can correct after the fact. Yes, there are libraries that will filter out obvious bad input, but they're only hiding the problem, and not very well. Given the wide range of odd constructs browsers will accept, there will always be ways to sneak bad HTML through them, and at the same time they will be giving you false positives – for example this post would be blocked for discussing the tag <script>.

They are at best a temporary sticking plaster until you can fix the real problem.

bobince
What do you mean by, "for example", your post would be blocked? Escaping values when inserting it into HTML would give you pretty much the same thing you get here in SO. Wouldn't it?
wtaniguchi
Yes. If you escape text when adding it into HTML, you're doing it right. What I mean is that if SO were doing it wrong (like NVelocity apparently is), and then tried to cover that up by using one of the ‘anti-XSS’ input filters, it would have negative side-effects like either blocking or mangling valid user input like us talking about `<script>`. As well as not actually being watertight.
bobince
NVelocity does not escape anything when getting the input value or adding it into HTML.I'm trying to get NVelocity to render escaped values by default, but this is going to be a long ride...
wtaniguchi
Indeed. Fixing up an old app with no output-escaping is a long and tedious task but the only way that'll properly work in the end. (Nothing should be escaped on getting input values.)
bobince