#git

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.

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

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.

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.

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 Director::forceSSL() not being enforced, SS_HTTPRequest->getIP() returning a wrong IP (disabling any IP restrictions), and spoofed hostnames circumventing any hostname-specific restrictions enforced in SilverStripe Controllers. Regardless on running a reverse proxy in your hosting infrastructure, please follow the instructions on Secure Coding: Reques...

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.

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.

"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.

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.

Plus, SS7 vulnerabilities are being exploited and BreachForums is taken down again.