IARC prod tool throws XSS error for some developers

VERIFIED FIXED in 2014-01-28

Status

Marketplace
Developer Pages
P1
normal
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: cvan, Assigned: robhudson)

Tracking

2014-01-28
Points:
---

Details

(Whiteboard: [incorrect_implementation], URL)

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
From a developer via the app-reviewers mailing list:

> When I click on the Developers  My Submissions Pay Ontime Content Ratings -->  Create an IARC Ratings Certificate button the page throws error. Please refer the attachment for further details

Can someone investigate and/or contact the IARC?
Assignee: nobody → cmccarthy
Severity: normal → critical

Comment 2

4 years ago
Christine, it seems like a developer has angle brackets in their company name and is not accepted as valid input in the IARC tool.
Assignee: cmccarthy → nobody
Severity: critical → normal

Updated

4 years ago
Summary: IARC prod server is down → IARC prod tool throws XSS error for some developers

Comment 3

4 years ago
It works for my apps on prod, maybe since I don't have an angle bracket in my developer name.

Comment 4

4 years ago
I will  keep look at whether we can yank the .net built-in form security reasonably safely to allow for angle brackets. If not, we may have to parse and encode angle brackets when submitting them. I will look at it first thing in the morning.
(Assignee)

Updated

4 years ago
Duplicate of this bug: 962660
(Assignee)

Comment 6

4 years ago
FWIW, in the form the angle brackets are escaped, e.g.:

  <input type="hidden" name="company" value="Robérto &lt;yolo@hy.fr&gt;">

Comment 7

4 years ago
Rob, I've managed to recreate this on our end. When I pass the string as you indicate above (with the brackets escaped) it seems to go through cleanly. But when I pass angle brackets themselves, the error occurs. We will be looking at how we can get this addressed quickly and will keep you updated.

Comment 8

4 years ago
Here is the current situation, and I'd like a sense from your end on which way we should go.

1. We don't have a quick solution to accepting unencoded angle brackets, but are continuing to work on finding one.

2. We could remove validation from the page, which would allow unencoded angle brackets through, but would also open us to some potential security issues, and so would have to be a temporary measure, but could be implemented quickly.

3. In our testing, HTML encoded angle brackets submit cleanly regardless.

So, the next move really depends on whether this is preventing your users from being able to make their submissions. If it is, we can put the temporary fix in place while we work out the permanent fix. I would also be interested in having you test the encoded vs. decoded brackets, since Rob said you were already sending them encoded, and we didn't have any problems when we were encoded.
(Assignee)

Comment 9

4 years ago
We're encoding the values in the form but when they are POSTed they get converted to true angle brackets. We can double encode them so you actually get the "&gt;" and "&lt;" values. The only problem is this isn't representative of what we actually store on our end, which is "Rob <me@example.com>". It's only HTML encoded so it doesn't cause XSS problems when displayed in HTML.

Alternatively could you not HTML encode this form field on your side? Or does the framework security kick in before you even get the data?

Comment 10

4 years ago
We're looking into exactly where the framework security kicks in, we're not currently sure if it's the moment the form arrives with angle brackets, or not until we start trying to use the form variables. That's the permanent fix we're currently hoping to put in place.

We are comfortable with having a slight variation in our stored data, as the encoded values should continue to display correctly when printed to screen, if you'd like to try double encoding to get everything working quickly. We will continue pursuing answers for the unencoded angle brackets regardless.
(Assignee)

Updated

4 years ago
Assignee: nobody → robhudson.mozbugs
Target Milestone: --- → 2014-01-28
(Assignee)

Updated

4 years ago
Blocks: 929812
(Assignee)

Comment 11

4 years ago
https://github.com/mozilla/zamboni/commit/12f1849 

To verify, submit an app with developer.name in the manifest containing HTML characters (e.g. "Rob <rob@example.com>"). On the content ratings step of the submission process, view page source and ensure that the "company" field is double escaped.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 12

4 years ago
Verified as fixed in https://marketplace-dev.allizom.org/developers/ on FF29 (Win 7).
Attaching postfix screenshot.
Closing bug.
Status: RESOLVED → VERIFIED

Comment 13

4 years ago
Created attachment 8364927 [details]
postfix_html_escaped.png

Updated

4 years ago
Whiteboard: [incorrect_implementation]
You need to log in before you can comment on or make changes to this bug.