The Frontier Group - Blog

Securing FCKEditor

April 6th, 2009, by aaron

FCKEditor is a third party WYSIWYG editor for websites that is used in a great number of applications across the web. The problem with using third party applications is that you can never be sure of the quality of the code, or of the security model they’re enforcing. In the case of FCKEditor the default installation can be extremely insecure and information on how to secure it is pretty thin on the ground.

There are a few things that can be done to improve the security of FCKEditor after installation so hopefully these few pointers will help.

Integrate Your Own Authentication
You can integrate some basic authentication fairly easily using an htaccess file and the php auto_prepend directive. This directive will basically tell the php engine to prepend any script with the file that you specify, it’s essentially the same as issuing a require() call before each page is run. We use this to run our own authentication scripts before access to any part of our application is run. There are parts of FCKEditor that are freely open to the public, so this is quite important unless you want your site to have anonymous users uploading anything to you.

Turn Off The PHP Engine in Your Upload Directories
FCKEditor does have some very basic checking included to try and stop users from being able to upload any sort of executable code to your application; but none of it works very well. The best way to circumvent this is to stop PHP from functioning inside your upload directories. What this means is that although a user could circumvent your security and upload some malicious code to your server all that will happen is your web server will serve back the content as plain text.

Remove FCKEditor’s Testing Pages
FCKEditor includes some basic forms that allow you to check that your configuration is correct for uploading and browsing your website. These forms if they remain publicly available provide a very handy access point for users to upload content to your site that they shouldn’t be. The file exists in /editor/filemanager/connectors/test.html and is there only to allow you to test the connectors, you should be deleting it. This step will not stop those progressing up to step one or two, but I see this as putting up some fake security cameras, it’ll stop some lazy criminals.

Hopefully these tips will help anyone that is using FCKEditor and is worrying about any holes in their security this might open up. Obviously these can be generically applied to any application that allows uploading to occur, however with FCKEditor being quite prominent in older applications it’s probably worthwhile just having a look at your app to see how secure your editor really is.

We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.


Cross Domain IFrame and Cookie Issues with IE7

February 12th, 2009, by aaron

This morning I had to solve a problem that involved an application inside an IFrame not keeping it’s session state. I’d solved this problem many times before, a long time ago, in a galaxy far far away, but still it stumped me again!

In this example we had two client websites we’ll call site-a.com and site-b.com. Site-a.com had a page that contained an IFrame which sourced it’s content from site-b.com. The page on site-b.com allowed the user to log in to the application that resides on the site-b.com domain and then click on various links that would take them to other areas in the site-b.com application.

This worked perfectly in Firefox and Safari, but in IE7 it failed and would not let the user log in. After setting up a test environment on my virtual machine and repeating the bug I went looking for a solution.

It turned out that what was required was a declaration by site-b.com that it was okay to do what I was trying to do. It seems that as long as site-b.com declares that it’s safe then the browser assumes this to be the case and it all starts to work.

The way this is done is through adding P3P info to the header of the response. Essentially what this does is say to the browser that your application is okay with taking information from other domains. Rather than relying on external security measures, you’ve taken the steps yourself to develop a secure application. This sort of setting can also be used for single sign on situations too where your cookies need to be accessible across domains and applications.

Typically it’s as simple as adding :

header('P3P: CP="CAO PSA OUR"');

to the page. You could also add it on the server level if required, but in this case it all takes place in an extranet module so it’s perfectly suitable to be applied only on one page. There are quite a few options that you can find on the P3P Specification.

So that’s how you get cross domain cookies to work with PHP. It’s much the same in other web frameworks, you just need to work out how to modify the headers in the one you’re using.

We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.


Making a Copy of an Object in PHP

February 5th, 2009, by aaron

In PHP4 objects were passed by value, it’s probably the intuitive way to deal with variables for a beginner and in a language where objects are not first class. However in PHP5 this has been changed and now objects are passed by reference, this stung me when writing some tests recently.

public function testNameIsUnique() {
	$test1 = $this->BuildValidDiscountType();
	$test2 = $test1;

	$test1->Save();
	$this->assertTrue($test1->id > 0);

	$this->setExpectedException('DiscountTypeException');
	$test2->Save();
}

This code shouldn’t have worked as far as I was concerned, in fact I was expecting an exception to be raised. Instead it was working and after a little debug tour I found that my $test1 = $test2 line was causing $test2 to be a reference to $test1, not what I wanted. This caused my update method to be triggered instead and of course the name is still unique.

It only required a small change to that line, using the clone specifier :

$test1 = clone $test2;

After that everything went as expected and I knocked off another test, and added to my PHP knowledge.

We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.


Bench marking instead of bench warming

December 16th, 2008, by mlambie

In August of this year we deployed a series of new server and storage devices which we expect will carry us through to 2011. One of the negative side effects of this deployment was that all of the sites and services we hosted on the new hardware performed significantly better than on the old configuration.

