If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Verbatim should filter input

RESOLVED FIXED

Status

Webtools Graveyard
Verbatim
--
blocker
RESOLVED FIXED
9 years ago
2 years ago

People

(Reporter: dschafer, Unassigned)

Tracking

Details

(Reporter)

Description

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

Updated

9 years ago
Severity: major → blocker
(Reporter)

Updated

9 years ago
Priority: -- → P1

Comment 1

9 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

9 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

9 years ago
Assignee: dschafer → nobody
Status: ASSIGNED → NEW

Comment 3

9 years ago
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.

Comment 5

9 years ago
(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.

Comment 7

9 years ago
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

9 years ago
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: 9 years ago
Resolution: --- → FIXED
(Assignee)

Updated

2 years ago
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.