SQL injection is a serious concern for developers, and there are a number of ways of dealing with it; however the best, and most proven method, is through parameter binding. What parameter binding does is substitute variable data within a query with parameters, which are then replaced by the database driver during query execution. Since the database driver is intimately aware of which parts of the query are parameters it can parse the query and then execute it with the bound parameters safely set.

The framework that Blesta 3 is built on, minPHP, handles parameter binding through use of the PDO extension. But because writing queries is tedious and prone to typos, minPHP offers a database access object to interface with PDO in the Record class.

A query that would otherwise looks like this…

 
$this->query("SELECT `users`.`first_name`, `users`.`last_name` FROM `users` WHERE `id`=?", 3);

becomes…

 
$this->Record->select(array("users.first_name","users.last_name"))->from("users")->where("id", "=", 3);

No need to worry about syntax, semantics, escaping data, or back-ticks. That’s all handled by the computer, which loves performing tedious operations over and over.

We’ll look at how to overcome cross site scripting (XSS) vulnerabilities next week.

Tags: blesta 3.0 | minphp | security | sql injection

Security is a constantly evolving field in computing. Following Moore’s law, computational power essentially doubles every 18 months. Even brute forcing strong encryption algorithms can become, at least theoretically, feasible over the span of a decade.

With Blesta 3.0, we’re looking into the future. — way into the future. We’re designing security measures today that will easily keep data secure beyond 2030. Why? Because even if you never update your software, your data should continue to be secure long into the future.

So how do we do it? By using trusted, non-proprietary ciphers such as AES and RSA, with large keys, we’re able to protect data from brute force attacks. To encryption algorithms, the larger the key the more secure the encrypted data.

Why would you need to encrypt a credit card in such a way that it’s safe from attacks for 20+ years? The answer: You wouldn’t. Credit cards generally expire less than 10 years after issuance. But nevertheless, why take the chance?

Here’s how it works in Blesta 3.0:

Credit cards are encrypted using RSA, a public key cipher. This allows cards to be encrypted using one key (the public key), and only decrypted using a separate private key. This facilitates adding card numbers to the database without requiring admin approval or storing a private key on the system. Depending on your specific security requirements, you can choose to store the private key on your system (encrypted of course), to allow automatic payment processing, or you can choose to set a passphrase that must be entered whenever you wish a card to be decrypted.

Setting a passphrase for your private key is optional, but adds an additional layer of security. A passphrase can be added or removed at any time, without having to decrypt and re-encrypt credit cards. So your passphrase can be changed on a regular basis, which is always a good idea — especially for larger organizations.

Some merchant gateways are now allowing credit card numbers to be stored within their own secure systems. Invoking a charge is as simple as passing in a unique identifier, and the amount to be charged. We’re building support for this into version 3.0 as well..

In addition to credit cards, module data can also be encrypted

Blesta handles security in other areas well too, including XSS (Cross Site Scripting) and SQL Injection attacks and we’ll touch on these in a future article.

Blesta 3.0 is currently in active development.

Tags: AES | blesta 3.0 | encryption | RSA | security