TinyMCE v6 has a configuration value convert_unsafe_embeds set to false which allows svg files containing javascript to be used in <object> or <embed> tags, which can be used as a vector for XSS attacks. Note that <embed> tags are not allowed by default. After patching the default value of convert_unsafe_embeds will be set to true. This means that <object> tags will be converted to iframes instead the next time the …
A bad actor with access to edit content in the CMS could send a specifically crafted encoded payload to the server, which could be used to inject a JavaScript payload on the front end of the site. The payload would be sanitised on the client-side, but server-side sanitisation doesn't catch it. The server-side sanitisation logic has been updated to sanitise against this type of attack.
When running SilverStripe 3.7 or 4.x in dev mode with the mysqli database driver, there is a potential to disclose the connection details. We have denylisted the sensitive parts of the connection information from being included in dev mode stack traces when database errors occur.
A potential SQL injection vulnerability was identified by using the silverstripe/postgresql database adapter. While unlikely to be exploitable, we have patched silverstripe/framework to ensure that table names are safely escaped before being passed to database adapters or user code.
A possible denial of service attack vector has been identified in the dev/build system controller. dev/build now has its own URL token, similar to flushtoken, to ensure users are authenticated when running dev/build outside of dev environments.
A security protection device in Session designed to protect session hijacking was not correctly functioning. This function intended to protect user sessions by detecting changes in the User-Agent header, but modifications to this header were not correctly invalidating the user session.
The URL parameters isDev and isTest are accessible to unauthenticated users who access a SilverStripe website or application. This allows unauthorised users to expose information that is usually hidden on production environments such as verbose errors (including backtraces) and other debugging tools only available to sites running in "dev mode". Core functionality does not expose user data through these methods. Depending on your website configuration, community modules might have added …
If remember me is on and users log in with the box checked, if the developer then disabled "remember me" function, any pre-existing cookies will continue to authenticate users.
When accessing the install.php script it is possible to extract any pre-configured database or default admin account password by viewing the source of the page, and inspecting the value property of the password fields.
The core template framework/templates/Includes/GridField_print.ss uses "Printed by $Member.Name". If the currently logged in members first name or surname contain XSS, this prints the raw HTML out, because Member->getName() just returns the raw FirstName + Surname as a string, which is injected directly.
User enumeration is possible by performing a timing attack on the login or password reset pages with user credentials.
There is a user ID enumeration vulnerability in our brute force error messages. Users that don't exist in will never get a locked out message Users that do exist, will get a locked out message This means an attacker can infer or confirm user details that exist in the member table. This issue has been resolved by ensuring that login attempt logging and lockout process works equivalently for non-existent users …
List of key / value pairs assigned to OptionsetField or CheckboxSetField do not have a default casting assigned to them. The effect of this is a potential XSS vulnerability in lists where either key or value contain unescaped HTML.
All user login attempts are logged in the database in the LoginAttempt table. However, this table contains information in plain text, and may possible contain sensitive information, such as user passwords mis-typed into the username field. In order to address this a one-way hash is applied to the Email field before being stored.
A weakness in the .htaccess rules preventing requests to uploaded PHP scripts allows PHP scripts that had made their way into the assets directory to be successfully executed through the use of a specially crafted URL. There are protections in place to disallow upload of PHP scripts through the CMS, meaning this weakness does not lead to direct vulnerabilities. In addition, sites hosted on the New Zealand Common Web Platform …
When performing a fulltext search in SilverStripe 4.0.0 the 'start' querystring parameter is never escaped safely. This exposes a possible SQL injection vulnerability. The issue exists in 3.5 and 3.6 but is less vulnerable, as SearchForm sanitises these variables prior to passing to mysql.
Under some circumstances a form may populate a PasswordField with submitted data, reflecting submitted data back to a user. The user will only see their own submissions for password data, which is not considered best practice. We are not aware of data leaks to other users, devices or sessions.
A member with the permission EDIT_PERMISSIONS and access to the "Security" section is able to re-assign themselves (or another member) to ADMIN level. CMS Fields for the member are constructed using DirectGroups instead of Groups relation which results in bypassing security logic preventing privilege escalation.
When a user changes their password, the internal salt used for hashing their password is not updated. Although this is not considered a security vulnerability, this behaviour has been improved to ensure the salt is reset on change of password.
The SS_Report, and the reports CMS section only checks canView() when listing the reports that can be viewed by the current user. It does not (and should) perform canView checks when the report is actually viewed, so if you know the URL to a report and can otherwise access the Reports section of the CMS, you can view any report.
There is a user ID enumeration vulnerability in our brute force error messages. Users that don't exist in will never get a locked out message Users that do exist, will get a locked out message This means an attacker can infer or confirm user details that exist in the member table. This issue has been resolved by ensuring that login attempt logging and lockout process works equivalently for non-existent users …
RedirectorPage will allow users to specify a non-url malicious script as the redirection path without validation. Users which follow this url may allow this script to execute within their browser.
silverstripe/framework is vulnerable to XSS in Page name where the payload "><svg/onload=alert(/xss/)> will trigger an XSS alert.
Authenticated user with page edit permission can craft HTML, which when rendered in a page history comparison can execute client scripts.
In follow up to SS-2016-001 there is yet a minor unresolved fix to incorrectly encoded URL.
In the CSV export feature of the CMS it's possible for the output to contain macros and scripts, which if imported without sanitisation into software (including Microsoft Excel) may be executed. In order to safeguard against this threat all potentially executable cell values exported from CSV will be prepended with a literal tab character.
There is a vulnerability whereby arbitrary global functions may be executed if malicious user input is passed through to in the second argument of ViewableData::renderWith. This argument resolves associative arrays as template placeholders. This exploit requires that user code has been written which makes use of the second argument in renderWith and where user input is passed directly as a value in an associative array without sanitisation such as Convert::raw2xml(). …
After performing a password reset, ChangePasswordForm::doChangePassword() logs in the user without checking Member::canLogIn(). This presents an issue for sites that are using the extension point in that method to deny access to users (for example members that have not been “approved”, or members that have had their access revoked temporarily). It looks like Member::canLogIn() was originally designed to only be used for checking whether the user is locked out (due …
A carefully constructed malformed URL can be used to circumvent the offsite redirection protection used on BackURL parameters. This could lead to users entering sensitive data in malicious websites instead of the intended one.
Some potentially dangerous file types exist in File.allowed_extensions which could allow a malicious CMS user to upload files that then get executed in the security context of the website. We have removed the ability to upload .css, .js, .potm, .dotm, .xltm and .jar files in the default configuration. Since allowed_extensions are synced to webserver configuration (in assets/.htaccess) automatically, this will also deny access to any existing uploads with these extensions. …
Form fields returning isReadonly() as true are vulnerable to reflected XSS injections. This includes ReadonlyField, LookupField, HTMLReadonlyField, as well as special purpose fields like TimeField_Readonly. Values submitted to through these form fields are not filtered out from the form session data, and might be shown to the user depending on the form behaviour. For example, form validation errors cause the form to re-render with previously submitted values by default. SilverStripe …
A cross-site scripting vulnerability has been discovered in the TreeDropdownField and TreeMultiSelectField. This vulnerability can only be exploited if a user with CMS access has posted malicious or unescaped HTML into any of the dataobjects used as a data source for either of these fields. This has been resolved by ensuring that all dataobjects used as a data source have their content safely encoded.
A high level XSS vulnerability has been discovered in the SilverStripe framework which causes links containing hash anchors (E.g. href="#anchor") to be rewritten in an unsafe way. The rewriteHashlinks option on SSViewer will rewrite these to contain the current url, although without adequate escaping, meaning that HTML could be injected via injecting unsafe values to any page via the querystring. Due to the nature of this issue it is likely …
A cross-site scripting vulnerability has been discovered in the print view of GridField. This vulnerability can only be exploited if a user with CMS access has posted malicious or unescaped HTML into any field of an object in a GridField, and the print feature is used. This has been resolved by ensuring that the print feature safely escapes all fields.
A cross-site scripting vulnerability has been discovered in the FormAction field where a user-specified title may be specified.
A low level XSS vulnerability has been found in the Framework affecting http redirection via the Director::force_redirect method. Attempts to redirect to a url may generate HTML which is not safely escaped, and may pose a risk of XSS in some environments. This vulnerability is marked low as it is difficult to exploit, as any injected HTML will only be returned from the server if the Location HTTP header is …
A XSS risk exists in the returnURL parameter passed to dev/build. An unvalidated url could cause the user to redirect to an unverified third party url outside of the site. This issue is resolved in framework 3.1.14 stable release.
Due to a lack of parameter sanitisation a carefully crafted URL could be used to inject arbitrary HTML into the CMS Edit page. An attacker could create a URL and share it with a site administrator to perform an attack.
A potential hostname injection vulnerability has been found which could allow attackers to alter url resolution. If a request contains the X-Forwarded-Host HTTP header a website would then use its value in place of the actual HTTP hostname. In cases where caching is enabled, this could allow an attacker to potentially embed a remote url as the base_url for any site. This would then cause other visitors to the site …
When a secure token parameter is provided to a SilverStripe site (such as isDev or flush) an empty token parameter can be provided in order to bypass normal authentication parameters. For instance, http://www.mysite.com/?isDev=1&isDevtoken will force a site to dev mode. Alternatively, "flush" could also be used in succession to cause excessive load on a victim site and risk denial of service. The fix in this case is to ensure that …
The buildDefaults method on DevelopmentAdmin is missing a permission check. In live mode, if you access /dev/build, you are requested to login first. However, if you access /dev/build/defaults, then the action is performed without any login check. This should be protected in the same way that /dev/build is. The buildDefaults view is requireDefaultRecords() on each DataObject class, and hence has the potential to modify database state. It also lists all …
LoginForm calls disableSecurityToken(), which causes a "shared host domain" vulnerability: http://stackoverflow.com/a/15350123.
Non IE browsers don’t appear to be affected, but I haven’t tested a wide range of browsers to be sure Requests that come through from IE do NOT appear to encode all entities in the URL string, meaning they are inserted into output content directly by SSViewer::process() when rewriting hashlinks, as it directly outputs $_SERVER[‘REQUEST_URI’] Example IE8 request 127.0.0.1 - - [18/Jun/2014:14:13:42 +1000] “GET /site/cars/brands/toyota?one=1\”onmouseover=\”alert(‘things’);\” HTTP/1.1” 200 Example FF request …
"Add from URL" doesn't clearly sanitise URL server side HtmlEditorField_Toolbar has an action HtmlEditorField_Toolbar#viewfile, which gets called by the CMS when adding a media "from a URL" (i.e. via oembed). This action gets the URL to add in the GET parameter FileURL. However it doesn't do any URL sanitising server side. The current logic will pass this through to Oembed, which will probably reject most dangerous URLs, but it's possible …
In it's default configuration, SilverStripe trusts all originating IPs to include HTTP headers for Hostname, IP and Protocol. This enables reverse proxies to forward requests while still retaining the original request information. Trusted IPs can be limited via the SS_TRUSTED_PROXY_IPS constant. Even with this restriction in place, SilverStripe trusts a variety of HTTP headers due to different proxy notations (e.g. X-Forwarded-For vs. Client-IP). Unless a proxy explicitly unsets invalid HTTP …
A low level vulnerability has been found in the SilverStripe framework, where the Quadratic Blowup Attack could potentially be exploited to affect the performance of a site. See http://mashable.com/2014/08/06/wordpress-xml-blowup-dos/ for a writeup.
During installation, certain parameters (admin_username and admin_password) are not escaped in the setup form. This issue is resolved in 3.1.14 stable, although existing users are advised to remove this file prior to deploying to a production server.
A high level XSS risk has been identified in the encoding of validation messages in certain FormField classes. Certain fields such as the NumericField and DropdownField have been identified, but any form field which presents any invalid content as a part of its validation response will be at risk.
A vulnerability has been found in the SilverStripe framework where a login url can be potentially redirected to an external site. For example, the url http://www.my-silverstripe-site.com/Security/login?BackURL=/\attacker-site.com will redirect successful logins to the page http://attacker-site.com. If that website were set up to look identical to the first with "login failed" then the user will likely just enter their user/pass again.
GridField does not have sufficient CSRF protection, meaning that in some cases users with CMS access can be tricked into posting unspecified data into the CMS from external websites. Amongst other default CMS interfaces, GridField is used for management of groups, users and permissions in the CMS. The resolution for this issue is to ensure that all gridFieldAlterAction submissions are checked for the SecurityID token during submission.
A cross-site scripting vulnerability in VersionedRequestFilter has been found. If an incoming user request should not be able to access the requested stage, an error message is created for display on the CMS login page that they are redirected to. In this error message, the URL of the requested page is interpolated into the error message without being escaped; hence, arbitrary HTML can be injected into the CMS login page.
Default Administrator accounts were not subject to the same brute force protection afforded to other Member accounts. Failed login counts were not logged for default admins resulting in unlimited attempts on the default admin username and password.
Silverstripe Framework is the framework that forms the base of the Silverstripe content management system. Prior to versions 4.13.39 and 5.1.11, if a user should not be able to see a record, but that record can be added to a GridField using the GridFieldAddExistingAutocompleter component, the record's title can be accessed by that user. Versions 4.13.39 and 5.1.11 contain a fix for this issue.