Blesta 3.0: API Design

This is the first article, in what will be a series for Blesta 3.0, our next major release. When we sat down to discuss the primary goals of Blesta 3.0, one of the first topics to come up was API design.  The two major issues we discovered with the original API design (of 1.0) were that:

1. It was limited in its capabilities
2. It was difficult and cumbersome to update

By implementing Blesta on top of an MVC framework (minPHP) we were able to create an automatic API, which eliminated both of these issues entirely.  Within an MVC application the model contains all of the business logic, so the only thing required to complete the API is a controller to handle access to the various models.  Since models are objects, the API controller can instantiate and access all of the public methods within a requested model.  This facilitates requests on logical objects that may perform specific actions.

In addition, the API controller could now fulfill requests in any number of various formats (e.g. json, xml, etc.).  The syntax was simple: /api/model/method.format.

The only thing necessary to complete the RESTful design were HTTP status codes, and the API controller easily handled those.  The result is an automatic RESTful API system, that not only grants access to the Blesta core, but to the back end of any plugins installed within that copy of Blesta as well.

In case you missed it, this means that ALL public model methods will be accessible through the API. We’re really excited about the new API and how much support it lends to developers.

Blesta 3.0 is currently in active development. A release date has not yet been determined.

minPHP Framework Released

           _       _____  _    _ _____
          (_)     |  __ \| |  | |  __ \
 _ __ ___  _ _ __ | |__) | |__| | |__) |
| '_ ` _ \| | '_ \|  ___/|  __  |  ___/
| | | | | | | | | | |    | |  | | |
|_| |_| |_|_|_| |_|_|    |_|  |_|_|
framework

minPHP is an extremely lightweight, object oriented MVC PHP framework brought to you by the same people who developed Blesta. minPHP is free, open source software released under the MIT license.

Download it at minphp.org.

One of the most awesome things about minPHP, aside from the fact that it’s awesome in itself, is that it’s being used as the framework for Blesta 3.0. Blesta 3.0 is in active development, with a release expected in the early part of next year.

We’re excited to be able to offer something to the open source community, and if you’re a developer we hope you give minPHP a try. As an added benefit, if you’re familiar with minPHP you’ll be a Blesta 3.0 development rockstar right out of the box.

Ooh, my spider-sense is tingling.

Suhosin

Suhosin is a (somewhat) commonly installed PHP module used by shared hosting providers to prevent (to some degree) malicious PHP code from compromising a shared environment.  Sounds great, but the problem is it spreads its tentacles into areas where, if unaware of its presence, can cause some very unexpected results.

This was the case in Blesta, until recently.

The issue experienced in Blesta was related to session handling.  Blesta uses a database to maintain session information, for added security and to permit load balancing.  Normally, a session ends when the user closes their browser, however it can be revive if a cookie is stored on the user’s machine and is then read when they revist the site.  But because Suhosin encrypts session data by default, our revival code had access to only encrypted data.  Essentially, the session couldn’t be revived.  The only way to decrypt the data is to have Suhosin do it.  So what we did was rename the session prior to starting it, which tricks PHP into thinking the session never ended, and so Suhosin takes over and decrypts the Session just in time.

The psuedo code looks something like this:

$session_id = $_COOKIE[‘session_id’];

session_name($session_id);

session_start();

PHP & C

For those familiar with C, PHP seems strikingly similar. From the syntax to the function calls. It’s almost as if you could replace a couple asterisks (*) with dollar signs ($) and add a PHP-tag or two, and you could run your C source raw.

#include <stdio.h>
 
main() {
	char *phrase = “hello world!n”;
	printf(“%s”, phrase);
}

<?php
function main() {
	$phrase = “hello world!n”;
	printf(“%s”, $phrase);
}
?>

