Deny any unshowable MIME types in frames, images and similar cases

RESOLVED WONTFIX

Status

()

Core
Document Navigation
RESOLVED WONTFIX
12 years ago
5 years ago

People

(Reporter: Manko, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.2) Gecko/20060404 SeaMonkey/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.2) Gecko/20060404 SeaMonkey/1.0.1

Bug 266325 shows us that we should ignore IFRAME with an executable as a content. So, we shoudn't attempt to download IFRAME (and also FRAME, IMG etc.) with MIME types which are not showable in browser (which are not an HTML, image, plain text? XML etc, and are not supported by plugins).

Proposed algorithm:
1. Sending an HTTP request (maybe HEAD instead of GET?).
2. Analyzing a Content-Type.
3. If it is supported natively, showing a content.
4. Searching an appropriate plugin, if found, showing a content via plugin.
5. If steps 3 and 4 fail, ignoring (maybe showing an error message in a content area and providing a link or button to download a content data).


Reproducible: Always

Updated

8 years ago
Component: General → General
Product: Firefox → SeaMonkey
QA Contact: general → general
Version: unspecified → 1.0 Branch

Comment 1

8 years ago
Support For SeaMonkey 1.x Dropped, see ( http://www.seamonkey-project.org/news#2010-03-16 or http://weblogs.mozillazine.org/seamonkey/archives/2010/03/support_for_sea.html ).

Reporter, can you try and reproduce with SeaMonkey v2.0.4 or 2.1a1pre? (2.1a1pre isn't stable enough for everyone's daily use yet).
(Reporter)

Comment 2

8 years ago
Yes, I've reproduced this bug with SeaMonkey 2.0.4 and Firefox 3.6.3

This bug is deeper than SM/FF fork, retargetting it to Core.
Component: General → HTML: Parser
Product: SeaMonkey → Core
Version: 1.0 Branch → unspecified
(Reporter)

Comment 3

8 years ago
Update: <img src="file.ext"> doesn't work, but <iframe src="file.ext"> still works.
QA Contact: general → parser
Component: HTML: Parser → Document Navigation
QA Contact: parser → docshell
Can't be done without breaking the web.  Far too many sites will point iframes at a PDF; you're suggesting silently breaking them if the user doesn't have a PDF plug-in installed (which would be pretty much any user who knows what's good for them).

Similarly, just pointing an iframe at a file to download is a very very common thing for download sites to do.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 5

8 years ago
Cannot agree. This trick is used frequently at malicious sites, myriads of windows to download EXE-files appear, antivirus goes crazy.

We would provide info about file (MIME-type, name, extension, size, system registered type, icon) in an iframe, and link or button to download it. Of course, we should resize an iframe to make such info visible, zero-sized iframes are an evil.
> in an iframe, and link or button to download it.

That doesn't work for POST responses.
(Reporter)

Comment 7

8 years ago
Of course, if form is being submitted into an iframe, we should'n worry.

Thus bug is about unshowable content spammed by IFRAME SRC="...", not about form submission.
The two cases look identical to the code that processes the response from the server.
(Reporter)

Comment 9

8 years ago
Seems that codeflow should be separated here and in case of IFRAME SRC we should check URL up on showability before.
Before what?  You can't check for "showability" until you make the request to the server.
In any case, the right solution here would seem to be something similar to our existing attack sit list, for your scenario of comment 5.
(Reporter)

Comment 12

8 years ago
I've tried to describe it in comment 1. May be HTTP HEAD request would be helpful, may be we would abort loading rest of HTTP response if MIME-type would prove to be inappropriate.
Server responses to HTTP HEAD are irreparably broken, esp. in the legitimate use cases here.  We used to do HEAD requests for "save link as" to determine the type and filename and had to stop because it was wrong so often.
And in particular, HEAD makes no sense before POST.  And even for GET it usually fails miserably if the site has a CGI.
(Reporter)

Comment 15

8 years ago
Well, I don't deal with POST request, only about IFRAME SRC.

We always may do GET and abort loading body of HTTP response if Content-Type is unwanted.

Honest servers practically never place unshowable URLs into IFRAME SRC, so this doesn't lead to server overwork.
> Honest servers practically never place unshowable URLs into IFRAME SRC,

It's _very_ common for banks and the like to place URLs to PDF files in iframe @src.
(Reporter)

Comment 17

8 years ago
This might be solved via whitelisting of PDF files or current server.

Comment 18

5 years ago
As web developer, I use <script src="some.jsonp"></script> to execute JavaScript from external resources, with iframe, usually can load all content, that browser support to show that. So, with Chrome I can load some text file with custom extension (.wiki, read.me, .eula, .md,.markdown... and same .json) and after that parse it`s content with: iframe.contentWindow.document.body.innerText. It will be a good hack, till Firefox do not simply download the contents of iframe :(

Is there any other solution to get file contents (as text) in JavaScript?
You need to log in before you can comment on or make changes to this bug.