This is documentation for Kohana v2.3.x.
Status | Draft |
---|---|
Todo | Complete this document |
This section will contain brief security considerations covering the following topics
CSRF vulnerabilities allow attackers to remotely target specific url's (typically form submission scripts), enabling them to send arbitrary HTTP requests that appear to be coming from a trusted user. For more information on CSRF visit: Shifflet.org
Some methods to defend against CSRF vulnerabilities include: limiting the lifetime of cookies used for authentication, checking HTTP Referer headers, using POST instead of GET to submit forms that require verification, and implementing validation tests to deter automated form submissions (including CAPTCHA tests and random tokens).
Tokens are randomly generated values that are unique to each form and typically exist within a user's session. By modifying sensitive forms to check for a valid token, it is more difficult for an attacker to target individual users, since a valid token is required.
Random tokens are easy to generate. Here are some typical functions:
uniqid()
: PHP function to generate a unique identifier based on the current time in microsecondstext::random()
: Kohana helper to generate random text strings/** View **/ // include the random token in your form view and add it to the user's session <?php echo form::hidden('token', $_SESSION['token'] = uniqid())?>
/** Controller **/ // This check would typically occur at the start of your validation logic. Since the form should not be processed if the token test fails. // ensure that a token was submitted and matches the token in the session if (empty($_POST['token']) OR (empty($_SESSION['token']) OR $_POST['token'] !== $_SESSION['token'])) { // do something here such as redirect the user or stop the script. url::redirect(Router::$current_uri); }
Using a token validation function:
If you need to do CSRF token validation on multiple forms, you could simplify your code by creating a validation function in your template controller [http://docs.kohanaphp.com/addons/template]. As long as your form handling controller extends the template controller (e.g. Website_Controller), your check_token function will be available.
// Add the following function to your template controller: protected function check_token($redirect = NULL) { if ( ! empty($_POST)) { if (empty($_POST['token']) OR empty($_SESSION['token']) OR ($_POST['token'] !== $_SESSION['token'])) { url::redirect($redirect ? $redirect : Router::$current_uri); } } return TRUE; }
// Call the function at the start of your validation logic: $this->check_token();
Cross-site_scripting (XSS) vulnerabilities allow attackers to insert malicious HTML/Javascript content into a website; potentially allowing them to bypass access controls, gain access to private cookie and sessions and obtain escalated privileges.
Some methods to defend against XSS vulnerabilities include: escaping and filtering user input, validating user input and securing cookies. Kohana has built-in features to help you reduce the risk of XSS in your applications. Kohana XSS Tutorial
Kohana offers the following built-in escaping and filtering functionality:
You can enable XSS filtering on all user input globally by setting $config['global_xss_filtering'] = TRUE;
in application/config.php
. This is recommended for most applications, but does incur a slight overhead. The global XSS filter will sanitize the $_GET, $_POST and $_COOKIE global arrays. It also removes the $_REQUEST array.
The Kohana Input library is the recommended way to access user input from the $_POST, $_GET, $_COOKIE and $_SERVER global arrays. If global XSS filtering is disabled, using the Input library allows you retrieve a sanitized version of the variable by setting xss_clean argument (3rd argument) to TRUE.
// retrieve a get variable, set a default value, enable xss_filtering $my_var = $this->input->get('my_var','default_value', true); // retrieve a post variable, no default value, enable xss_filtering $my_var = $this->input->post('my_var', null, true);
HTML Purifier is a third-party library that offers a higher-level of filtering than Kohana's built-in functions. It also offers the ability to convert invalid markup into standards-compliant markup. Kohana gives you the option of using HTML Purifier for data filtering. Keep in mind that using HTML Purifier will require some additional processing and memory usage.
Installing HTML Purifier in your Kohana application:
htmlpurifier-x.x/library
directory to your Kohana system/vendor/htmlpurifier
directory.Using HTML Purifier in your Kohana application
$config['global_xss_filtering'] = 'htmlpurifier';
in your application/config/config.php
.// from within your controller $this->input->xss_clean($var, 'htmlpurifier'); // from outside your controller $var = Input::instance()->xss_clean($var, 'htmlpurifier');
The Kohana Security Helper offers various methods that assist with input filtering.
The Kohana html::specialchars() method is part of the HTML helper. It is advisable to run all user input that is displayed on a web page through html:specialchars() to convert special characters and quotes to HTML entities.
echo html::specialchars($string);
Beyond escaping and filtering, validation is critical for all applications that enable users to input data via forms. Kohana includes a very powerful and flexible Validation libary along with a valid helper. The Validation libary allows you to validate any arbitrary array of data fields, including user submitted data in $_POST and $_GET. It also allows you to run pre- and post-filters on data. The valid helper includes methods for many common data validations including email-addresses, dates, phone numbers, ip's, url's, digits/numbers and text. It easily integrates with the Validation library.
You should always ensure that your cookies are only usable by your website domain. To do this in Kohana, copy system/config/cookie.php
to your local application/config
directory and set $config['domain']
to your domain when you move to production.
Also refer to the cookie helper for simple methods to create, retrieve and delete cookies.
Same as the RFI, but requires the malicious file to be present in the targeted server.
Refer to the Installation page.
Refer to the Deployment page.