EE 1.4 is out

Last Friday, pmachine.com has release version 1.4 of Expression Engine.  EE is what I use to run this website.  This quite an upgrade and I’m really looking forward to flexing the muscle behind some of these new capabilities.

I’ve updated the backend running this website to the last version.  There are a couple of new features:

  1. All entries (Main section, Book area) now have versioning.  So I can make changes to an entry and feel safe I have the old version.  I have it set to save 10 old versions of an entry.
    http://eedocs.pmachine.com/cp/publish/index.html#tab_revisions
  2. Search term logs.  Site now remembers what people search for using the built in search utility. 
    http://eedocs.pmachine.com/cp/admin/utilities/search_log.html
  3. Mailing list notification.  I’ll get an email when someone signs up for the mailing list.
    http://eedocs.pmachine.com/cp/admin/system_preferences/mailinglist_preferences.html
  4. Mailing list templates: Standard footer info (signature, unsubscribe info) are now standard on outgoing Mailing list modules emails.
    http://eedocs.pmachine.com/modules/mailing_list/control_panel/index.html

A full list of changes for this new update are here:
http://eedocs.pmachine.com/changelog.html#v140

In the pMachine forums, somebody was asking about EE security.  Rick Ellis, the CEO, gave this explanation of EE security practices.  Thought it was interesting:

================================
We’re extremely dilegent about security.  Paul and I both subscribe to various security sites that post information regarding exploits in other programs.  Every time a a new exploit is discovered in other programs we’ll do a security review in EE to see if something similar could be used.  And whenever we release anything new we’ll do a thorough security reviews.  So far, we’ve never found a single exploit that worked in EE, due to the fact that we don’t allow URL query strings and we filter the hell out of user submitted data.  Actually, I take that back.  There was a vulnerability in some XML-RPC code in an early version of EE since the code was based on an open source script.  That code is long gone, even though it was implemented in a way that was not all that susceptible.  If you’re curious, here’s a list of some of the security stuff we do in EE:

1.  EE doesn’t use URL “query strings”.  Most web apps have URLs that look like this:

http://www.somesite.com/index.php?weblog=1&category=34&order=asc

A common exploit is to submit a URL string containing malicious data formatted in a way that can be passed to the scripts.  EE doesn’t use those types of URLs, or even accept URLs if they are formatted that way.  EE uses very simple segment based URLs:

index.php/site/joe/34/

The GET data that is requested when you load an EE page is stringently filtered.  We don’t allow any programatic characters, like ampersands, pound signs, hex characters, etc., and the segments must follow rigid conventions.  We also disallow many combinations of characters, like “http://” or “www” to be submitted in segments.  Many of the accepted characters are also converted to safe entities.  Simply said, it is impossible to submit something malicious as a GET string in EE.

2.  EE filters user submitted data.  All GET, POST, and COOKIE data is meticulously filtered.  All programatic characters are escaped, all reserved characters are converted to entities, etc., both in the global array keys and values, so that even if something malicious is submitted as a comment, email, entry, cookie, etc. EE won’t allow it to be turned into executable code, or stored in the database as executable code.

3.  No individual files can be loaded.  If you try to directly load any EE file in your system folder you’ll get an error message.  Any given EE file must be requested through a very controlled process originating from your index file.  The EE files individually are useless, and the process for file inclusion includes a number of checks to ensure the files being included are safe.

4. All path data is filtered.  Another common technique to compromise a site is to try to include a malicious file from a remote server.  EE checks all path data as it’s requested to ensure that only local files are accepted.

5. EE removes XSS data.  “Cross site scripting” exploits, that utilize javascript, HTML, cookie data, etc. are very common.  EE filters all data through an XSS filter, converting any characters that might be used within an exploit to safe entities.

6.  EE filters user submitted links and image tags.  All javascript event handlers are removed from these items, as well as other characters that are not standard.

7.  All database queries are filtered so that reserved mysql and programatic PHP characters are stored safely.

================================

Forum thread here:
http://www.pmachine.com/forums/viewthread/29456/

Posted by Jake Covert on 12/18/2005, evening

Comments

There are no comments yet for this entry.

Add a comment.