TinyMCE TinyBrowser Plugin Vulnerability
After the FCKEditor vulnerability that was patched by Adobe a few weeks ago, it turns out that a plugin for TinyMCE is also exploitable for remote file uploads that could be used to gain malicious access to the server hosting your application.
The details of this particular exploit are posted at Milw0rm (http://www.milw0rm.com/exploits/9296). Keep in mind this only affects the TinyBrowser plugin and not TinyMCE, so if you just have a default TinyMCE without this plugin you should be ok.
That being said, some general security tips as usual:
- Always upload outside the web root initially and perform additional checks on those files prior to making them web accessible. If you cannot access a location outside the root of your site (shared hosting) have you hosting provider adjust permissions on a temporary folder in your web root to disallow those files from being served (by the web server) but can still be accessed by your application.
- Keep any upload scripts behind an authentication scheme, whether it be HTTP authentication (a pop-up password box) or with something like cflogin. Make sure you test that these files cannot be accessed without first being logged in, you make think "OK, you need to log in to the /admin/ directory" but, can you still access /admin/tinymce/, etc. without logging in?
- Use secure passwords. I can't say this enough, I've seen MANY applications where the administrator is admin/admin or admin/admin123, which are the first things that an attacker (more likely their scripts and software) are going to attempt. I have seen a bit of a surge in brute force attempts on admin login screens recently - many of them successful because the passwords were woefully insecure.
- Define a password policy. Set things like password length and complexity as part of the business logic of your application and use regular expressions to enforce them. Another good idea, is to log every login failure (keep things like CGI.QUERY_STRING and CGI.REMOTE_ADDR so you know where these request are coming from). If you want to go a step ahead of simple logging, send alerts on each password failure with the same information. You could even keep track of failed logins and lock the user for a period of time after x failed log in attempts. While these things may add a bit of time and complexity to your development cycles they could very well save you hundreds of thousands of dollars and man-hours in the future.