I hear you ask “how is that a negative side effect?” It meant that I put off the investigation into bench marking and tuning our server platforms simply because the move to newer hardware gave us significant gains. I had planned on doing some configuration tuning and system refinement, but the sheer increase in processing power meant that I didn’t bother with it back then.

Today, however, I decided to investigate what the addition of a PHP opcode cache would provide, and I was very happy with the results.

I came across an issue with running APC, the opcode cache developed by Rasmus and other core PHP developers, alongside the Zend Optimizer. The two are incompatible so you’ll have to play favourites and pick one or the other.

Installation of APC is easy on Ubuntu. There’s many guides online, but I found this one to be the most succinct. You end up installing the following packages (note: I didn’t have build-essential initially and PECL couldn’t build the package because I was missing make):

mlambie@prime:~$  sudo aptitude install php-pear php5-dev apache2-prefork-dev build-essential

The installation of APC is easy via PECL:

mlambie@prime:~$  sudo pecl install apc

Then enable the module by creating an apc.ini file:

mlambie@prime:~$ cat /etc/php5/apache2/conf.d/apc.ini
extension = apc.so
apc.enabled = 1
apc.shm_size = 48
apc.include_once_override = 1
apc.mmap_file_mask = /tmp/apc.XXXXXX

I ran some benchmarks using Apache Bench. The results were very encouraging. I saw a reduction in the time per request fall from 91ms to 37ms (250% improvement). The volume of requests per second increased from 11/sec to 27/sec (245% improvement). Lastly, 98% of all requests are served within 639ms instead of 1165ms (182% improvement).

Each actual apache process saw a significant memory reduction too, from 26MB down to 20MB (almost a 25% footprint saving). When you’ve got multiple processes running the reclaimed memory adds up quite quickly.

I found the figures staggering, and the improvements are actual, real things that are visible when interacting with the sites and applications hosted on prime.

It’s fair to say that we more then doubled our performance, from a single server, simply by adding PHP opcode cache. If you’re not running one on your server, you might want to consider why.

We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.


Dynamically Reducing Object Sizes in PHP

November 19th, 2008, by aaron

After using jQuery for quite a while I’ve become quite attached to using the power of callbacks when dealing with sets of data. I’ve seen equally and perhaps better abilities in Ruby but of course had been let down in the past by PHP’s lack of abilities as a dynamic language.

Today I faced an issue due to the size of my objects. The problem essentially came down to the fact that for the largest objects such as Contact objects the amount of data passed back to the client when doing AJAX calls was pretty sizeable. I wanted to write a function that given a set of property names all the returning objects would be stripped of all but those properties.

I didn’t want to write a function for each set of properties I’d return, so I wrote a generic function that given an array of property names that was all that would be returned from that object and it was surprisingly easy and I think in the end highly dynamic and useful.

It uses the PHP array_walk() function which I’ve never used before. It’s a lot like the Array.each() methods that many other languages have.

	private function GetContacts() {
		$filter = RequestQuerystring('filter');
		$properties = RequestAll('properties');

		if (isset($properties)) {
			$properties = explode(',', $properties);
		}

		if (isset($filter)) {
			$contacts = [large_objects]
		}

		if (isset($contacts) && is_array($properties)) {
			array_walk($contacts, 'mod_ajax::FilterObjects', $properties);
		}

		echo json_encode($contacts);

	}

	private static function FilterObjects(&$object, $key, $properties) {
		foreach (get_object_vars($object) as $k => $v) {
			if (!in_array($k, $properties)) {
				unset($object->$k);
			}
		}
	}

Basically for this array of large objects on each one we call FilterObjects. That has to be a function or static method which I learned as I went. The object is passed in by reference so that any change made to it is reflected in the original array, and it just goes through the variables (properties) of the object and kills anything that isn’t in the allowable parameter list.

This allows me to trim large objects dynamically for any of my client side calls for data and I think is definitely going to save me time in the future. I remember when I first started using PHP I wrote a function for each object to spit out XML, then I progressed to JSON, now I’ve got a nice filter method.

I still feel like there must be a better way to do things, but quite possibly that would exist in another language.

We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.


Follow Us

Stay in the Loop

  • Enter your email address to subscribe to our mailing list. You'll get updates about our products, specials and bonus offers, and general behind the scenes news from our team.

Twitter

Newsletters

Alexa Rank

Testimonial

The boys at The Frontier Group are amazing! For such a relaxed and personable organisation, they have phenomenal technical ability and a rampant professionalism. They have customisable solutions for all of my IT needs and they always deliver, on time and beyond expectation.

They fix problems other service providers can't and they helped me get a critical section of my web site up and running 10 minutes after I emailed the request!

Alex Hyndman, Nexus Car Share.

Featured Project

Case Study - Caudo Group - www.caudo.com.au

Website

www.caudo.com.au

Caudo Machinery

Caudo Group engaged our services to redesign their outdated website. We sent our photographer on-site to capture the essence of their business and turned it into a stunning web design.