I want to know if there are advantages to keeping the extension of an image (on the client side, because on server side (linux), i do not see the benefits, knowing that the extension isn''t important).
Is it better to have <img src="/a" /> or <img src="/a.jpg" /> ?
So, store in server images with extension ?
Information: The images are photographs of the users. Names of the image is complex.
I'm thinking to keep extension, because if the user save the image, they will have extension.
But keep extension is a little more complicated for development.
And it can be advantage to stay with no extension?
Typically, the extension is how the web server determines the MIME type for the file, which is how the browser knows it's an image and not text or arbitrary binary data or something else.
So, typically, you'd want to keep the extension just for that reason. There may be unusual situations where that may not be true, but in a typical web server serving files right off the filesystem, that's the case.
If you don't need the extension on the server side because you are sending the correct MIME type regardless of extension, then yeah, the only obvious advantage would be for situations where the user would want to save the image and the browser or OS isn't smart enough to do the right thing with the image without an extension. In this day and age, I have no idea how common that situation is but it is certainly less common than it used to be.
Personally, I'd be disinclined to worry about it if it will complicate development for you (especially if it's something you can always go back and do if you find out that you actually do need it for some reason). What I would ponder, though, is if there is something that needs to be improved in the application architecture if preserving the file extension is a big headache. It seems like that shouldn't be a big deal one way or the other. Of course, I say that without knowing the particulars of your situation; I'm just speaking in generalities.
Not using extension should be fine as long as you send the correct MIME types. Browsers automatically add extensions if required. (Prove: Your Gravatar picture: http://www.gravatar.com/avatar/f1f8a3382d2946bd526dd629eaa29b2b?s=32&d=identicon&r=PG)
Basically you can use any extension as long as the MIME type is correct. If you serve your files statically using extension would be more convenient since most Webservers use extension-based MIME-type guessing. Serving from a database not using extensions could be more convenient...
Related
For example, we have a cool styled website, can we use developer options(f12) from browser to snatch this?
Ignoring any legal / copyright implications, you can grab the client-side code this way, yes. All HTML, CSS, JavaScript and imagery can be seen through the F12 Developer Tools.
However, there is no way to know what server-side code a website is using (outside of the server owner themselves configuring something incorrectly and thereby exposing that information).
The answer from Obsidian Age is a good one. I'm going to add some more information that may be useful to you.
I've used this technique myself of getting source code via the developer window. Usually I want to find out how they did some neat CSS or JS trick so that I can try it in my own apps.
The files that make up a website such as HTML, JavaScript, and CSS you can find in the Network tab and can easily copy these.
However you should know the JS, CSS, and even (sometimes to a degree) the HTML files have been minimized and are typically missing any comments from the original developers. Chrome has a nice feature that will un-compress JS files and you can even set break points and step through the JS code.
Here's the deal. I've animated + coded a variety of 'screensavers' in Actionscript3/Flash. They make extensive use of the timeline, AS3 code, the TweenLite library, and embedded fonts. That's the limit of my programming knowledge. I've tried, to no avail, to convert my .SWFs into screensaver files using a variety of software, such as InstantStorm. Somehow it never works, the code never executes properly, it's a disaster.
So, I'm wondering if it's possible to make a screensaver that simply contains an embedded browser, and have it point to my .SWF file, hosted on my web-server. Basically, imagine a full-screen website acting as a screensaver.
If this is possible, what is the EASIEST and FASTEST way for me to whip up a solution for both PCs and Macs? Language, etc. I'm hoping something that has a library I can simply draw from to embed the browser view :)
My startup is developing a product to do exactly this, it's called Screensaver Ninja and you can find it at https://Screensaver.Ninja.
You can set many different web pages with different timers. The configuration tool allows you log in and navigate to the page you want to display:
It uses WebKit, on Mac OS X it uses Safari's and on Windows it uses Chrome's and in both cases it has a separate session from any other browser installed on the computer.
Here's a small Windows-only solution:
https://github.com/cwc/web-page-screensaver/releases
You could modify this open-source one for the Mac so that it's hard-coded to your URL:
http://www.liquidx.net/blog/2010/11/13/webviewscreensaver-for-mac/
Modify hasConfigureSheet() to return NO and change the URL in kScreenSaverDefaultURL. And change the name!
I want to let users (i.e. anyone who signs up for an account) upload and download video and text documents. I have been researching the security issues regarding letting users upload files, but everything I can find on the subject assumes that users will only upload images.
Are there any security issues specific to letting users upload videos and text documents? Is security a lot more difficult when users can upload files at video size? Are there any particular file extensions I should look out for?
The problem is this: If you let users upload videos, images and text files, some of them will try to upload viruses, server-side scripts and other malicious code. Such code will then expose your site's users to what ever 'bad things' those users uploaded, within the context of your own site.
If you allow such uploads, you must be very careful that you are only saving files of the actual types you planned on - and not by looking at the file extension, either. You also must make sure those files are placed in locations where execute/script permissions are disabled.
Virus checking is a must - but it is not at all enough. A PHP script may not set off virus warnings at all, but that same script could reveal vital information for your site, or cause other bad things to happen if executed.
You must examine the content of the files - never rely on the extension or MIME type reported by the client. Those can easily be faked.
Serve your downloads from a location for which you have disabled the execution of server side code. This is all you need to do to protect yourself from server side exploits. Relying on file extensions or other such things are all hacks.
If you want to fully protect your users (and indirectly your website) as well, you'll need to run the files through a suitable virus scanner. It is possible, and there are real-life examples of doing so, to exploit video decoders and such software to run arbitrary code. But if you start walking down that line, you could also argue that certain text strings might set off weird behavior in certain software, and that starts getting silly. Luckily, the people who write virus scanners will have done most of the work for you. So:
Never execute that what is uploaded
If you feel it's needed, virus scan them as well.
You can virus check each file that is uploaded. If you look at most web based email clients you will see when you upload a file they are checked by McWhoever. In generally you shouldn't let them upload exe files but checking the extension is a very basic (unreliable) method.
It's quite hard to make an upload REALLY secure.
There are quite a lot of things to check - the file extension is just one part of it. Here are few things which have to be at least checked:
file extension (as you've already mentioned)
mimetype
filesize
depending on the users: maybe check the uploads with ClamAV ...
To answer your question here is a meta attack:
bad guy uploads a binary to your
server, perhaps tricking your
filters by compressing file and
changing extension to .avi
exploit bug in a CGI script to
decompress avi from #1
exploit bug in another CGI to
execute file from #2 -> backdoor
installed
backdoor accessed and rootkit
installed to hide all evidence of steps
1,2,3
Some variation on the above is what typically happens when servers are compromised.
We're using the Mantis bugtracker (version 1.1.8), which is based on PHP. To ease the workflow of adding bugs we'd like to add an option to paste screenshots from the clipboard directly into the 'new bug form'.
Screenshots make bugreports much more valuable for developers, so I'd like to make adding them as easy as possible. Preferably without using an external application, but right in the browser.
I've looked all over for a way to add this, but no luck. How do other people do this? Am I missing something obvious?
edit: The bugtracker is a private one, in a small company, so I'd be willing to accept the security risks that for example Java applets present.
There isn't really a way to do this short of using ActiveX, applet or Flash-type technology on the client. Even then, there are numerous security roadblocks. A browser has no easy way to convert stuff from the clipboard into a suitable format for upload to a website, and even if it did there would be security concerns. For example, malicious code in a page could copy sensitive information from your clipboard and send it to the page's site without you even knowing it was happening.
Update: There is a standalone screen capture utility which claims to work with Mantis (and a whole bunch of other bug-trackers). This is probably your best option.
There is a drag n drop image attacher Java applet for Atlassian Confluence which has the functionality you need. It only supports Confluence but as the sourcecode is freely available under BSD you should be able to customize it to your needs.
Forgot the link:
http://confluence.atlassian.com/display/CONFEXT/Drag+and+Drop+Image+Attacher+Plugin
I've managed to build my own solution that works quite well. It places a Java file upload applet on the pages where you'd want to attach a screenshot. The applet has two buttons:
'paste screenshot', which pastes an image from the clipboard into the applet
'upload screenshot', which uploads the pasted image to the /tmp dir on the Mantis server and uses a javascript callback to place the autogenerated filename of the uploaded image into a form field.
Once the form is submitted, a new function in Mantis uses the filename in the form field to move the image from /tmp to the final location and processes the image just like other attachments. If the form is never submitted the uploaded file remains in /tmp and will eventually be purged by the server.
It works well, but has one drawback that I cannot avoid: I'm using Java to get access to the client's clipboard, but that requires breaking the JVM sandbox. Apparently, this can be done if you digitally sign the applet, which requires a rather expensive yearly payment (something like $500) to a company like Verisign (currently free options like cacert.org are still limited in their usefulness).
Another way to allow Java applets access to the clipboard is to create a file called .java.policy in your home or profile directory. This file should contain the following (Replace the domain with the domain that hosts your Java applet):
grant codeBase "http://bugs.example.com/-" {
permission java.awt.AWTPermission "accessClipboard";
};
Thankfully the solution is cross-browser compatible since the JVM always checks the same file regardless of the browser used. Since my solution requires having this .java.policy file on each client computer I don't consider it ideal, but workable in a controlled company environment.
I looked in to this also. No real easy way, so instead I allowed them to upload an unlimited number of files and those files would then be "attached" to that bug. It actually turned out to be better because they can upload screenshot, spreadsheets, word docs, etc.
Like yours, this is an internal only site so security is light. I did this in ASP.Net, but the general idea is that when they are looking at a page for a bug they have an upload box. When they upload something I pre-append it with the bug id. So ScreenShot.jpg becomes 233_ScreenShot.jpg.
Also on that page is a grid (GridView) that is bound to all of the filenames in my upload directory that start with that bug id.
To see what this looks like click here.
For tech-oriented users, there's always to possibility of using Eclipse + Mylyn + Mylyn-Mantis connector.
Then uploading screeshots is very easy:
Screenshot upload http://img216.imageshack.us/img216/246/screenshotattachments1.png
I want to allow my users to embed their own Flash animations in their posts. Usually the actual file is hosted on some free image hosting site. I wouldn't actually load the flash unless the user clicked a button to play (so that nothing auto-plays on page load). I know people can make some really annoying crap in flash, but I can't find any information about potential serious damage a flash app could cause to the viewer.
Is it unsafe to embed just any flash file from the internets? If so, how can I let users embed innocent animations but still keep out the harmful apps?
edit:
From what I can gather, the most obvious threat is for actionscript to redirect you to a malicious site.
Adobe says you can set allowScriptAccess=never and allowNetworking=none and the swf should have no access to anything outside of itself. Will this solve all my problems?
Flash has some neat security measures in place. Allowing users to upload swf's to your site and embedding them is unsafe, you're basically setting yourself up for an XSS attack.
However, allowing them to hotlink should not be a problem. The swf will be locked to the domain that is hosting it and is not allowed calling url's outside of that space.
It will still be open to "evil links" (i'm sure theres a proper word for them), and by that I mean having regular links to yoursite.com/admin/deleteallpages.php which it tries to load "as" you. It will not however be able to use this data in any way, it'll basically be the same as a normal link, and I'd guess modern cms' are protected from that type of attacks.
You could get the same protection by hosting your flashes on a different subdomain, since flash considers this the same as a completely different domain.
When embedding SWFs from unknown sources, it is also best practice to throw a mask on the Loader so that the loaded SWF can't take over more screen real estate than expected.
Pseudo-code to do so:
var maskSpr : Sprite = new Sprite();
maskSpr.graphics.beginFill();
maskSpr.graphics.drawRect(0,0,safeWidth,safeHeight);
maskSpr.graphics.endFill();
myLdr.mask = maskSpr;
There is actually more than one option.
To be totally safe, set allowScriptAccess=never and allowNetworking=none and the swf will have no access to anything outside of itself.
NOTE: allowNetworking is only in Flash Player 9 (it was created in response to various myspace worms), so you'll need to use SWF Object to insure that only users with the right flash player version or better have the flash loaded.
If you want to enable things like youtube videos, though, you can't set allowNetworking to "none". Fortunately, there is an intermediate level of security for this field - "internal" which lets the SWF talk to its hosted domain.
Also note that you better not have a crossdomain.xml file on your site - read more about those dangers here and other places.
Here are some other sites that are mentioned by other answers that go into more detail:
http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps_04.html
http://blogs.adobe.com/stateofsecurity/2007/07/how_to_restrict_swf_content_fr_1.html
As an example Drupal has a scenario of how allowing flash content from users could be a security concern.
Adobe says you can set allowScriptAccess=never and allowNetworking=none and the swf should have no access to anything outside of itself. Although allowNetworking is only in Flash Player 9, so users with earlier versions of Flash would still be susceptible to some exploits.
Creating more secure SWF web applications : Security Controls Within the HTML Code
How to restrict SWF content from HTML
Yes, it's unsafe.
There's no easy way of allowing it. You could have a domain whitelist that allowed YouTube, Hulu, etc. through, but whitelisting is inherently painstaking - you'd be constantly updating.