Tag
#vulnerability
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 as it does for existant users. This is a regression of [SS-2017-002](https://www.silverstripe.org/download/security-releases/ss-2017-002).
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 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 or SilverStripe Platform have additional configuration in place which prevents PHP script execution in assets, even in a malicious party manages to upload these into the folder.
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()`. `ViewableData::customise` is not vulnerable.
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.
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.
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.
By Owais Sultan Cloud security is crucial for businesses. Here are vital tips to safeguard your data, including choosing a secure… This is a post from HackRead.com Read the original post: Best Practices for Cloud Computing Security
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 more specific functionality which can be used to either access or alter user data. We have fixed the usage of isDev and isTest in SilverStripe 4.x, and removed the URL parameters in the next major release of SilverStripe.
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.