View Full Version : Allow swf attachments
Fidodo
June 12th, 2008, 10:10 PM
Now I'm assuming the reason this isn't allowed is to prevent people from hosting their projects on the site. However, you could prevent this by setting the limit to 10kb. Since anything posted on these forums should be a code example, any swf that only has pure code should be less than this. 10kb is actually huge for pure code swfs. You could get away with 4, or even 2.
sekasi
June 12th, 2008, 10:14 PM
second, if possible.
TheCanadian
June 12th, 2008, 10:51 PM
This site got hacked several times due to Flash footers and attachments.
Templarian
June 14th, 2008, 10:44 PM
^It can be prevented now... but I guess better safe than sorry.
Sirisian
August 1st, 2008, 07:04 PM
I know this is a bit of a necro, but I kind of wish that users with a certain post count or ones that are trusted would be allowed flash footers again. If you put the normal signature image there and a javascript link that says "Enable Flash Signature" so users can click on a single signature to enable it and it would be loaded dynamically. It would be the exact size of the old signature rules and everything. Something like:
[SWF src="swfname" alt="signature.png"]
I'm 100% certain this can be done securely without any difference to a users experience on the site. I bet Senocular could help to explain the swf security stuff if that worries Kirupa. Also or you could just give each user a few blobs on the database of a certain size and then allow a user to upload the swf and image files and such. The upload system is already in place on these forums right? It would just be like granting access to certain users to place swfs with only a certain format to how they can be placed.
Or just enable it for everyone I mean this can be done securely so the only problem I see is performance. I don't see much performance problems though when I run a lot of swf stuff.
(I promise not to put a multiplayer game into it).
(I necroed this rather than this older one (http://www.kirupa.com/forum/showthread.php?t=185637&highlight=swf+footers))
Krilnon
August 1st, 2008, 07:16 PM
users with a certain post count or ones that are trusted
Definitely, we should only allows members of the Preppy Shallow Clique to have SWF footers.
REEFˇ
August 1st, 2008, 07:21 PM
My footer will say: HAHA THIS IS AN SWF.
Esherido
August 1st, 2008, 07:27 PM
I feel so shallow, preppy, and cool right now. :P
REEFˇ
August 1st, 2008, 08:50 PM
Why?
BS
August 1st, 2008, 08:59 PM
I think I'm shallow and preppy but im not in a clique yet. (Still waiting on my invite.)
Esherido
August 1st, 2008, 09:07 PM
Don't hold your breath. (If anyone in the clique invites him, I will never acknowledge their presence at this forum again. Just kidding.)
BS
August 1st, 2008, 09:16 PM
Ouch
Sirisian
August 1st, 2008, 11:12 PM
Definitely, we should only allows members of the Preppy Shallow Clique to have SWF footers.
I meant something like 10 posts. Flash while being fairly secure can be abused to lag browsers for 15 seconds or longer. For users that wish to add a signature ten posts isn't asking much. Most users I believe that join to ask one or two questions don't fill out all the optional fields, let alone create a complex signature.
I think the picture before the swf should be optional however, but a user could choose to opt for a javascript button that asks if they want to allow the flash signature on a case by case basis or not at all since some people don't have the bandwidth to view them all the time.
Unless you guys think no one will abuse them in which case it probably isn't a problem.
Along with the signature idea allowing swf files to be embedded into the actual post would be extremely useful for the source/experiments section. Many people have to post an example link off the site for users to go to when it might be a better idea to just show it right there.
(I probably will put a multiuser signature so Kirupa would need much more strict rules about what is allowed. I remember the old rules worked well).
What are your opinions?
Templarian
August 1st, 2008, 11:27 PM
http://kirupa.templarian.com/footer/
Here Sirisian this might help your point, a basic example.
I myself could care less either way as I don't really use flash, but it seems like it could work for footers, maybe not full in post swf's though.
Sirisian
August 1st, 2008, 11:36 PM
Yeah exactly. A user could put in an alt signature that will show up if they don't want the swf to run every time or if the person viewing it checks that they don't want to view the swf. If no alt signature is supplied it would just show the swf all the time unless the user specified in their control panel not to show them in which case it would just show a small default: "Click Here to Show the <User>'s Flash Signature". Nothing fancy.
This might not even need to be a tag. Just need to be a second signature box like:
Flash Signature: ????
Alt Signature: ????
kirupa
August 2nd, 2008, 12:44 AM
If the footer happens to be hosted elsewhere on a different domain, then none of the XSS issues would be a problem. The problem happens when you have SWF attachments - which are stored on the same domain as that of the forum itself.
Sirisian
August 2nd, 2008, 01:54 AM
If the footer happens to be hosted elsewhere on a different domain, then none of the XSS issues would be a problem. The problem happens when you have SWF attachments - which are stored on the same domain as that of the forum itself.
Isn't this a simple problem? Or am I overlooking something?
http://blogs.adobe.com/stateofsecurity/2007/07/
How to restrict SWF content from HTML
When you host SWF content inside HTML, you have a few tools at your disposal to control how much privilege that SWF has. If you are hosting SWFs that you created or trust completely, these may be unnecessary, however you may find them useful otherwise.
When specifying container tags (i.e. OBJECT or EMBED), you can optionally provide one of the following two parameters: "allowScriptAccess" and "allowNetworking". These tags can only be specified within HTML (not from a SWF itself), and apply to that root SWF and any other SWFs the root SWF may load.
"allowScriptAccess" controls the ability of the SWF to call into the browser's JavaScript DOM. This means the SWF could inject script into the website that is hosting it, which can be either dangerous, or at least not desirable (as the SWF could open new windows, inject JavaScript into the surrounding HTML, redirect the current window, read cookies, etc.)
"allowNetworking" affects the ability of a SWF to perform network I/O, either via the browser (opening new windows, etc.) or directly using Flash networking APIs. This implicitly may also restrict scripting access to the browser, as you cannot prevent network I/O without prohibiting access to the browser's JavaScript DOM.
In order of least to most restrictive, you can specify:
"allowScriptAccess=always": This permits the SWF to call arbitrary browser JavaScript at all times, even if the SWF came from another domain. This is generally not safe to do unless you completely trust the SWF you are loading (and any children SWFs it may subsequently load).
"allowNetworking=all": All normal network I/O is allowed (as permitted by the Flash Player security model).
"allowScriptAccess=sameDomain": This permits the SWF to call into the browser's JavaScript DOM only if the SWF came from the same domain as the HTML hosting it. This is equivalent to the typical browser "same origin policy" model.
"allowScriptAccess=never": The SWF is never permitted to call into the browser's JavaScript, even if it came from the same domain as its HTML container. You can use this tag if you host SWFs in the same domain as the HTML, but don't trust the SWFs to interact with the surrounding HTML, cookies, etc. In particular this setting will also prevent the SWF from modifying or redirecting existing frames windows. However, if you really don't trust the SWF you may need some stronger medicine.
"allowNetworking=internal": Everything with "allowScriptAccess=never" applies, and also prevents the SWF from opening new browser windows, modifying existing ones, or otherwise affecting any browser state. The SWF can still use internal networking ActionScript APIs like loadMovie(), XML.load(), LoadVars, etc.
Finally, "allowNetworking=none" prohibits any browser or network interaction. This means that the SWF cannot do much more than interact with the assets it contains internally, and cannot do anything to influence the browser, or load or send any data over the network.
In addition, Flash Player integrates with the browser's pop-up blocking technologies to ensure that windows that could not be opened directly via HTML/JavaScript will be blocked in Flash as well.
The safest strategy is to always explicitly set the parameter value you want, so you don't have to worry about what the behavior will be on a given situation.
For additional details on the allowScriptAccess tag, see http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000360.html (http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000360.html)
For additional details on the allowNetworking tag, see http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000360.html (http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000360.html)
Esherido
August 2nd, 2008, 09:08 AM
I think there needs to be a set of style guidelines for Flash footers if they are allowed (EG: No sound, no loading of external files larger than a certain size, etc.), and I also think that there does need to be the option for me to say "ok, I don't want to see so and so's Flash footer, but I do want to see so and so's Flash footer."
Templarian
August 2nd, 2008, 03:36 PM
^So basically the same rules back when we had Flash Footers. I think the whole idea I posted would be the quickest way to handle flash footers, and prevent all of the stuff Esherido said without modifying/installing plugins.
Its just a basic bbcode tag (the problem is that you would have to modify the write post section so that when a post is echo'ed to the screen it fills in the data with the "postidhere" as seen in the source.
kirupa
August 2nd, 2008, 03:36 PM
Sirisian - yeah that's something that could be considered, but Flash footers are generally just a drain on memory and CPU when you have 15 of them per page. There are non-security reasons why they aren't allowed as well.
Esh - yeah, but I don't want to have anybody waste time enforcing those guidelines.
Sirisian
August 2nd, 2008, 04:40 PM
That's why I said allow users to turn them off with an alt signature and such. It could be that they are turned off by default. Also if a user thinks that multiple of them might be CPU intensive the user could just check a box that says "Default to alt signature". So anyone seeing the signature would just see the normal image signature unless they click on the signature in which case it would turn into the flash signature. I'd imagine some people might have little things that say, "Click here to see flash signature".
This is a flash forum and it was never a problem a long time ago. (Or I didn't see a problem.) I used an older computer and I could render tons of those flash footers without a problem. We could also have a sticky or FAQ on how best to make a flash footer so it isn't abused. Also I believe the moderators could care less about enforcing that stuff. On the forum I moderate I would never see it as being a problem. They already moderate regular footers.
kirupa
August 2nd, 2008, 04:55 PM
Yes, but that is extra functionality that I would have to add. What you are describing is what Facebook does for Flash content. It just isn't worth it for having annoying Flash footers.
In the end, though, if we do have guidelines in place, they will be enforced. Otherwise, it defeats the purpose of having them. In the past, we did spend quite a bit of time enforcing signatures. Everything ranging from file size, footer dimensions, CPU usage, etc. were all things that we flagged and actually fixed. That was despite having clear guidelines in place.
saxx
August 2nd, 2008, 05:06 PM
The allow flash footer option per user pretty much fixes all those problems
REEFˇ
August 2nd, 2008, 07:11 PM
The allow flash footer option per user pretty much fixes all those problemsThis forum gave up favoritism a long time ago. See you and me saxx, we're the same.
Only on this website though, everywhere else I rool you :m:.
saxx
August 2nd, 2008, 07:19 PM
Favouritism? Don't you mean democracy? and moved more t'word favoritism
TheCanadian
August 2nd, 2008, 09:14 PM
Favouritism? Don't you mean democracy? and moved more t'word favoritism
Umm no, not at all.
I think allowing SWF attatchments is a good idea for giving examples to people in the Flash and source forums.
Esherido
August 2nd, 2008, 09:14 PM
If favoritism had more clout around here, saxx, it would be a completely different forum. (You might not still be a member.) This is forum is a dictatorship, Kirupa rules, and the mods are the henchmen. It would be even worse if it was a democracy.
TheCanadian
August 2nd, 2008, 09:22 PM
You insulting everyone is getting kind of annoying :|
Esherido
August 2nd, 2008, 09:27 PM
Maybe if you guys didn't gang up on me every 10 or 20 posts I make and criticize me mercilously I wouldn't be so irascible.
saxx
August 2nd, 2008, 09:38 PM
Can we get back to flaming the most recent lamer here <<<
(i originally said the N word, noob i didn't want canadian to stop talking to me)
Jeff Wheeler
August 2nd, 2008, 09:44 PM
I think that an implementation similar to some suggested above is possible. Temp showed me an example outside of this thread that did what I would expect: a default alternative image is displayed, and on click, it replaces the image with a Flash footer of the same dimensions. Inspired by that and some other stuff we talked about, this is the behavior I would expect:
Some BBCode like this
the-swf-uri[/i]]alt-image-uri
could produce some HTML/JS like this:
<a href="#" onclick="removeImage(this); addFlash(this, \"the-swf-uri\");" title="Click to see Flash footer">
<img src="alt-image-uri" title="User's footer">
</a>
Of course, removeImage merely needs to delete all the children of it’s first argument, and addFlash could either use SWFObject (http://code.google.com/p/swfobject/) or merely add the DOM elements for object and embed. Size could be enforced here via the width and height attributes of those objects.
I didn’t worry about writing clean code in the above examples — this site is already a mess. When writing the actual implementation, more care could easily be taken.
Esherido
August 2nd, 2008, 10:10 PM
^ Could I be included in future conversations like that? Or do you still hate me? :q:
Jeff Wheeler
August 2nd, 2008, 10:14 PM
What? I’ve purposefully stayed entirely out of the discussions regarding saxx and you.
Esherido
August 3rd, 2008, 09:43 AM
That had nothing to do with saxx! I was under the impression that you hated my programmatic guts and was wondering if that had changed.
Jeff Wheeler
August 3rd, 2008, 12:06 PM
Err … I don’t know what you’re talking about. :-/
Sirisian
August 3rd, 2008, 02:36 PM
obvious troll is obvious.
http://bugtraq.ru/library/underground/.keep/trolls.feed.jpg
Good suggestions jeff with the swfobject width and height stuff. In case kirupa doesn't know when you place an swf into a swfobject it crushes it into the width and height if it doesn't fit.
layer51
August 7th, 2008, 12:45 PM
Hi everyone, interesting thread.
Has anyone done any testing for versions of flash that don't support allowScriptaccess/networking ? Will the flash file completely ignore that html and allow potentially malicious XSS attacks? For example:
getUrl('javascript:alert(document.cookie)');
mlk
September 16th, 2008, 08:50 AM
I think the optional swf signature is a great idea, but the default option should be to only view static footers, and in the user's cpanel it could be turned to swf footers - with a warning
this way it solves the cpu problem (which, given today's machines, should be minimized)
Sirisian
September 27th, 2008, 09:31 PM
I really wish this would get implemented. Kirupa is the only person with the ability to add features to this site right? Or are there like moderators with admin rights to the server?
kirupa
September 28th, 2008, 05:40 AM
I looked into this a bit, and it is a bit of a hassle to implement. I am trying to avoid making any mods to VB that would make maintainance difficult, for every forum upgrade (even minor ones) will require me having to go through and re-add all of these modifications.
Something such as this cannot be handled by using the plug-in mechanism of vB. It will require me modifying the PHP files themselves, and that is a maintainance hassle that is just not worth doing.
Jeff Wheeler
September 28th, 2008, 12:27 PM
Have you thought about using a patch system that would let you automate that process? Storing your modifications as diffs might make them super-easy to remove and add again.
It’s probably also possible to use Quilt (http://savannah.nongnu.org/projects/quilt) or something related to Git (StGit or Guilt).
kirupa
September 28th, 2008, 05:17 PM
That's a good idea! I will look into that a bit more.
Powered by vBulletin® Version 4.1.10 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.