Fuel takes security very serious, and as a result, has implemented the following measures to ensure the safety of your web applications:
By default, Fuel doesn't filter POST and GET variables on input, and encodes everything on output.
Fuel also encodes the URI to prevent nasty surprises when using URI segments, and escapes everything going into the database.
This page explains the general security measures Fuel offers, the Security
class is documented under Classes. You will also find the details on configuring Fuels security class on that page.
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.
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
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.
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
// using a form instance, will also add a validation rule to forms fieldset
$form = \Form::forge();
To manually check if the form has been submitted by the client that requested the form:
// check if a form was submitted
// check for a valid CSRF token
if ( ! \Security::check_token())
// CSRF attack or expired CSRF token
// token is valid, you can process the form input
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.
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 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.
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.