4.1 KiB
3.0.4
Overview
- 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
- Changed
dev/tests/setdbanddev/tests/startsessionfrom session to cookie storage.
Details
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.
The nginx installation instructions
have also been updated to reflect those changes.
Security: Information exposure through web access on composer files
Severity: Low
Description: Composer 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.
The nginx installation instructions
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.
Upgrading
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)
Misc
- If you are using
dev/tests/setdbanddev/tests/startsession, you'll need to configure a secure token in order to encrypt the cookie value: Simply runsake dev/generatesecuretokenand add the resulting code to yourmysite/_config.php. Note that this functionality now requires the PHPmcryptextension.