Spring Security Advisories

Applications that do not change the value of the MvcViewFactoryCreator useSpringBinding property which is disabled by default (i.e. set to “false”) can be vulnerable to malicious EL expressions in view states that process form submissions but do not have a sub-element to declare explicit data binding property mappings.

Spring Security does not consider URL path parameters when processing security constraints. By adding a URL path parameter with an encoded "/" to a request, an attacker may be able to bypass a security constraint. The root cause of this issue is a lack of clarity regarding the handling of path parameters in the Servlet Specification (see below). Some Servlet containers include path parameters in the value returned for getPathInfo() and some do not. Spring Security uses the value returned by getPathInfo() as part of the process of mapping requests to security constraints. The unexpected presence of path parameters can cause a constraint to be bypassed.

Users of Apache Tomcat (all current versions) are not affected by this vulnerability since Tomcat follows the guidance previously provided by the Servlet Expert group and strips path parameters from the value returned by getContextPath(), getServletPath() and getPathInfo() [1].

Users of other Servlet containers based on Apache Tomcat may or may not be affected depending on whether or not the handling of path parameters has been modified.

Users of IBM WebSphere Application Server 8.5.x are known to be affected.

Users of other containers that implement the Servlet specification may be affected.

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=25015

Paths provided to the ResourceServlet were not properly sanitized and as a result exposed to directory traversal attacks.

Sort instances handed into user defined Spring Data repository query methods using manually declared JPQL queries are handed to the persistence provider as is and allow attackers to inject arbitrary JPQL into ORDER BY clauses which they might use to draw conclusions about non-exposed fields based on the query result's element order changing depending on the injected JPQL.

This especially comes into play if the Sort instances are created from untrustable sources, e.g. web request parameters.

Both Spring Security and the Spring Framework rely on URL pattern mappings for authorization and for mapping requests to controllers respectively.

Differences in the strictness of the pattern matching mechanisms, for example with regards to space…

When processing authorization requests using the whitelabel views, the response_type parameter value was executed as Spring SpEL which enabled a malicious user to trigger remote code execution via the crafting of the value for response_type.

The class org.springframework.core.serializer.DefaultDeserializer does not validate the deserialized object against a whitelist. By supplying a crafted serialized object like Chris Frohoff's Commons Collection gadget, remote code execution can be achieved.

When authorizing an application against an OAuth 2 API provider, Spring Social is vulnerable to a Cross-Site Request Forgery (CSRF) attack. The attack involves a malicious user beginning an OAuth 2 authorization flow using a fake account with an OAuth 2 API provider, but completing it by tricking the victim into visiting the callback request in their browser. As a consequence, the attacker will have access to the victim's account on the vulnerable site by way of the fake provider account.

Under some situations, the Spring Framework is vulnerable to a Reflected File Download (RFD) attack. The attack involves a malicious user crafting a URL with a batch script extension that results in the response being downloaded rather than rendered and also includes some input reflected in the response.

For details and concrete examples see the very helpful RFD paper from Trustwave.

XML external entities were previously disabled with the publication of http://pivotal.io/security/cve-2013-6429. If DTD is not entirely disabled, inline DTD declarations can be used to perform Denial of Service attacks known as XML bombs. Such declarations are both well-formed and valid according to XML schema rules but when parsed can cause out of memory errors. To protect against this kind of attack DTD support must be disabled by setting the disallow-doctype-dec feature in the DOM and SAX APIs to true and by setting the supportDTD property in the StAX API to false.

This is now done in the Spring Framework by default wherever the framework sets up XML parsing from external sources. Mainly this includes the Unmarshaller implementations in spring-oxm and the HttpMessageConverter implementations in spring-web.

Note that further actions may need to be taken by applications in particular where use of StAX is concerned. For example IBM JDK 1.6 and 1.7 require an environment variable in addition to setting supportDTD=false (see IBM JDK reference). Moreover we’ve found that supportDTD alone does not protect against all kinds of DoS attacks with JDK JAXP implementations. Hence we recommend using the Woodstox open source library for StAX parsing.

The following describes when StAX is used in the Spring Framework:

• SourceHttpMessageConverter -- enabled by default. The converter was added in 3.2 while StAX support was added in 4.0.1 and is used when converting to Spring MVC controller method argument of type javax.xml.transform.stax.StAXSource.
• Jaxb2CollectionHttpMessageConverter -- not enabled by default. This converter was added in 3.2.
• MappingJackson2XmlHttpMessageConverter -- enabled when “jackson-dataformat-xml” is present on the classpath. This converter was added in 4.1.