HTTP Public Key Pinning (HPKP) is a security mechanism which allows HTTPS websites
to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates.
(For example, sometimes attackers can compromise certificate authorities,
and then can mis-issue certificates for a web origin.)
The HTTPS web server serves a list of public key hashes, and on subsequent connections
clients expect that server to use 1 or more of those public keys in its certificate chain.
This commit will add this new functionality.
Fixes gh-3706
Modifying the SecurityContext on the same Thread can cause issues. For example, with a
RejectedExecutionHandler the SecurityContext may be cleared out on the original Thread.
This change modifies both the DelegatingSecurityContextRunnable and DelegatingSecurityContextCallable to,
by default, only modify the SecurityContext if they are invoked on a new Thread. The behavior can be changed
by setting the property enableOnOrigionalThread to true.
Previously SecurityContextHolderAwareRequestWrapper always prefixed with
rolePrefix. This meant the defaults would never return true for a role
that started with the prefix (i.e. ROLE_).
We no longer apply the rolePrefix if the value passed in already starts
with rolePrefix.
This ensures that Spring Session & Security's logic for performing
a save on the response being committed can easily be kept in synch.
Further this ensures that the SecurityContext is now persisted when
the response body meets the content length.
Previously there were some incorrect dependency versions. This commit fixes
that.
We added dependencyManagement for Spring Framework and corrected
Thymeleaf and embedded redis versions.
Previously DefaultLoginPageGeneratingFilter would match on /**/login
which was not ideal since other parts of the application may want to
match on the URL.
Now it matches on /login.
Previously, if the Principal returned by getPreAuthenticatedPrincipal was not a String,
it prevented requiresAuthentication from detecting when the Principal was the same.
This caused the need to authenticate the user for every request even when the Principal
did not change.
Now requiresAuthentication will check to see if the result of
getPreAuthenticatedPrincipal is equal to the current Authentication.getPrincipal().
Add the DelegatingAuthenticationFailureHandler class to support
map each exception to AuthenticationFailureHandler. This class gives
more powerful options to customize default behavior for users.
Previously SavedRequestAwareWrapper overrode the getCookies() method. This
meant that the cookies from the original request were used instead of the
new request. In general, this does not make sense since cookies are
automatically submitted in every request by a client. Additionally, this
caused problems with using a locale cookie that was specified after the
secured page was requested.
Now SavedRequestAwareWrapper uses the new incoming request for determining
the cookies.
In order to get better error messages (avoid NullPointerException) the
HttpSessionEventPublisher now gets the required ApplicationContext which
throws an IllegalStateException with a good error message.
A number of projects had duplicate dependencies on their classpaths
as a result of the same classes being available in more than one
artifact, each with different Maven coordinates. Typically this only
affected the tests, but meant that the actual classes that were
loaded was somewhat unpredictable and had the potential to vary
between an IDE and the command line depending on the order in which
the aritfacts appeared on the classpath. This commit adds a number of
exclusions to remove such duplicates.
In addition to the new exclusions, notable other changes are:
- Spring Data JPA has been updated to 1.4.1. This brings its
transitive dependency upon spring-data-commons into line with
Spring LDAP's and prevents both spring-data-commons-core and
spring-data-commons from being on the classpath
- All Servlet API dependencies have been updated to use the official
artifact with all transitive dependencies on unofficial servlet API
artifacts being excluded.
- In places, groovy has been replaced with groovy-all. This removes
some duplicates caused by groovy's transitive dependencies.
- JUnit has been updated to 4.11 which brings its transitive Hamcrest
dependency into line with other components.
There appears to be a bug in Gradle which means that some exclusions
applied to an artifact do not work reliably. To work around this
problem it has been necessary to apply some exclusions at the
configuration level
Conflicts:
samples/messages-jc/pom.xml
Striping off all leading schemes in the DefaultRedirectStrategy, so it
will be less vulnerable to open redirect phishing attacks. More info can
be found at SEC-2177 JIRA issue.
Previously there was unecessary complexity in CsrfRequestDataValueProcessor
due to the non-passive changes in RequestDataValueProcessor. Now it simply
implements the interface with the methods for both versions of the interface.
This works since linking happens at runtime.
Previously session fixation protection could output an incorrect warning
that session fixation protection did not work.
The code now synchronizes on WebUtils.getSessionMutex(..).
Previously a ClassCastException was thrown if the type was invalid. Now
a flag exists on AuthenticationPrincipal which indicates if a
ClassCastException should be thrown or not with the default being no error.
This also removed the CsrfToken from the response headers to prevent the
token from being saved. If user's wish to return the CsrfToken in the
response headers, they should use the CsrfToken found on the request.
Previously AbstractSecurityWebApplicationInitializer delegated to a
WebApplicationInitializer, but it caused issues in some instances where
a container would pass the annonymous inner class to
SpringServletContainerInitializer which caused errors on startup.
Now AbstractSecurityWebApplicationInitializer registers the
ContextLoaderListener on its own instead of delegating.
Added JavaConfig for Headers. In the process, more HeaderWriter instances
were added so that we can reuse logic between the XML and JavaConfig. This
also prompted repackaging the writers.
This is a distinct filter as apposed to reusing StaticHeaderWriter
since the specification specifies that the "Strict-Transport-Security"
header should only be set on secure requests. It would not make sense to
require DelegatingRequestMatcherHeaderWriter since this requirement is
in the specification.
- hf.doFilter is missing FilterChain argument
- response.headers does not contain the exact values for the headers so
should not be used for comparison (note it is a private member so this
is acceptable)
- hf does not need non-null check when hf.doFilter is invoked
- some of the configurations are no longer valid (i.e. ALLOW-FROM
requires strategy)
- Some error messages needed updated (some could still use improvement)
- No validation for missing header name or value
- rebased off master / merged
- nsa=frame-options-strategy id should use - not =
- FramewOptionsHeaderFactory did not produce "ALLOW-FROM " prefix of origin
- remove @Override on interface overrides to work with JDK5
- Implemented different ALLOW-FROM strategies as specified in the proposal.
Conflicts:
config/src/main/java/org/springframework/security/config/http/HeadersBeanDefinitionParser.java
config/src/test/groovy/org/springframework/security/config/http/HttpHeadersConfigTests.groovy
Created HeadersFilter for setting security headers added including a
bean definition parser for easy configuration of the headers. Enables
easy configuration for the X-Frame-Options, X-XSS-Protection and
X-Content-Type-Options headers. Also allows for additional headers to
be added.
Session fixation protection, whether by clean new session or
migrated session, now publishes an event when a session is
migrated or its ID is changed. This enables application developers
to keep track of the session ID of a particular authentication
from the time the authentication is successful until the time
of logout. Previously this was not possible since session
migration changed the session ID and there was no way to
reliably detect that.
Revised changes per Rob Winch's suggestions.
Previously Spring Security would disable automatically saving the
SecurityContext when the Thread was different than the Thread that
created the SaveContextOnUpdateOrErrorResponseWrapper. This worked for
many cases, but could cause issues when a timeout occurred. The problem
is that a Thread can be reused to process the timeout since the Threads
are pooled. This means that a timeout of a request trigger an apparent
logout as described in the following workflow:
- The SecurityContext was established on the SecurityContextHolder
- An Async request was made
- The SecurityContextHolder would be cleared out
- The Async request times out
- The Async request would be dispatched back to the container upon
timing out. If the container reused the same Thread to process the
timeout as the original request, Spring Security would attempt to
save the SecurityContext when the response was committed. Since the
SecurityContextHolder was still cleared out it removes the
SecurityContext from the HttpSession
Spring Security will now prevent the SecurityContext from automatically
being saved when the response is committed as soon as
HttpServletRequest#startAsync() or
ServletRequest#startAsync(ServletRequest,ServletResponse) is called.
Both overloads of
AbstractAuthenticationProcessingFilter.successfulAuthentication()
claimed to invoke SessionAuthenticationStrategy, which is not true, as
the invokation happens earlier in doFilter(). The Javadoc on these
methods are updated to reflect the actual code.
Previously DummyRequest implemented HttpServletRequest which caused complications
since Servlet 2.5 and Servlet 3 had non passive changes. While we were "safe" if the
Servlet 3 methods were never invoked reflective access of the methods would also
problems. We could prevent users from accessing the methods of DummyRequest by
returning new HttpServletRequestWrapper(DummyRequest), but a debugger could
potentially try to iterate over the methods triggering a NoClassDefFoundError.
DummyRequest now extends HttpServletRequestWrapper which will be dynamically
linked to the proper version of HttpServletRequest. We use a Dynamic Proxy that
throws UnsupportedOperationException to implement any methods we are not
interested in.
Previously SecurityContextCallableProcessingInterceptor used afterCompletion
to clear the SecurityContextHolder. This does not work since afterCompletion
is invoked on the Servlet Container thread.
Now SecurityContextCallableProcessingInterceptor clears the
SecurityContextHolder on postProcess which is invoked on the same thread
that the Callable is processed on.
Previously, if the Principal returned by getPreAuthenticatedPrincipal was not a String,
it prevented requiresAuthentication from detecting when the Principal was the same.
This caused the need to authenticate the user for every request even when the Principal
did not change.
Now requiresAuthentication will check to see if the result of
getPreAuthenticatedPrincipal is equal to the current Authentication.getPrincipal().
Previously a NullPointerException would occur if an HttpServletRequest.getMethod()
returned null.
Now AntPathRequestMatcher and RegexpRequestMatcher will handle if the
HttpServletRequest.getMethod() returns null. While under normal circumstances,
it is unlikely for the method to be null this can occur when using
DefaultWebInvocationPrivilegeEvaluator.isAllowed(String, Authentication).
Shazin Sadakath
Rob Winch
Tim Ysewyn
Andrei Ivanov
Rob Winch
Alex Panchenko
izeye
zhanhb
Thomas Darimont
Gunnar Hillert
Pascal Gehl
Michael Cramer
Marcin Mielnicki
Stillglade
Rob Winch
Kazuki Shimizu
Spring Buildmaster
bcecchinato
Mattias Severson
Maciej Zasada
Julien Dubois
getvictor
David Alberto
Adrien be
kazuki43zoo
Marten Deinum
Keesun Baik
Nicholas Williams
Balazs Zagyvai