442158 - Verbatim should filter input

Status: RESOLVED FIXED

(Webtools Graveyard :: Verbatim, defect)

Description

[Dan Schafer [:dschafer]]

Verbatim needs to filter its input, to make sure that there's no bad stuff in there (Javascript, XSS)...

Comment 1

[Friedel Wolff]

Are you referring to translations being entered? With the use of Kid in the templating, mostly the library takes care of escaping. There are only a few places where we work with raw HTML, for example diffing, and displaying translations a little more marked up (fancy spaces, colour highlighting). A while ago I had a quick look at XSS possibilities and didn't find anything, but this is not something I'm very experienced in.

Comment 2

[Dan Schafer [:dschafer]]

Yeah, XSS in translations is what this bug refers to.  I wasn't able to find any sort of XSS vulnerabilities either, but I also have little experience in this area.

Comment 3

[Israel Saeta Pérez]

If Kid escapes any data entered by the user, we don't have to worry about Cross-Site Scripting (XSS).

Lack of form validation would be a different issue; for example, a malicious user could select an inexistent interface language and cause a server error. Are we using any form validation framework?

Comment 4

[Wil Clouser [:clouserw]]

(In reply to comment #3)
> If Kid escapes any data entered by the user, we don't have to worry about
> Cross-Site Scripting (XSS).

Yeah, Kid does escape any input unless it's filtered through XML() in the template (which doesn't happen often)

> 
> Lack of form validation would be a different issue; for example, a malicious
> user could select an inexistent interface language and cause a server error.
> Are we using any form validation framework?
> 
As long as the "server error" is just returning a 404 or 500 I don't care.  If it breaks the server like bug 449445 then we've got problems.  Either way, we're not using a separate validation framework right now.

Comment 5

[Israel Saeta Pérez]

(In reply to comment #4)
> (In reply to comment #3)
> > Lack of form validation would be a different issue; for example, a malicious
> > user could select an inexistent interface language and cause a server error.
> > Are we using any form validation framework?
> > 
> As long as the "server error" is just returning a 404 or 500 I don't care.  If
> it breaks the server like bug 449445 then we've got problems.  Either way,
> we're not using a separate validation framework right now.

But you don't know in advance what invalid data will break the server and what won't. In my opinion, all data coming from the user browser (forms, GET parameters, etc) should be validated to avoid potential issues. If not now, it should be planned for a future release.

Bug 449445 is about a Firefox freeze, was that a typo?

Comment 6

[Wil Clouser [:clouserw]]

Absolutely; we won't trust user input implicitly, but if a user enters something malicious and the only consequence is the server giving them a 404 or 500 it's pretty low on my list of bugs - it just depends on how you're defining "break the server" I guess.

And yeah, I meant bug 449455 - that kind of server breakage is not a good thing.

Comment 7

[Israel Saeta Pérez]

For example, entering an invalid language name and not being able to login again is not acceptable in my opinion.

404's are low on my list too, but what I mean is that not validating user input can lead to unforeseen critical bugs.

Comment 8

[Israel Saeta Pérez]

I've never used it but it deserves a quick look at least:
http://www.formencode.org/

Comment 9

[Wil Clouser [:clouserw]]

jtoolkit has this built in and the new platform, django, has it's own setup.  This bug could stay open forever so I'm calling it fixed and if anyone sees specific problems please open new bugs.