PHP: уязвимости стека · Страница 156

silverstripe/framework ChangePasswordForm does not check `Member::canLogIn()`

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 to too many incorrect login attempts) but has been opened up to other uses.

• Обновитесь до 3.1.20
• Обновитесь до 3.2.5
• Обновитесь до 3.3.3
• Обновитесь до 3.4.1

silverstripe/framework password encryption salt not updated

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.

• Обновитесь до 3.1.20
• Обновитесь до 3.2.5
• Обновитесь до 3.3.3
• Обновитесь до 3.4.1

SilverStripe comments module includes version of jQuery vulnerable to Cross-site Scripting

The silverstripe/comments module, the cwp/starter-theme and the cwp/watea-theme include an outdated version of jQuery by default, which contains XSS vulnerabilities if user input is used in certain contexts. Though no known exploit has been found for these in the existing usage, user customisation to these themes could have made them exploitable. CWP 2.0.0 has been released with the fixed cwp/stater-theme and silverstripe/comments module, and SilverStripe 4.2.0 will be released with the fixed silverstripe-themes/simple theme.

• Обновитесь до 3.1.1

Cross-Site Scripting vulnerability in PHP Server Monitor

PHP Server Monitor, version 3.2.0, is vulnerable to an XSS via the /phpservermon-3.2.0/vendor/phpmailer/phpmailer/test_script/index.php page in all visible parameters. An attacker could create a specially crafted URL, send it to a victim and retrieve their session details.

• Обновитесь до 3.3.0

Multiple vulnerabilities in DOLIBARR's ERP CMS

Vulnerabilities in Dolibarr ERP - CRM that affect version 9.0.1 and allow SQL injection. These vulnerabilities could allow a remote attacker to send a specially crafted SQL query to the system and retrieve all the information stored in the database through the parameters viewstatut in /dolibarr/commande/list.php.

Multiple vulnerabilities in DOLIBARR's ERP CMS

Vulnerabilities in Dolibarr ERP - CRM that affect version 9.0.1 and allow SQL injection. These vulnerabilities could allow a remote attacker to send a specially crafted SQL query to the system and retrieve all the information stored in the database through the parameters sortorder y sortfield in /dolibarr/admin/dict.php.

silverstripe/framework ReadOnly transformation for formfields exploitable

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 forms automatically load values from request data (GET and POST), which enables malicious use of URLs if your form uses these fields and doesn't overwrite data o

• Обновитесь до 3.1.21
• Обновитесь до 3.2.6
• Обновитесь до 3.3.4
• Обновитесь до 3.4.2

Silverstripe Cross-site scripting vulnerability in VersionedRequestFilter

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.

• Обновитесь до 3.3.3
• Обновитесь до 3.4.1

Silverstripe Missing CSRF protection in login form

LoginForm calls disableSecurityToken(), which causes a "shared host domain" vulnerability: http://stackoverflow.com/a/15350123.

• Обновитесь до 3.1.19
• Обновитесь до 3.2.4
• Обновитесь до 3.3.2

Silverstripe Brute force bypass on default admin

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.

• Обновитесь до 3.1.19
• Обновитесь до 3.2.4
• Обновитесь до 3.3.2

Silverstripe XSS in CMS Edit Page

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.

• Обновитесь до 3.1.19
• Обновитесь до 3.2.4
• Обновитесь до 3.3.2

Silverstripe Hostname, IP and Protocol Spoofing through HTTP Headers

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 headers from connecting clients, this can lead to spoofing requests being passed through trusted proxies. The impact of spoofed headers can include Dire

• Обновитесь до 3.1.17
• Обновитесь до 3.2.2
• Обновитесь до 3.3.0

Silverstripe CSRF vulnerability in GridFieldAddExistingAutocompleter

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.

• Обновитесь до 3.1.17
• Обновитесь до 3.2.2
• Обновитесь до 3.3.0

Silverstripe Missing security check on dev/build/defaults

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 modified tables, allowing attackers more insight into which modules are used, and how the database tables are structured.

• Обновитесь до 3.1.17
• Обновитесь до 3.2.2
• Обновитесь до 3.3.0

Silverstripe HtmlEditor embed url sanitisation

"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 future changes would break this.

• Обновитесь до 3.2.1

Silverstripe Form field validation message XSS vulnerability

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.

• Обновитесь до 3.1.16
• Обновитесь до 3.2.1

Silverstripe framework is vulnerable to XSS in install.php

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.

• Обновитесь до 3.1.14

SilverStripe Vulnerability on 'isDev', 'isTest' and 'flush' $_GET validation

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 empty tokens fail the validation check.

• Обновитесь до 3.0.14
• Обновитесь до 3.1.13

Silverstripe XSS in dev/build returnURL Parameter

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.

• Обновитесь до 3.1.14

Silverstripe External redirection risk in Security?ReturnURL

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.

• Обновитесь до 3.0.14
• Обновитесь до 3.1.13