Movable Type 4.2 and Security

Movable Type has a long track record of excellent security practices. In Movable Type 4.2 not only did we invest the time into auditing our code for performance benefits, but we also walked through the code line-by-line looking for ways in which we could improve security.

However, before we discuss what we did specifically in Movable Type 4.2 to make things even more secure, let’s review some of the things inherent in Movable Type’s design that make it more secure than the average blogging system:

1. Data abstraction layer. Movable Type uses a data abstraction layer that prevents any core application component, any plugin and/or any theme from having direct access to your database. This is beneficial not just from a data security standpoint, but it also makes SQL injection attacks nearly impossible because all calls to the database are generated programmatically.
2. Input filtering. All form inputs are routed through a set of filters to make sure that data is escaped properly. A common vulnerability found in web applications is when data input by a user is echoed right back to the browser without being escaped. This provides hackers with a way to inject javascript onto your published page, an exploit commonly referred to as a cross-site scripting vulnerability, or XSS.
3. Request tokens. One common technique used by hackers is called a “replay attack” where they intercept a request from a session and are then able to resend it after making slight modifications to it. Movable Type includes in all form submissions include an encrypted timestamp known as a “token.” These tokens prevent the same form request from occurring after a certain time frame and makes replay attacks much more difficult.
4. Static HTML. Movable Type publishes static HTML making it virtually impossible for a plugin or theme to introduce malicious PHP code or application logic that could compromise your system, your content or your stability.
5. RSync Publishing. Movable Type is capable of publishing your site and then rsyncing your files via SSH to a set of servers of your choice. This allows you to have an entire site published to a set of machines from which it is impossible to access your database. Therefore, in the worst case scenario where a hacker gains physical access to your servers, the damage they can do is dramatically reduced and they have no way to access sensitive customer information.
6. CGI based. CGI applications like Perl and Ruby have inherent security benefits over languages like PHP because of security requirements and policies enforced by the web server itself. While these policies can be overridden by administrators, their presence can provide an added level of confidence in knowing that even if the web application itself is compromised, the web server provides a safety net to keep malicious hackers from gaining access to your system, or corrupting your data.

What’s New in Movable Type 4.2

In Movable Type 4.2 we took additional steps to make Movable Type secure. First, we fixed a number of security vulnerabilities. Many of these vulnerabilities were also found in previous versions of Movable Type so we also issued updates for all supported versions of Movable Type, going back to Movable Type 3.36.

• We incorporated into our test suite third party tools that routinely scan for vulnerabilities. Not only did this help us isolate and address a small hand full of vulnerabilities in Movable Type, it also gives us and our customers the assurance that new code will continually be scanned prior to release for vulnerabilities.
• We centralized and augmented input filtering. One XSS exploit we discovered that affects older browsers like IE6 is a mixed character encoding issue. These browsers are unable to distinguish between characters encoded in two different formats and thus will mistakingly interpret them. If these characters translate into javascript code, then that code will be executed. Movable Type ensures that all data published to the page is published in a single character set and will filter content as necessary to avoid this vulnerability.
• We conducted a line-by-line security audit of all the logic that processes form input from the application and users. We were scanning for unescaped input that has the potential for being echoed back to the browser. We found a number of potential vulnerabilities, confirmed which were actual vulnerabilities, and then we fixed them.

Creating and maintaining a secure web application takes constant vigilance, and no one can claim they are 100% secure. We feel security should never be an after thought, security must be woven into the fabric of your application and the very processes that produce that application.