Security attack from IP 92.243.90.103

I've noticed recently that the IP 92.243.90.103 is testing several servers, requesting for files related to FCKeditor and then checking for the availability of the connectors to perform operations on the server (usually I think that it's more common requests related to tinymce filemanager, but it doesn't really matter too much).

I don't think that the requests are related to an unknown problem with the server connectors in FCKeditor as it seems to search both the asp and aspx versions (maybe it acts depending on the server software), but there are a few points that everybody should remember in order to avoid problems.

As every other time that I've written about this issues, let me remember you that I'm not a security expert and these are just some basic guidelines, the basis is that you should try to create an onion around the security of your server, different layers so that an attacker has to go through all of them, and hopefully he should be stopped at the very first steps.

Keep only the needed files

Whenever you use a third party software (or even your own software), don't upload to the server everything that comes in the shipped distribution. You won't need at the server source files, samples, documentation, or integration files for other server languages.

By removing those extra files you are avoiding a larger vulnerable surface and you can focus on the important files.

Security by obscurity can be useful

Yes, security by obscurity isn't really secure, but this kind of automated attacks that just search any number of domains for some files at specific locations like "/FCKeditor/editor/filemanager/connectors/aspx/connector.aspx?Command=GetFoldersAndFiles&Type=File&CurrentFolder=/" can be avoided if you place this 3rd party components in a non-standard location, so something as easy as putting the FCKeditor in another subfolder can avoid that an automated attack finds your files.

It's also important that the files that the users upload to your server with scripts like the FCKeditor server upload, don't end up in a folder that gives any hint about how they have been placed there, if your files are under /scripts/CKFinder/userfiles I'll know that you are using CKFinder somewhere in your server and more important, you are stating the path for CKFinder so you are weakening a little the security that you got in the first place by using /scripts/CKFinder instead of just /CKFinder

Expose the upload script only to users that can upload files

If a user doesn't have permissions to upload anything, then he shouldn't be able to see any hint about what are you using to manage the files in your server.

Secure the upload folder

The folder where the users are able to upload files shouldn't have permissions to execute any script, so even if they are able to upload a script, it won't do anything. Using the IIS control panel or .htaccess files in Apache it's easy to perform this task.

Keep your code updated

This can be a pain, but you once you start using a script at your server, you should check from that moment any new release about that project, paying special attention to warnings about security problems in new releases. I think that every project has some kind of RSS feed, so it shouldn't really be that hard to at least notice the new versions.

Enable file management wisely

In FCKeditor and CKFinder the server connectors include a config file where you can adjust some parameters (location of uploaded files, allowed or disallowed extensions, types of files, etc...) but the most important one is the ability to state if the script is enabled or disabled.

By default the server connectors are disabled in FCKeditor and CKFinder as that's the safe default, but people the complain that when they try to use them they get a message stating that the connector is disabled. Of course, that kind of people are showing that they didn't bother to read the minimum about how to configure these scripts, so they might end up using other ones that are enabled by default and they won't ever notice that now everyone can manage the files of their servers.

The correct step is to use the login credentials of your CMS to enable the file management only for the correct users, you don't really want an anonymous user being able to upload a file to your server.

Finally: be careful

As you can see, I'm not revealing anything extraordinary, these are just some basic rules that can provide some basic protection, but there are more that you should be aware of and that's part of the task of managing a web server.

When you pick a file manager for your server, don't think only about a few buck that you can save by using a free manager instead of a paid one, check how the security is implemented in each one, if an attacker is able to get control of your server you can lose many times that money trying to getting it back to normality.

 

New releases at CKSource

Yesterday CKSource released the new versions of CKEditor and CKFinder. You can read the updates on each one in their blog posts, but I'm gonna give you my point of view about them.

CKEditor 3.3 is a progressive enhancement over the previous version, lots of bug fixes, some little new features, everything focused on trying to make your experience using CKEditor better than ever before. Of course we have tried to test and verify that everything is working correctly and no regressions have been introduced, but it's just impossible to test all the possible setups and ways that people use CKEditor, so if you find something that used to work in 3.2 or 3.2.1 and now fails, then go ahead to the CKEditor dev site, check for other reports and if you don't find anything create a new ticket explaining the problems and please, provide a test case so that we can reproduce the problem. If you just say "it fails", then we won't be able to fix it, if instead you provide a simple html file then it will be easier to find out what went wrong.

