Closed Bug 334644 Opened 19 years ago Closed 15 years ago

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

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Windows Server 2003
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: sinchi, Unassigned)

Details

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
Product: Firefox → SeaMonkey
QA Contact: general → general
Version: unspecified → 1.0 Branch
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).
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
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
Closed: 15 years ago
Resolution: --- → WONTFIX
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.
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.
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.
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.
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.
This might be solved via whitelisting of PDF files or current server.
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.