Closed Bug 477032 Opened 16 years ago Closed 16 years ago

FEBE extension processes server response in an unsafe way

Categories

(addons.mozilla.org :: Security, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jwkbugzilla, Unassigned)

References

()

Details

Looking at content/boxnet.js, there is a function febeprt() that processes incoming messages in like this: var box = document.getElementById("messages"); txt = "<span style='font-family: Courier New,Courier,monospace; font-size: 12px; color: "+color+";'>"+txt+"<br></span>" box.contentDocument.write(txt); The document that includes boxnet.js is content/BoxNet.html which is opened as a chrome dialog on uploads, the messages frame has about:blank loaded (meaning that it inherits chrome privileges). One particular caller of the febeprt() function is febeUpload() function, the processing of the server response contains the following code: case "upload_some_files_failed": var resp = req.responseText; var domParser = new DOMParser(); var xmldoc = domParser.parseFromString(resp, "text/xml"); var response = xmldoc.getElementsByTagName('response')[0]; var files = response.getElementsByTagName("files")[0].firstChild var err = files.getAttribute("error"); var fname = files.getAttribute("file_name"); febeprt(febeMsg[124]+" "+fname+": "+err+febeMsg[105], "red"); No sanitizing is performed, neither here nor in febeprt(). This means that the server can decide to return "<script>alert(Component.classes)</script>" in either "error" or "file_name" attribute and that script will execute with chrome privileges. Server URL is http://upload.box.net/, so it isn't even an encrypted connection. There is similar code content/febeVerifyext.js but from what I can tell it only deals with local data - meaning that it isn't security relevant. For reference: https://developer.mozilla.org/En/Displaying_web_content_in_an_extension_without_security_issues
The developer has been emailed
Wladimir, reading the reference you supplied would seem to indicate that adding type="content" to the iframe tag in content/BoxNet.html would fix the security issue. Is this correct?
Yes, type="content" should fix that issue - about:blank inherits privileges from its parent, if it becomes the top frame it will have no privileges. However, I would at least switch off JavaScript and plugins for that frame as well. And escaping the HTML characters in message text certainly wouldn't harm either: txt = "<span style='font-family: Courier New,Courier,monospace; font-size: 12px; color: "+color+";'>"+txt.replace(/&/g, "&amp;").replace(/</g, "&lt;").replace(/>/g, "&gt;")+"<br></span>" Meaning - if you really want to choose the route of generating HMTL code of course.
FEBE 6.0.4 just uploaded to AMO. The only changes are the type="content" params in the iframe tags. FEBE 6.1 is nearing completion and will incorporate your other suggestions.
Component: Administration → Add-on Security
This bug should be RESOLVED : FIXED. The problem was addressed and fixed in Feb '09.
Thanks.
Status: NEW → RESOLVED
Closed: 16 years ago
QA Contact: administration → security
Resolution: --- → FIXED
I think that this should be public by now.
Flags: needinfo?(jorge)
Group: client-services-security
Flags: needinfo?(jorge)
You need to log in before you can comment on or make changes to this bug.