CKFinder on the other side is a complete rewrite of the client part, you'll find now that it follows the behavior of CKEditor, it includes lots of changes and this is just the beginning. With CKFinder 2 it's possible to write both client-side and server-side plugins to enhance your integration and provide new features. Check the provided samples and be sure that we will keep improving it, we just need time and good feedback about what you need. In order to report issues you can use the CKFinder forum

Trying to explain all the features available right now with just a few words isn't easy so I'm gonna stop talking and urge you to test the demos (CKEditor and CKFinder), I hope that you really like them.

New releases of CKEditor and CKFinder

To start the new year, the team at CKSource has released new versions of CKEditor  and CKFinder.

CKEditor 3.1

It is an evolution of the previous version. It's focused mostly on introducing New features, several of them to bring back parts of the old FCKeditor feature set, but there are also new parts like the integration with jQuery and the new Paste system that allows to have a control about what's being pasted into the content.

As these features have been rewritten, don't be surprised if there's a little bug here and there, so if you're sure that something isn't working then head up to the dev site and search for existing bugs (if it's something obvious and easy to reproduce it's highly likely that someone has already reported it). If you can't find any ticket about the problem then file a new one with the steps to reproduce the problem (what's the browser, a sample page to load, what must be done after the page is loaded...) and then if it's confirmed it might be fixed in a future release.

If you don't report the bug with the proper steps to reproduce the problem then your problem might remain there for a long time, but even if you provide a clean set of steps to reproduce, just remember that browsers have bugs so maybe it can't be fixed because it would need some very complex workaround that can introduce other problems or it's just impossible to fix in javascript.

The best way to learn more about the new features is to read the announcement by Frederico and then download CKEditor 3.1 to test them.

Just remember that there's a lot of work going on in CKEditor as you can see in the roadmap.

CKFinder 1.4.2

The simple announcement by Wiktor explains it well, some little bugs, improved compatibility and new translations. The focus of the work is now on the new version that will try to address the missing features that are requested in the CKFinder forum and trying to look even further by making it possible to create more easily new features in the future that no one has dared to request.

There's one thing to notice about this release, as I explained in the previous post Firefox 3.6 hasn't included support of onreadystatechange and the previous versions of CKFinder fail to enable the upload button. The new release includes a little workaround so download CKFinder before your users upgrade to Firefox 3.6 and they call you to ask why does it fail.

Delivering code half-done in a web browser

Today I was checking something about CKFinder and I've realized that the Upload button doesn't work in the latest beta of Firefox 3.6.

That's strange and quite important as lots of people will be using it as soon as it is released, so I dug into the code to find out the problem. After tracing the differences in the execution of 3.5 and 3.6 I've finally found that when an iframe is created it finish the initialization by checking for document.readyState to avoid problems using an unfinished document in IE, and now that code was triggered also by Firefox 3.6

The fact that Firefox includes a property that was previously supported by IE (and IIRC also Opera and Webkit) shouldn't break anything, that code path uses the document.onreadystatechange to properly listen for the change of state and finish the initialization.

The real problem is that such event hasn't been added to Firefox, so the code never executes!

Everything was OK without support for document.readyState, but now they have added it without including the document.onreadystatechange, so things might get broken due to this big oversight. I suggest all of you to review your code and check for the usage of this event (not to be confused with XHR.onreadystatechange) because Firefox 3.6 might be a real pain for you if you don't patch your code it in due time.

Mozilla guys: thank you for bringing us this extra work.

Upload progress for Firefox 3.5

The new release of CKFinder 1.4 is due mainly to cover the integration with CKEditor 3, but it includes other little details, and I'm gonna talk about one of the here: the upload graph for Firefox 3.5

 

Firefox 3.5 might look boring for the users, it doesn't bring any special change to the interface or to the general options, but under the hood there are lot of changes for developers. Old bugs fixed, polishing, new features...  And among those new features there is something special for us: the ability to read the files picked with an <input type="file"> from javascript. Previously the only option was to read the filename and then submit the form to the server, without any ability to know how long it's taking.