The Big Blue C In recent time PHP has diverged from C’s familiar convention, in an attempt to offer a higher level experience. Much of this relates to IO. For example, PHP 4 required you to call fopen, then fwrite, and finally fclose in order to write content to a file, just as you would do in C. In PHP 5 file_put_contents was added in, which operates more of how you would expect from a scripting language. Although much has changed, some things likely never will. For example, command line parameters are handled in just about the same way. And while I haven’t viewed the source, I suspect fgetc directly invokes the C library. In fact, just about every function in the standard IO library (stdio.h) in ANSI C is represented in PHP. Static, Extern and Global PHP and C handle static variables within functions in exactly the same way. However, since PHP refuses to search the call stack outside of a function’s scope, a global keyword is required to pull these variables into scope so they can be used within a function. While this works similar to C’s extern declaration, unlike in C, you can’t ever use a variable defined outside a function, even if declared before the function, unless it is declared global or is one of the special “super global” types. C You Later PHP never had pointers, though they do offer references similar to Java. The difference being that a reference can’t be moved or reassigned as a pointer can using pointer arithmetic. PHP 5 raises errors when attempting to pass references to functions. While it’s still possible to pass by reference, the function or method signature must define it and the call must not include the ampersand (&). This is because, as of PHP 5, non-primitive types are implicitly passed by reference. While in some respects PHP has moved away from its C influence, in other aspects it’s become more similar. PHP 4, for example, added capabilities for variable length parameters, although in a much different way than C. Nevertheless, the C influence appears to be dwindling, in favor of higher level capabilities, such as XML parsing, and simpler IO. So it’s unlikely we’ll see new primitive C constructs, such as goto’s any time soon… or will we?

Encoding vs. Encryption

Encoding and encryption are both routines performed on data, however the end results are quite different. In the case of encryption the purpose is to disguise the data such that it can’t be read, except by the intended recipient. On the other hand, encoding is used merely to work the data into a more suitable format. Sometimes these methods are used in conjunction, as we’ll see later in this article, but frequently developers mistakenly substitute encryption with encoding, which can cause some very serious security issues.

While there are many different encoding algorithms, one of the most widely used in web development is base64. As the name suggests, base64 maps 6-bit blocks of binary data into 64 different character representations. The phrase “hello world!” in base64 encoding appears as “aGVsbG8gd29ybGQh,” a somewhat random looking set of characters. However, if we examine the string in more detail we see right away that a very limited set of characters are in use, and applying base64 decoding gives the original “hello world!” message back.

<?php 
echo base64_encode("hello world!"); // prints aGVsbG8gd29ybGQh
?>

A typical application for encoding is transmitting binary data across the Internet. If not encoded, the binary data will likely become corrupt. This is because some systems may interpret the data differently. To ensure this doesn’t happen we can encode the data before sending it, and decode it upon arrival.

It’s important to point out that encoding should never be used in place of encryption. The reason for this is due to the very nature of encoding, which allows data to be easily converted from one representation to another. Only the algorithm is needed, no key is required. To an attacker, it’s like coming across a front door with a dozen knobs and no lock. The only thing standing between them and what’s inside is finding the right knob to turn.

When storing or transmitting sensitive information encryption should always be used. As with encoding algorithms there are many different encryption algorithms (ciphers), perhaps even more than the former. It’s worth noting that ciphers typically have very short life spans, and while popular ciphers in use today have withstood rigorous attacks, it’s likely that will not always be the case.

What makes a good cipher is high entropy. The more random a string appears, the more difficult it is to crack. Because of this many encrypted strings contain unreadable characters, which can often be lost or corrupt when transmitting or reading. To prevent that from happening we can encode the encrypted string into a readable format before storing or transmitting. Anyway, let’s take a look at an example.

Our “hello world!” phrase, encrypted using the AES cipher looks like “R4OuDkO7P5Z6fLHzpuC8ZQ==” in base64 encoding, or “4783ae0e43bb3f967a7cb1f3a6e0bc65” in hexadecimal (I’ve left out the plain-text representation here because it contains almost no readable characters). The only way to convert this data back into its original form is to decrypt it using the same algorithm and key that was used to encrypt it. Since the key is kept private, an attacker will have a very difficult time recovering the plain text even if he knows the algorithm used.

It’s easy to mistake an encoded string with an encrypted string, especially if we assume an attacker has no idea what encoding is being used. For example, if we take our base64 encoded “hello world!” string and reverse it we get “hQGby92dg8GbsVGa.” An attacker may recognize this as a base64 encoded string, and it is a valid one, however, simply decoding this without first reversing the string will result in what appears to be a random collection of characters. While this may deter some attackers, it’s absolutely no substitute for encryption.

<?php 
$a = strrev(base64_encode("hello world!")); // $a = hQGby92dg8GbsVGa
echo base64_decode($a); // prints unreadable characters
echo base64_decode(strrev($a)); // prints hello world!
?>