Documentation

Output encoding

By default, Fuel favors output encoding to input filtering. The reason behind this is twofold. No matter where your data originates, and whether or not it is filtered, output encoding will make it harmless when it is send to the client. It also means all input is stored in raw and unaltered form, so that no matter what happens, you will always have access to the original data.

It also means you don't run into trouble when you need data in its unaltered form. One common example is the data produced by html editors like TinyMCE or ckeditor, used in lots of application for enduser content editing. In such cases you might want to run XSS Filtering on these input variables to filter out any nasty surprises that might have crept in, since this is a typical example of data you don't want to encode on output either.

Since output encoding can only happen on strings, you have to pay attention to objects you want to pass to your views. Either make sure your object contains a __toString() method on which the encoding can take place, add your object class to the class whitelist in the security configuration (don't forget the namespace!), or pass it to the view with the $encode flag set to false. You can also use the auto_encode method to temporary disable automatic output encoding on a per-view basis.

See the section on view security to see how this is implemented for views.

CSRF Protection

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser. The attack works by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have been authenticated.

For example, one user, Bob, might be browsing a chat forum where another user, Mallory, has posted a message. Suppose that Mallory has crafted an HTML image element that references an action on Bob's bank's website (rather than for example an image file). If Bob's bank keeps his authentication information in a cookie, and if the cookie hasn't expired, then the attempt by Bob's browser to load the image will submit the withdrawal form with his cookie, thus authorizing a transaction without Bob's approval. source: wikipedia

Fuel provides you the tools to protect your forms against this kind of attacks, by including a security token in the form, which will can be validated upon form submission, and will ensure that when validated, the form was submitted by the client that has requested the form.

CSRF protection can be configured through the security section in the applications config/config.php file.

To enable CRSF protection, start by adding the token to your form:

// in plain HTML
<input type="hidden" name="<?php echo \Config::get('security.csrf_token_key');?>" value="<?php echo \Security::fetch_token();?>" />

// using the Form class
echo \Form::csrf();

// using a form instance, will also add a validation rule to forms fieldset
$form = \Form::forge();
$form->add_csrf();

To manually check if the form has been submitted by the client that requested the form:

// check if a form was submitted
if ($_POST)
{
	// check for a valid CSRF token
	if ( ! \Security::check_token())
	{
		// CSRF attack or expired CSRF token
	}
	else
	{
		// token is valid, you can process the form input
	}
}

XSS filtering

Fuel provides XSS filtering using the HTMLawed library, a very fast and highly configurable library. By default it runs in safe and balanced mode.

Safe refers to HTML that is restricted to reduce the vulnerability for scripting attacks (such as XSS) based on HTML code which otherwise may still be legal and compliant with the HTML standard specs. When elements such as script and object, and attributes such as onmouseover and style are allowed in the input text, an input writer can introduce malevolent HTML code.

In balanced mode, HTMLawed checks and corrects the input to have properly balanced tags and legal element content (i.e., any element nesting should be valid, and plain text may be present only in the content of elements that allow them).

For performance reasons, it is recommended that you use the xss_clean method on individual input values, rather than as a generic input filter.

Input filtering

Although not enabled by default, you can configure Fuel to filter all input ($_GET, $_POST and $_COOKIE) on every page request. To do so, configure the functions or methods to be used to filter them in the application's config/config.php file.

/**
 * Security settings
 */
'security' => array(
    'input_filter' => array(),
)

Anything that is callable in PHP and accepts a single value as parameter can be used for filtering purposes. This includes PHP functions like 'htmlentities', static class methods like '\\Security::xss_clean' or even object methods which are defined as array($object, 'method'). If you use an object method, make sure the object is available before Fuel is initialized, as input filtering happens very early in the request process.

SQL injection

SQL injection is a code injection technique that exploits a security vulnerability occurring in the database layer of an application (like queries). The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another. SQL injection attacks are also known as SQL insertion attacks.
This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into an SQL statement. This results in the potential manipulation of the statements performed on the database by the end-user of the application. source: wikipedia

Fuel protects against SQL injection by escaping all values passed to one of the Database class methods. Since this happens at the level of Fuel's central Query Builder, all code that uses the Query Builder, including Fuel's ORM package, will automatically use escaping.