How can I prevent CSRF protection using Tomcat 7 ?
I have heard that tomcat 7 provides CSRF filter
http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/filters/CsrfPreventionFilter.html
But is it thread safe ?
Or shall we do a custom protection in our spring 3 application ?
CsrfPreventionFilter is a good way to prevent CSRF attacks, altough it's part of the tomcat code base and is based on putting the token in the URL.
This means the token will be logged etc, it's better to put the token in a hidden field in each form of the page.
Spring security 3.2 will have built-in support, and the solution would also work in other application servers. But depending on your application there is probably no need for building a custom protection at the spring level, the tomcat solution works OK.
The tomcat filter is thread-safe, given that each http request is handled from beginning to end by one thread, and that the token cache has synchronized access.
Related
I am building a small spring boot/ angular app that will be diplayed inside an iframe of another app. Basically a small tool for adding / editing contracts. I have not implemented spring security, because the whole authentication thing is done by the parent app. There is only 1 way to reach my app, through that another app. The parent app will send me the login and thats all.
The problem is, I cannot open my app inside the another, because of the x-frame-options: deny header. Is there a way to change this header without implementing the whole spring security thing. Or maybe implementing only the HttpSecurity part with disabling x-frame-options. Implementing the whole spring security would be an overkill for that small app, so I really hope there is some another option in spring boot, or maybe server side (WildFly 20).
I am using spring boot 2.7.0.
Thanks in advance.
If you implement Content-Security-Policy frame-ancestors directive it will override X-Frame-Options (Except for IE, which no longer should be a problem). You need to find a way to set the header in the same response as X-Frame-Options, this could likely be in code, webserver, proxy, or a load balancer. In the frame-ancestors directive, list the host names of all allowed hosts.
I have a single grails (3.3.5) web server, and I am interested in improving the availability and I'd like to add another server and put a load balancer in front of it.
Rather than share sessions between servers, or use sticky sessions, i'd like to know if there is a good way to have a session-less front-end server. I don't use sessions for anything other than using spring-security to validate the session token that it is using to identify the user.
I'd like to find a token based authentication system suitable for the front-end such that the token is safe and sufficient for identifying the current user.
I've seen the grails-spring-security-rest plugin which looks promising, but it seems like everyone is using it for back-end rest api calls. Is it also suitable for front-end authentication when you aren't storing application data in the webapp session?
If you don't use the session objects in your controller then tomcat will not create any sessions for you.
Also you can define your controllers to be
static singleton = true
then they will be instantiated not on per-request basis.
Now, if you still want to use sessions, you can use something like Cookie Sessions and keep your data inside the cookies instead of tomcat's memory.
I haven't used the grails-spring-security-rest, but you should be able to tweak spring-security-core to be session-less. You should set scr.allowSessionCreation to false and use remember-me.
Since Grails is built on Spring Boot, you can access all the features of Spring Session (https://docs.spring.io/spring-session/docs/2.0.x/reference/html5/), which includes the ability to share session data between server instances with some data store instead of keeping it in memory.
In those docs you'll find this pointer to a guide with a Grails 3.1 example that uses Redis as the store. https://github.com/spring-projects/spring-session/tree/2.0.3.RELEASE/samples/misc/grails3
Is it also suitable for front-end authentication when you aren't storing application data in the webapp session?
Yes, you can use JWT tokens in your front-end. You need to properly configure the security filters of your controllers so that they are not using cookie for authentication but they are looking for JWT.
See : http://alvarosanchez.github.io/grails-spring-security-rest/latest/docs/#_plugin_configuration for configuration of endpoints that should validate JWT tokens.
Have a look at https://github.com/hantsy/angularjs-grails-sample/wiki/3-basic-auth for a stateless example with Angular.
I have enabled CSRF in my Spring + Thymeleaf application. The good thing is that Thymeleaf automatically takes care of adding CSRF to every < form > in html. The problem is that Ajax calls submitting those forms are now failing and I want to know if there is a standard solution to this.
The other issue on the other hand is that my application is going to support Restful APIs. When I am enabling CSRF in my application, the authentication from client using API fails.
So the question is that is there a way to enable CSRF for web browsing and disable it for my Restful API?
On the other hand disabling the CSRF makes restful APIs vulnerable to attacks if the attacker knows about them. So what is the best practice here?
Thanks
For First Scenario to submit form using ajax call you need to manually add hidden input generated by csrf in form.
For second case you can exclude some url from interceptor in your case you can exclude url from CSRF interceptor.
exclude tag is present in spring 3.2
<mvc:interceptor>
<mvc:exclude-mapping path="/your_url"/>
</mvc:interceptors>
I have a Spring MVC application that uses Spring Security to handle user login authentication, which works fine.
Now I want to add some Ember.js and Angular.js code to the HTML pages that accesses the Spring RESTful web services (which just return JSON data).
How do I bind the user login authentication to the authentication for the RESTful web services? In other words, I want to make it so that the RESTful web services can only be accessed once a user has logged in. That way, the Angular.js and Ember.js libraries can access these RESTful web services securely from my user pages only without anyone else being able to directly call them.
I read on one other post that Spring Security was never meant to be used with a full Ajax framework, is that true? I hope this is not the case. I'd imagine that this type of thing must be pretty common now as there are so many AJAX client side frameworks that work based off accessing a JSON/RESTful API.
It is certainly not true that Spring Security was never meant to be or cannot be used in AJAX applications. I have two applications in production that use Spring Security as well as AJAX and more applications under development with the same mix.
If you are going to use EmberJS or AngularJS in an existing web application with Spring Security working, you should not face too many problems if you simply add the JavaScript library to your project. This is because once your users are authenticated, any normal HTTP requests will be treated as authenticated as well because the browser will ensure that session information is passed back and forth using cookies or URL parameters, as appropriate. You can see one of my working examples on Github for Spring Security and EmberJS integration.
The only thing you may need to worry about is CSRF tokens for form submissions using AJAX. The latest Spring Security documentation has a small section dedicated to this so you should not face too many problems getting that to work either. However, I would like to clarify that this particular issue is not specific to Spring Security. CSRF protection typically involves including a secure, randomly generated token with every HTTP POST request. The challenge arises from making existing JavaScript libraries aware of this token and how it should be included in HTTP POST requests. This would be a challenge in any application, not just those using Spring Security.
If however you will work with stateless clients, such as, mobile devices, you will be unable to rely on the default Spring Security mechanism of storing the user credentials in HTTP Session because HTTP requests will not have information to tie them to a session. This again is not specific to a Spring or Spring Security application because the constraint is imposed by the nature of the client and the client-server communication rather than any server-side technology. In such circumstances you will need to pass some authentication token in the HTTP headers for the application to maintain security state on the server side. I have a working example for this as well. If you need more details, there are articles on the web that explain how to do something like this with Spring Security.
I need to use Concurrent Session Control features of Spring Security. I need to invalidate the previous session of the logged in user(single user sign in). I do not need the feature of authentication and authorization, since it was already implemented by the application using Servlet(Filter) which calls serice layer that calls dao layer(Hibernate).
Please guide me how to implement Concurrent Session Control without authentication and authorization.
Thanks,
balachandar
One option (hack) would be to use Spring's pre-authentication feature. i.e. you would perform your authentication in your filter and set an attribute on the request object which is the username. The request would then be passed down to Spring and Spring where the concurrent session control feature could be enabled.
But really the best option would be to implement concurrent session control in your filter. You could even "borrow" some code from the spring source.
Short answer: you can't unless you refactor your application to use spring-security fully.
Slightly longer answer: you can "fake" a Java EE container login (pre-authenticated). That would entail specifying a login-filter derived from AbstractPreAuthenticatedProcessingFilter in your spring security http configuration. For instance, you could wrap your request in your filter and add a header values and use the RequestHeaderAuthenticationFilter, or you could write your own that pulls the principal from a request attribute you set on the request in your own login filter. Combine with a PreAuthenticatedAuthenticationProvider.
Slightly longer answer #2: you could use an allow-all kind of setup where you configure spring-security with session concurrency as usual but set the access to permitAll for all URLs (is <intercept-url pattern="/*" access="permitAll" />). You would, however, have to implement essentially what the ConcurrentSessionControlStrategy does in your own login logic, to get the sessions registered into the spring security SessionRegistry. You will most likely run into any number of other snags along the way as well.
Note however that since spring-security works on the basis of a servlet filter (not a servlet like Spring MVC), you will need to refactor your own login as a filter and place it before the spring security filter in the chain, if you are to go with some combination of your own auth logic and spring security.
My advice, if you want to leverage spring-security for concurrent session control, you should really go all the way and build your auth on top of spring-security instead of some custom servlet. Don't fight the framework, use it as intended. Or, don't use it at all.