A little history

In order to provide a progress bar you had to use some special coding at the server, so it could provide a progress info and poll that periodically. In some context it's far easier than in others, some require proprietary components, some require just a little script, but it's not easy to get it ready for every environment.

Then the Flash uploaders appeared. Macromedia did add a nice API to flash that allowed to easily pick several files from the user computer (of course, it's the user the one that selects the files) and then upload that data to the server, with event notification so now you can find several (lots?) of libraries to do that. One example is SWFUpload. But as far as I know, all of them have a problem due to the flash plugin itself: in non-IE browsers it fails to send back to the server the proper cookies, so it ruins the ability to keep authentication in the upload process. The trick then it's to send the data for the authentication cookie along the request and then recreate the session at the server with that info, I know that the code to do that in PHP and Asp.Net it's available and you can easily add that, but I've never seen such workarounds working for Asp (I don't know about CF). And even in Asp.Net you might need to alter files (global.asax) that you can't touch "to show a progress bar".

So as you can't see there is no easy solution "that works for everyone", but in the future that can be different.

The present

Starting with Firefox 3.5 you can use a new (non-standarized) API of the XmlHttpRequest: sendAsBinary. This post at hacks.mozilla.org  does explain it much better that I would be able to do in a lifetime.

So I went ahead and coded it for CKFinder.

• Pros:
  • No changes required at the server,
  • It's based on feature detection, so if any other browser adds these APIs it will automatically work.
• Cons:
  • Only Firefox 3.5,
  • We don't know how well it will perform with big files (1).

1: The Firefox API is based on reading the full contents of a file as a string and then sending it with a XHR, so if you pick a 1Mb file it means reading 1Mb of data, that looks easy. On the other side, if you are storing a 500Mb movie, then Firefox will go ahead and use in a moment 500Mb of additional memory. Wow, looks scary so we capped the feature so it's only triggered if the file is smaller than 20Mb.

The way that it's coded means that this is transparent to the user, he doesn't have to do anything and it will work. The form is just the same, the only change is the way that the data is sent to the server.

Other options

At the same time I evaluated the ability provided by Webkit that allowed to pass a file object to the XHR.Send() method, but it has some important drawbacks:

• It's not possible to do feature detection on the ability, so it would need to be hardcoded using UserAgent strings. That's not nice
• The file is sent to the server without any of the POST boundaries to wrap the data. That means that your standard code at the server won't work, you need to write special code to send the file name (easy) and then process the boundless data at the server (not so easy). In Firefox we have to add those boundaries, but the point is: It's possible to add them, so the server doesn't notice any difference between a standard form-post and this xhr.sendAsBinary()

There are lots of talk about this kind of features for inclusion in the new versions of XHR and related APIs, so I think that it's important to start testing what's available and provide feedback about what works and what fails.

I also tested the ability that Opera and Webkit offers to select multiple files with the <input type="file"> widget, and although it worked for Webkit, Opera did send the data using a set of headers that caused Asp.Net to consider it an attack, and crashed the AspUpload ActiveX from Persits (I didn't test it further as it was a dead road).

So in the future the ability to send multiple files with webkit might be added, also we will evaluate further the option to use a flash uploader so IE users get the option to both select multiple files and get a progress status, the important part is that the adjustments at the server side should remain within the CKFinder code, when you start requesting changes to global files then the problems start

Little bugs

Nevertheless, I don't think that the Firefox implementation is bug free.

The first problem is that the progress events are fired only when the server "consumes" the data. I mean: if you look carefully or put a sleep() at the server you will notice that the upload seems to stall at the end, although the data has been sent to the server, the browser doesn't notify that, it waits there, and looks strange.

As I said, reading the full file in memory doesn't look nice, it should be possible to request sending a file and the browser would read it just like it does with a normal form POST, it can read it little by little as it needs and with minimum overhead. In that situation we wouldn't need to restrict the maximum size, and this is important because getting progress info is more interesting when the file grows bigger.

If you notice any problem with this feature, please report it so we can look at it and fix it ASAP.

Releases

I wanted to post something about several releases of different products, but I didn't have the time until now.

Let's start from oldest to the most recent.

CKFinder 1.3

This release fixes all the problems (at least for asp) known in previous versions, it's the work of several months trying to debug each and every report from the users.

Adding over that, it also includes some enhancements like ability to select the thumbnails themselves and remember the last selected folder.

ImageMap 2.1

I still need some time to update the demo page (and zip) in my server. This is update is just the job of Adam, and the parts related to the FCKeditor plugin are the ability to use Zoom and general bug-fixes and memory leaks. I'll try to really test it asap but I'm a little busy :-(

Internet Explorer 8 RC1

It seems that this release can be really tested, they have fixed lots of bug (included the two that I reported related to FCKeditor), improved performance, and I guess that we all really should test it to avoid finding two months after release that we didn't test it and it did include some regression that makes us suffer again. I don't expect any other releases shortly, just like IE7 I guess that we will have to wait a lot for something new, so this is the time for us to test it and check that it's really getting closer to the rest of the browsers. Let's hope that hopefully IE8 along the release of Windows 7 (I guess that it will be released much sooner than most of the people expects it) makes IE6 fade away.

FCKeditor 2.64

This is one of the last releases of the 2.x series of FCKeditor. It includes lots of bug fixes, I would had included even more little fixes but time is finite and it isn't possible to do everything that one would like to. This release isn't just bug fixes, it also includes support for table headers and a zero-configuration online spellchecker. If you are using any 2.6x version it's a no-brainer to update, your users will be pleased if they ever faced any of the bugs and you shouldn't have any problem to use it.

Let's remember also, that the 3.x versions are called CKEditor and you can start taking a look at it right now with the first beta that has been released, the online demo of the nightlies is available here. Almost everything is being rewritten, it isn't an easy task but the results so far are looking great.

 

Optimizing the generation of gifs in .Net

While debugging some problems that a client had with CKFinder I found out that the thumbnails that were generated using the asp.net code of gif files were in reality png files, just a little oversight and should be easy to fix. Previously the code did test only for jpg files in order to adjust the quality, and the rest of extensions did were saved with

oResampled.Save( targetFile );

But as I said, the .Net framework doesn't check the extension of the file that you want to generate, instead it uses the png format.

So the new code just needed to do a switch:

switch ( extension )
{
    case ".gif":
        oResampled.Save( targetFile, System.Drawing.Imaging.ImageFormat.Gif );
        break ;
    case ".png":
        oResampled.Save( targetFile, System.Drawing.Imaging.ImageFormat.Png );
        break ;
    case ".bmp":
        oResampled.Save( targetFile, System.Drawing.Imaging.ImageFormat.Bmp );
        break ;
}
easy fix, isn't it?

You're wrong, for some strange design decision at MS, decreasing the palette from full color to 256 colors uses the infamous "web safe" palette, so your page will look again like those done at the start of the times, back when Nestcape was synonymous to Internet.

Why has the .Net team gone that way at this time and age?. I don't care, I didn't want to know why it's done that way, I just wanted to know how to do it the right way, how to specify a proper palette for the new file.

So searching a little you can find this very interesting article at MSDN that explains everything that you want to know about gifs and colors, it has links to other resources that try to explain the miracle that is a web safe palette, but it has been years since I saw a system that wasn't able to work with 24 bit-images.

That article does even include a sample that shows exactly how to do the quantization of images and provides also an implementation of an Octree palette generator. Too good to be true :-)

So there we go, add the class and quickly I see that there are some strange attributes on the classes. "unsafe", uh?

Let's recap: the article was written for the .Net Framework 1.1, and nowadays the servers in hosted providers are using mostly (AFAIK) Asp.net 2.0 in medium trust, so that code won't work at all.

Fortunately there was another nice blog by Brendan Tompkins that did found this same problem and does provide an explanation of the required changes in order to run properly. So I tested and now I didn't get the same compilation problems that I had with the original code, the unsafeness seemed to have gone away.

But when I tested really with medium trust, oh no!, a System.Security.SecurityException! Did I make something wrong?

I reviewed the changes and used directly the modified classes, nops, no way, it fails. Reading the comments I found that other people also reported the same problem but no one answered them. Could it be that initially the code did work in .Net 2.0 but some patch later the behavior was changed and now the calls to Marshal aren't allowed?

Searching to find the solution to this problem hasn't been successful, no one seems to know a solution and I spent one or two days reading everything that seemed interesting trying different combinations of search terms. Even trying to find another method to do the quantization hasn't been fruitful, there are questions posted in different places but no one has provided a positive answer.

Obviously I don't need to read the raw memory of the picture, using GetPixel seems that should be enough to create the palette, but this isn't the final solution because to generate the new picture with the specially created palette I need to specify the color/index of each pixel, and when you try to use SetPixel, you get:

"SetPixel is not supported for images with indexed pixel formats"

And again the solutions to this problem suggest to use the LockBits and then writing directly to memory, but that will fail in Medium Trust.

To recap:

• If you're running in High Trust, CKFinder 1.3 the asp.net or asp version (with asp.net handling) will create gif thumbnails correctly
• If you're in Medium Trust the call to create the 256-colors image will fail, and so far we haven't been able to find any solution. The GetPixel method is useful only for half of the process, it does still require direct memory access to create the new image so it hasn't been implemented. In this situation the "gif" image is really a 24-bit color png, not optimal and if someday the browsers stop sniffing the content of images they won't be shown, but hopefully before we reach that day MS would have released .Net v8 with some api to control the color-reduction method and/or SetPixel method expanded to handle indexed images.

CKFinder 1.2, now in your own language

Yesterday was released the new version of CKFinder, with one of the most important changes for 1.2 being the ability to show the interface in the language of each user.

Besides some fixes and improvements, another important addition is the ability to filter files and folders on the server, so by default all .* files are hidden, and it's possible to customize the filters so that it matches your needs.

With regards to the localization, in 1.2 there are four languages included (besides English): German, Italian, Polish and Spanish, but if you need to add another language you just have to follow the localization guide for CKFinder.

Of course, if you create any such translation the recommended procedure is to send it back so it can be added for the rest of the people and you don't have to worry about how to update it with any new version.

I hope that all of you enjoy this version.

 

CKFinder 1.1, an advanced Ajax File Manager

Today the new version of CKFinder 1.1 has seen the light after some months in development.

This version provides support for Asp and ColdFusion server hosting, provides improved security across all the environments, does bring support for Safari 3 and Opera 9.5 and fixes some little problems with some IE6 installations.

It also introduces the new documentation site for FCKeditor and CKFinder. It is still an ongoing task, but you should be able to find much more info and detailed explanations about how to configure and use these tools, please be gentile if there's something wrong or missing, you should know that developers hate to write documentation and that you must point them with a gun in order to stop coding and start writing in plain English ;-)

What's this CKFinder about?

If you still haven't checked it, CKFinder is a browser based file manager.

Its User Interface is written with HTML and Javascript (buzzword: AJAX) so the client doesn't need any plugin to run it. The new version provides support for the four major engines, as long as you are using a recent enough version. That means: due to marketshare there is support for IE going back to IE 5.5, with Firefox you need 1.5 or newer (or equivalent Gecko browser), Safari 3 does work, and with Opera you need to run the latest beta available for 9.5

On the server side, as I said this version does provide two new languages, so there are four different configurations where you can use it:

• PHP 4.3 and later
• IIS with Asp.Net 2.x
• IIS with classic Asp
• ColdFusion 6.1 and later, BlueDragon 7.0 and later

With a few lines of code you will be able to add some nice features to your web applications like allowing the users to browse some server folders, upload their files and select them (for inclusion in FCKeditor or any other related situation).

Security and working with different users at the same time has been a main topic since the start of the development, so it's possible to define in a simple file using your server language the way that CKFinder should work, for example:

• allow non-indentified users to only browse the folders.
• Users of type "editors" have the ability to upload pictures to the images folder. They have their own folder each one.
• "Administrator" users are allowed to delete folders and files
• etc...

All those names and features are just some suggestions that I wrote, you can fine tune the behavior to your specific needs, just site and pick pen and paper, write down the types of users that you need and what should each one of them be allowed to do, and then just configure the CKFinder with that roles and restrictions.

If you just want your registered users to upload some files, and there are no problems with regards to different roles, and you don't need either the abilities to manage uploaded files (renaming, deleting both files and folders), and usage of thumbnails, then the basic filemanager included with FCKeditor might fit your needs.