3.0.4 changelog update

This commit is contained in:
Ingo Schommer 2013-01-04 18:21:26 +01:00
parent f8bbc0a726
commit 303352926b

View File

@ -5,11 +5,14 @@
* 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/setdb` and `dev/tests/startsession` from session to cookie storage.
## Details
### Security: Prevent web access to YAML and composer files
### Security: Information exposure through web access on YAML configuration files
Severity: Moderate
@ -52,6 +55,47 @@ 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/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`.