Verbatim should filter input

RESOLVED FIXED

Status

--
blocker
RESOLVED FIXED
11 years ago
3 years ago

People

(Reporter: dschafer, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Updated

11 years ago
Severity: major → blocker
(Reporter)

Updated

11 years ago
Priority: -- → P1

Comment 1

11 years ago
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.
(Reporter)

Comment 2

11 years ago
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.
Priority: P1 → --
(Reporter)

Updated

11 years ago
Assignee: dschafer → nobody
Status: ASSIGNED → NEW
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?
(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.
(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?
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.
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.
I've never used it but it deserves a quick look at least:
http://www.formencode.org/
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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.