iframe embed
Description
Embeded local HTML page is displayed as HTML source.
How to Reproduce
Upload simple HTML file into your page, ex. helloworld.html:
<html> <head> <title>Hello World!</title> </head> <body> <h1>Hello World!</h1> </body> </html>
Try to embed this page using:
[[embed]]
<iframe src="http://your_name.wikidot.com/local--files/your_page/helloworld.html"></iframe>
[[/embed]]
or simply
[[iframe http://your_name.wikidot.com/local--files/your_page/helloworld.html]]
Browsers
Has bug
No longer applies.
Firefox 2.0.0.13
Opera 9.27
Safari 3.1
Works correctly
No longer applies.
IE 6
IE 7
Workarounds
Rename extension of local file from html to, lets's say, scrap (Removed because it is huge a security threat)
This workaround works - BUT IS NOT LONGER NECCESSARY ! THE BUG IS FIXED!
- Have the extension of the (attached and) embbeded file on html !
- RENAME THE URL to specific naming convention:
( It cannot be the same domain name as before)
Try to embed this page using:
http://your_name.wdupload.wikidotsyndication.com/local—files/bugs:iframe/helloworld.html
[[embed]]
<iframe src="http://your_name.wdupload.wikidotsyndication.com/local--files/your_page/helloworld.html"></iframe>
[[/embed]]
or simply
[[iframe http://community.wdupload.wikidotsyndication.com/local--files/bugs:iframe/helloworld.html]]
gerdami. Please visit his/her userPage.
and
Helmuti_pdorf. Please visit his/her userPage.
Contact
Rate this Bug
Rate the urgency of this bug. If you think it is more urgent and important than it's current rating suggests, rate it up.
Comments
Could be web browser issue, but the question on forum hasn't been aswered for almost 2 months…
http://community.wikidot.com/forum/t-51141/local-javascript#post-137607
As we don't want to serve any user-submitted HTML files, I have recently disabled serving anything in user upload directories as text/html.
IE6 rendering non- text/html files as as HTML is a security bug in IE, not ours, so we don't do anything about this.
If you wonder how serving user-submitted HTML files by Wikidot can be dangerous, it is because user include malicious JavaScript, that being run from the same domain as the wiki page would be ran at full privileges and potentially do bad things (like deleting all wikis of the currently logged user).
If you're interested in how we are going to host HTML files the right way, look at the following page:
http://groups.google.com/group/wikidot/browse_thread/thread/b0db300e0d02095a?hl=en
Maybe that should be a how to here on the community? Why would it go somewhere else? Lets put it where people will look for it.
Edit: I didn't see that it does not work yet. When it does though, we can make it a how to. For now, couldn't you (or do you) just let people host the files on a different wiki than the one they are iframing from? That should work and be safe until a different approach is implemented.
Different wiki on Wikidot is unsafe the same way as the same wiki.
You could make a page on a.wikidot.com/local-files/proxy.html which iframes a file b.wikidot.com/local-files/hack.html
Include some hackish JavaScript on the second, and then iframe the a.wikidot.com/local—files/proxy.html file from the wiki b.
The only way is to not serve ANY user submitted files as text/html or serve it from some other domain.
So I would recommend users to use other that Wikidot HTML upload service to achieve iframing HTML files from Wikidot sites. At least till we implement this.
Changelog is still dated 16.01.2008 with no trace this "FIX".
Please fix also the ChangeLog!
(Are you saying that the "workaround" of renaming files to .scrap has been disabled? I tested the "Hello World" thing a few days ago and it seemed to work.)
Anyway, today I "tricked" my wiki into running .php code that was included as a .css file inside an .html file that I iframed into a page.
I'd like to direct you to my wiki:
Karma-Lab wiki
I'm thinking it's starting to look pretty bitchin', but there are some formatting problems with different browsers. I've been searching for a solution to that, other than the sometimes ugly hacks people do to css files.
Let me explain: I am running a php fix on my site (not my wiki site, my main site) that uses php inside a css file, to determine browser type, and then to dynamically generate some fixes for the .css file to compensate for differences in browser display. In other words, I have my main css file with everything in it, and then this supplementary css file is included after it, which only generates a few things to tweak the appearance that is mainly governed by the main css file.
Note: credit for the basic idea goes to http://www.stylegala.com/articles/no_more_css_hacks.htm.
So I wanted to run this same kind of thing on my wiki. After spending nearly a whole day today, I got it to work! You can see it here on this sandbox page, which contains the details:
http://karma-lab.wikidot.com/misc:test-iframe-php
Now, I am planning to rely on this working to fix a few things, in addition to doing some other things, so I want to be sure that this is not "prohibited activity" and is not going to be disabled. I'm not a php expert, I don't know if this kind of thing can be used for malicious behavior.
Please tell me this is OK - I want to implement a number of things based on this sort of php inclusion. Thanks!
I am not sure how thgis is working now in Firefox.
"Standard" java apllets are NOT working in Fireforx now. In Internet Explorer it is working because of a bug in IE…
I made a test of your link in FF and it looks good.
I do not know if this will be changed in the future…
I will ask Gabrys on the edv-list:
http://groups.google.com/group/wikidot/browse_thread/thread/b0db300e0d02095a?hl=en
COuld be so easy top answer … this is an iframed URL and not embedded ?
The answer to your question is easy. It all work because you use YOUR server outside Wikidot to run PHP files.
The Wikidot servers don't serve any user-submitted files as text/html or parse them with PHP.
The first (serving some files as text/html) would allow to run malicious JavaScript codes.
The second (parsing php files) would allow to do even more evil, because this would allow to do almost anything with the Wikidot service.
However serving HTML files as text/html IS safe IF we serve it from other domain. Even if user have some malicious JavaScript it is not allowed by browsers to touch anything on Wikidot, because the domains differs.
Hope this helps.
Gabrys,
You have destroyed a functionality, without notice.
Thank you very much.
Thank you! Glad to know I can use this technique.
Hi
as we have seen many users relying on our security bug (which was ability to upload a HTML file with the extension .html renamed to something else), we've decided to provide such a functionality the right way.
If you want to have this possibility you need to slightly change the way you invoke the [iframe] tag.
Say, you have an iframe with the URL http://some-wiki.wikidot.com/local--files/some-page/some-file.html
You just need to change the domain name part and let it render: http://some-wiki.wdupload.wikidotsyndication.com/local--files/some-page/some-file.html
This file is safe for us to serve as text/html, and we do it.
Actually now ALL the files you want to be served as html NEED to have the .html suffix.
The feature is still beta, but should be quite stable. We will also manage to create some automagical redirects from the previous-style-links to the new one if a page is .html ended.
Hey.
Now this is REALLY fixed!
This means, you just upload a file with .html extension to Wikidot, and it JUST WORK (all the magic with other domain name is hidden behind).
Sorry for the inconvenience for this week of two of having this particular feature disabled, but this WAS a security bug.
Now, enjoy your HTML files hosted on Wikidot :)
Thanks Gabrys!