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.

Session id generation in the Java SockJS client is not sufficiently secure and could allow a user to send messages to another user’s session.

Note that this only affects users of the Java SockJS client, which generates its own session id. It does not affect browser clients even if they’re connecting to the same server.

Furthermore, since SockJS is a transport layer, when using a higher level messaging protocol on top such as STOMP over WebSocket with the spring-messaging module, application-level security may already be getting applied to STOMP messages and that can neutralize the impact of any potential attacks.

Some URLs were not santized correctly before use allowing an attacker to obtain any file on the file system that was also accessible to process in which the Spring web application was running.

Some URLs were not sanitized correctly before use allowing an attacker to obtain any file on the file system that was also accessible to process in which the Spring web application was running.

When using Spring Security's CAS Proxy ticket authentication a malicious CAS Service could trick another CAS Service into authenticating a proxy ticket that was not associated. This is due to the fact that the proxy ticket authentication uses the information from the HttpServletRequest which is populated based upon untrusted information within the HTTP request.

This means if there are access control restrictions on which CAS services can authenticate to one another, those restrictions can be bypassed.

If users are not using CAS Proxy tickets and not basing access control decisions based upon the CAS Service, then there is no impact to users.

When processing user provided XML documents, the Spring Framework did not disable by default the resolution of URI references in a DTD declaration. This enabled an XXE attack.

When a programmer does not specify the action on the Spring form, Spring automatically populates the action field with the requested uri. An attacker can use this to inject malicious content into the form.

The ActiveDirectoryLdapAuthenticator does not check the password length. If the directory allows anonymous binds then it may incorrectly authenticate a user who supplies an empty password.