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?
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.