silverstripe-framework/docs/en/changelogs/3.0.4.md

# 3.0.4 (2013-02-19)

## Overview

 * Security: Undefined or empty `$allowed_actions` overrides parent definitions
 * Security: Information leakage through web access on YAML configuration files
 * Security: Information leakage through web access on composer files
 * Security: Require ADMIN permissions for `?showtemplate=1`
 * Security: Reflected XSS in custom date/time formats in admin/security
 * Security: Stored XSS in the "New Group" dialog
 * Security: Reflected XSS in CMS status messages
 * API: More restrictive `$allowed_actions` checks for `Controller` when used with `Extension`
 * Changed `dev/tests/setdb` and `dev/tests/startsession` from session to cookie storage.

## Details

### Security: Undefined or empty `$allowed_actions` overrides parent definitions

Severity: Important

Description: `Controller` (and subclasses) failed to enforce `$allowed_action` restrictions
on parent classes if a child class didn't have it explicitly defined, or it is set to an empty array.
Since this is the default configuration on `Page_Controller`, most SilverStripe installations
will be affected.

Impact: Depends on the used controller code. For any method with public visibility,
the flaw can expose the return value of the method (unless it fails due to wrong arguments).
It can also lead to unauthorized or unintended execution of logic, e.g. modifying the
state of a database record.

Fix: Apply 3.0.4 update. In addition, we strongly recommend to define `$allowed_actions`
on all controller classes to ensure the intentions are clearly communicated.
Read more about `$allowed_actions` in our "[controller](/topics/controller/#access-control)"
docs.

Reporter: Zann St Pierre

### Security: Information exposure through web access on YAML configuration files

Severity: Moderate

Description: YAML files are used to configure the SilverStripe application
since its 3.0 release. These files can contain sensitive values such as database
and API credentials. By default, the installer still stores database credentials
in `_config.php` files which are safe from web access. So this only concerns
configuration values added in your own project, or a third party module.

Resolution: Update your `.htaccess` file (for Apache), or your `web.config` file (for IIS)
with the new files from the project root, and reapply any customizations you've made.
Follow the [general upgrade instructions](/installation/upgrading).
The [nginx installation instructions](/installation/nginx)
have also been updated to reflect those changes.

### Security: Information exposure through web access on composer files

Severity: Low

Description: [Composer](http://getcomposer.org) is a dependency management
tool which can optionally be used to install SilverStripe. The `composer.json`
and `composer.lock` files are required for its operation, so they are included 
in the standard release since 3.0.2. These files contain information on the installed
versions of core and thirdparty modules, which could be used to target specific
versions of SilverStripe.

Resolution: Update your `.htaccess` file (for Apache), or your `web.config` file (for IIS)
with the new files from the project root, and reapply any customizations you've made.
Follow the [general upgrade instructions](/installation/upgrading).
The [nginx installation instructions](/installation/nginx)
have also been updated to reflect those changes.


### Security: Require ADMIN permissions for `?showtemplate=1`

Severity: Low

Description: Avoids information leakage of compiled template data,
which might expose some of the internal template logic.

### Security: Reflected XSS in custom date/time formats in admin/security

Severity: Low

Prerequisite: An attacker must have access to the admin interface.

Description: When creating a new user on the security page 
(Security->New User) within the admin interface, the user input 
is not properly validated and not encoded. A reflected XSS is 
possible within the `DateFormat_custom` and `TimeFormat_custom` fields.

Credits: Andreas Hunkeler (Compass Security AG, http://www.csnc.ch)

### Security: Stored XSS in the "New Group" dialog

Severity: Low

Prerequisite: An attacker must have access to the admin interface.

Description: There is a stored XSS vulnerability on the "group" tab on the 
security page in the admin interface 
(Security -> Groups -> New Group). It's possible to store a 
XSS within the group name. Everywhere where these group names 
are used, the XSS is executed. E.g. "New User" or "New Group".

Credits: Andreas Hunkeler (Compass Security AG, http://www.csnc.ch)

### Security: XSS in CMS status messages

Severity: Low

Prerequisite: An attacker must have access to the admin interface.

Description: Any data returned to CMS status messages (Growl-style popovers on top right)
was not escaped, allowing XSS e.g. when publishing a page with
a specifically crafted "Title" field.

Credits: Andreas Hunkeler (Compass Security AG, http://www.csnc.ch)

### API: More restrictive `$allowed_actions` checks for `Controller` when used with `Extension`

Controllers which are extended with `$allowed_actions` (through an `Extension`)
now deny access to methods defined on the controller, unless this class also has them in its own
`$allowed_actions` definition.

## Upgrading

 * If you are using `dev/tests/setdb` and `dev/tests/startsession`,
   you'll need to configure a secure token in order to encrypt the cookie value:
   Simply run `sake dev/generatesecuretoken` and add the resulting code to your `mysite/_config.php`.
   Note that this functionality now requires the PHP `mcrypt` extension.