I'm making a newsletter editor which will allow file uploads (the sender of the newsletter can upload files to the server which will be linked to in the email).
The site is set up so that only .do URIs are actually executed/handled by servlets so it's not much of a security risk, but I've been told to blacklist .jsp, .php, .asp, .aspx, .exe, .com, and .bat. This does not strike me as a comprehensive blacklist, and I've the impression that blacklists are not a good policy.
On the other hand, a whitelist would be dozens long. What's the correct way to identify allowable/disallowable extensions? Or is it more proper to just allow anything and run it by a virus scanner, or some combination of these?
I would allow any file extension to be uploaded, but I would store the files in a folder that is not directly served by the web server. I would then create a HTTP handler that would be linked to from the email, which would stream the requested file. The file could be requested either by original file name, a system generated file name or by an ID. Either way, I would sanitise the parameter to guard against directory traversal attacks.
e.g. www.example.com/FileLink.ashx?FileName=Word.docx
This way you do not need to worry if in future you wish to serve additional file extensions as executable file types, as any file is served directly from a byte stream from the file system and is never passed through the web server handlers.
You can also use the handler to check that the current user has the correct permissions to load the file.
It would also be worth virus scanning each file, just in case the newsletter author uploads (either maliciously or accidentally) a file that would attack subscribers' computers rather than the server.
Also ensure that the Content-Disposition is set to attachment:
Content-Disposition: attachment; filename="filename.html"
This guards against XSS being achieved by upload of HTML containing script tags, or other Same Origin Policy bypasses using Flash or PDF files. The scenario here is one newsletter editor compromising the session of another newsletter editor. It is worth also setting X-Content-Options: nosniff, which can also protect against this. xap files (Silverlight) could also bypass the Same Origin Policy, so check that the filename cannot be ended in .xap to request your file
e.g. www.example.com/FileLink.ashx/x.xap?FileName=Word.docx
and you could blacklist the setting the content type for Silverlight as extra protection for this special case. Source here:
Note: .XAP files can be renamed to any other extension but they cannot
be load cross-domain anymore. It seems Silverlight finds the file
extension based on the provided URL and ignores it if it is not .XAP.
This can still be exploited if a website allows users to use ";" or
"/" after the actual file name to add a ".XAP" extension.
Note: When Silverlight requests a .XAP file cross-domain, the content
type must be: application/x-silverlight-app.
I've also verified these scenarios myself and are are currently valid attack vectors.
Or is it more proper to just allow anything and run it by a virus scanner.
Yes.
Both blacklists and whitelists are trivially circumvented and cause just administration pain and provide no security whatsoever.
In my opinion, even though the whitelist maybe a bit of a chore to maintain, it's far more secure than using a blacklist.
It's much better to forget to add something to the whitelist, and have to go back and change it, than to forget to add a new file extension to the blacklist and get hacked.
In addition to the whitelist, I would still virus scan the uploaded files, as even seemingly harmless files (such as .pdf or .doc) can have malicious code (.pdf's support javascript, and .doc macros)
I would recommend you:
Use a whitelist approach (by the reasons described above, it's fairly
more secure)
Check the filetype (bypassable but still one more measure)
Store uploaded files in internal folders not exposed to the public (using non enumerative IDs)
Set-up a low grade permission to the folder that will contain the uploaded files
Set-up less privileges as possible to the uploaded files
Make sure if there aren't secure libraries to upload files already available.
Antivirus aren't worth it. Most of web shells signatures are really easy to bypass since any 'hacker' can add some random code and do different types of encodings on an web shell. Sure it will protect you from common shells such as C99 but nowadays there are thousands of these tools publicly available and fully undetectable. And regarding protecting your users from executable files or infected PDF's hosted on your websites, if someone it's capable of get a shell on your site and start up a malware campaign it won't use malware or virus already spotted by av signatures.
Related
Currently I'm building a local serach engine for network drives that is going to be used in our company.
The search engine is build on top of Solr and Tika. I've build an indexer that indexes Samba-shares over the network which works great and indexes all the directories that are given in a configuration file. However that is not really relevant.
The current problem we have is that the web interface that connects to Solr and delivers the search results will try to serve local file:// files that are links to the files with a absolute or Samba path. But serving file://'s are of course disallowed by browsers like Google Chrome. The error that Chrome gives is:
Not allowed to load local resource: file:///name/to/file.pdf
Which is obvious and logical, however I want to work around that issue and serve 'local' files to our users. Or at least open an Explorer window with the given path.
I was wondering if this is even possible or if there is a workaround available? The server that is going to serve these files is running on Apache or Tomcat (doesn't matter).
Alhtough opening file://'s seems pretty much impossible without the use of browser-specific plugins, I created a workaround by specifying a custom URI-handler combined with a Windows specific application that will open explorer.exe with the given directory.
This is by far not the ideal answer to my question, but I think it is a decent workaround for an intranet search application.
Streaming the file from your application to the browser is a much better idea from a usability and security perspective.
By assigning a MIME type to the stream, the user's browser can decide how best to open and display the file to the user.
By streaming from you application, control of the data can be maintained. The location of the file on you server is not revealed and proper authentication, authorization and auditing are easily achieved.
Assuming Java based upon your use of Solr and Tika:
http://www.java-forums.org/blogs/servlet/668-how-write-servlet-sends-file-user-download.html
I am trying to write a chrome extension that initialize some parameters from a config file.
I would like to allow the extension to change those parameters and save them to the file so that the next time the extension was loaded it uses the new configuration.
I have been reading the chrome.filesystem api but it needs the interaction of the user to choose the file. However in this case the process must be done automatically without any action of the user.
Since this configuration file will be only accessed by the extension it could be sand-boxed but It must be persistent even if chrome is closed.
I manage to read the file using an XMLHttpRequest but I could not find a way to modify the file.
Is it possible to do this from a chrome extension?
This is an old question but unfortunately the only response it got was wrong.
It's definitely possible to read and write files using HTML5 in Chrome, without the vague "security" issues mentioned. The HTML5 Filesystem creates a protected sandbox in which you write and read virtual files: you can think of it as files being written in file based database managed by Chrome and not accessible by either other Chrome apps & extensions or other OS based applications. The user won't be able to copy or move these files using his OS file explorer since they reside inside the web browser's file DB.
You can't read (or write) arbitrary files from (to) disk based on any given file path.
If you need a file from disk you can only let the user select it himself by using chrome.fileSystem.chooseEntry()
You can however read (and write) your own files from (to) the HTML5 Filesystem.
So to answer your question: no you don't need user interaction to write your config file to the browser's file system.
An alternative to files could be chrome storage, localstorage or even indexedDB to store your (persisted) config key-value pairs.
Here are a couple of useful links to start reading about it:
Toying with the HTML5 filesystem
HTML5 Rocks
HTML5 demos
I imagine allowing a chrome extension to write to config files without the user knowing could be a bit of a security problem. You're probably hitting up against a security feature. A potential work around is to build a desktop application that is always on, and your chrome application communicates with it. Heck, you might able to do what you need to (without knowing all the details) with something like autohotkey.
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.
Now I didn't do the website design but a couple of months ago I ported an existing website over to wordpress for a client of mine.
I got a call from a client today regarding their website, and some sort of a security problem.
The websites homepage loads up fine, but if you try to navigate to any other page it brings you to - http://secure.wheelerairservice.com/main.php.
The nav appears to still be linking to the appropriate page (when you rollover contact us, the link displays in the status bar as /contact-us) but it redirects to the above url.
Just wondering if anyone knows what the problem is, and who or what might have done this and how.
Any suggestions on how I could fix this?
thanks!
Ok I've looking into the problem some more and found that the .htaccess file had been replaced somehow. I'm just wondering how someone might have done this? via ftp access, wordpess admin account or some hole in wordpress, any thoughts?
Typically when it's the .htaccess files that have been infected, it's usually the result of stolen (compromised) FTP credentials.
This usually happens by a virus on a PC that has FTP access to the infected website. The virus works in a variety of ways, but usually one of two.
First, the virus knows where the free FTP programs stores it's saved login credentials. For instance with FileZilla on a Windows XP PC, look in:
C:\Documents and Settings(current user)\Application Data\FileZilla\sitemanager.xml
in there you'll find, in plain text, all the websites, usernames and passwords that user has used FileZilla to access via FTP.
The virus finds these files, reads the information and sends it to a server which then uses them to login to the website(s) with valid credentials, downloads specific files, in this case the .htacces files, infects them and then uploads back to the website. Often times we've see where the server will also copy backdoors (shell scripts) to the website as well. This gives the hacker remote access to the website even after the FTP passwords have been changed.
Second, the virus works by sniffing the outgoing FTP traffic. Since FTP transmits all data, including username and password, in plain text, it's easy for the virus to see and steal the login information that way as well.
Change all FTP passwords immediately
Remove the the infection from the .htaccess files
Perform a full virus scan on all PCs used to FTP files to the infected website
If the website has been listed as suspicious by Google, request a review from Google's webmaster tools.
If the hosting provider supports it, switch to SFTP which encrypts the traffic making it more difficult to sniff.
Also, look at all files for anything that doesn't belong there. It's difficult to find backdoors, because there's so many different ones. You can't go by the datetime stamp either because these backdoors modify the datetime stamp of files. We've seen infected files with the exact same datetime as other files in the same folder. Sometimes the hackers will set the datetime stamp to some random earlier date.
You can search files for the following strings:
base64_decode
exec
fopen
fsock
passthru (for .php files)
socket
These are somewhat common strings in backdoors.
Change your passwords. See Hardening WordPress and FAQ: My site was hacked « WordPress Codex and How to completely clean your hacked wordpress installation
If FTP has been used to access/modify the files in this wordpress site, then it could be more than possible that someone has got the username and password for FTP access and modified your .htaccess file. FTP is not secure at all. I would suggest using SFTP as a minimum.
Wordpress is not perfect (not many things are) but i highly doubt there would be a flaw like this, is possible but i very much doubt it.
I suggest you first, change your FTP username/password, upgrade wordpress to the latest version, change the default admin username to something else and change the password for the administrator user, ensuring that all passwords are at least 8-10 characters in length
We also getting same problem for word press website, once virus removed but it re-attacking again, So as said above first have to backup all files, then change passwords of FTP, Administrator and cPanel, then upload back the website. I did above steps for our website.
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