I use Play in a cluster behind an AWS load balancer. To prevent CSRF attacks I added #CSRF.formFields to all form submits. But I get 403 errors randomly, and I guess it's because the token issued by server
A wouldn't be accepted by server B.
Have you encountered this problem before? Did you need to store the session in a distributed cache or database? Are there features in Play that I'm not aware of that can solve this problem?
By the way, a similar question was asked here with no answers.
Thanks for your help!
try put this in your application.conf
trustxforwarded=true
or check your loadbalance configuration, maybe here You will find some usefull info
https://www.playframework.com/documentation/2.3.x/HTTPServer
As far as I understand, "application secret" is an attribute of an entire application, not a single instance/server.
Therefore it should be the same on all servers in a cluster. This will naturally "fix" the CSRF token validation.
As another example - sessions: by default session data is stored on a client side in a session cookie, and session cookie is signed using the application secret as a salt - if it would be different on different servers of same application - this would defeat the entire idea of the client-side session because session cookie would be only valid on one server.
P.S. Similar thread about Django's secret key: Django SECRET_KEY in a distributed setup
Related
I'm looking for some clarity regarding security concerns with just JWT in our current project.
basically it is working right now like this:
User authenticates with username + password at an authentication Service
frontend gets JWT
frontend can use this JWT in the communication with the backend.
but that seems unsecure for many reasons, so we discussed this so far and had a few ideas to make it more secure:
additionally encrypt the JWT, basically make an nested JWT (JWE) and work with a blacklist on logout... but here the question remains why work with an JWT and not a stateful authentication like Shared Sessions and a Redis service
Implementing an Api-Gateway so that the frontend or User gets a Session cookie and the gateway works with JWT for backend and auth. unfortunatly i've found no implementation like this whatsoever
We just want to be kinda secure in Login/Logout AND be scaleable in the the future so that there might be X other backends.
apologies for any errors, english is not my first language and i'm happy to answer any questions regarding this.
take care.
You are right that keeping tokens on the front end has some security issues. The current best practice is to try to keep tokens out of the browser altogether. At Curity we have described one possible solution as the Token Handler pattern. It adds a bit more complexity to your system but enables you to use secure sessions on the front instead of any tokens. We have provided a few implementations of the components needed by the Token Handler, you can have a look at how to run our complete example here: https://curity.io/resources/learn/token-handler-spa-example/
As to your first idea, if you want to implement blacklisting tokens, then you're in fact implementing sessions, and you're better off with cookies and plain old HTTP sessions. JWEs protect the contents of your token but an attacker can still steal such a token and use it to call your APIs.
I would like to enable extended (virtually forever) authentication for my web/mobile application, similar to how many popular sites operate (e.g. Facebook), virtually never needing to re-log in unless your credentials are changed from another terminal or the session is deliberately ended server-side. I am currently evaluating Apache Shiro. I have not yet been able to find a way to support dropping a cookie with some kind of access token that would be submitted every time the site is revisited so that the user does not need to log in again. Is there a way to do it?
Yes,
You can configure the session cookie's MaxAge:
https://shiro.apache.org/web.html#session_cookie
Using the bean properties of the cookie: https://shiro.apache.org/static/current/apidocs/org/apache/shiro/web/servlet/SimpleCookie.html
I'm not sure I'm following the last bit about access tokens and cookies though.
Typically, using a session cookie is default functionality for web apps running on most Java Servlet containers (this differs once you get into REST API frameworks)
I am looking into using microservice for my application. However the application involves authentication. E.g. there is a service for user to upload their images if they are authenticated. There is also a service for them to write reviews if they are authenticated.
How should i design the microservice to ensure that the user just need to authenticate once to access different services. Should i have a API gateway layer that does the authentication and make this API gateway talk to the different services?
You can do authentication at the gateway layer, if authentication is all you need. If you are interested in authorization, you may have to pass the tokens forward for application to consider it. Also you can do that, if you have trust on other services behind the gateways. That is service 1 is free to call service 2 without authentication.
Also you loose bit of information about the principal, you can however write it back on the request in the gateway while forwarding.
Also another point to consider is JWT, they are lightweight and more importantly could be validated without calling auth server explicitly and it saves you some time specially in microservices. So even if you have to do auth at every service layer you are doing it at minimal cost, some nanoseconds. You can explore that as well.
However final call is based on how strong your security needs are compared to rest. based on that you can take a call. Auth stripping at api gateway saves you code duplication but is less secure as other services can do as they wish.
Same goes for token, you can authenticate without explicit call to auth server but then tokens are valid for some min time and bearer is free to do as they wish once they got the tokens, you cannon invalidate it.
While Anunay's answer is one the most famous solutions, there is another solution I would like to point out. You could use some distributed session management systems to persist sessions on RAM or DISK. As an example, we have authentication module that creates a token and persists it in Redis. While Redis itself can be distributed and it can persist less used data on disk, then it will be a good choice for all microservices to check client tokens with redis.
With this method, there is nothing to do with API gateway. The gateway just passes tokens to microservices. So even in case you are thinking about different authenitcation methods on different services, it will be a good solution. (Although I cant think of a reason for that need right now but I have heard of it)
Inside a session, you can store user Roles and Permissions. That's how you can strict users access to some API's. And for your private API's, you could generate a token with role ADMIN. Then each microservice can call other one with that token so your API's will be safe.
Also you could rapidly invalidate any sessions and store anything you want in those sessions. In our system, spring framework generates a X-AUTH-TOKEN that can be set in headers. The token is pointing to a session key in redis. This works with Cookies too. (and if I'm not wrong, you could even use this method with oAuth and JWT)
In a clean architecture you can create a security module that uses this validation method over API's and add it to every microservice that you want to protect.
There are other options when it comes to session persisting too. Database, LDAP, Redis, Hazelcast ... the choice depends on your need.
I have a relatively successful app in the app store that allows people to view metrics on their iDevice using a JSON file hosted on the their server. The app has a simple settings screen in which you simply type the URL of your JSON file and the app takes care of visualising the data in the file. I use AFNetworking for this.
For example the URL might be: http://www.mylargecompany.com/factorykpi.json
Customers are now coming back to me and asking for the ability to connect to their servers more securely. Problem is there is a myriad of ways you can secure your server.
I need some advice. What kind of standard security features would I need to build into my app. I am confused by OAuth, HTTPS, etc.
I believe OAuth would mean the customers server would have to use it? Can you make a generic OAuth login screen in an app or do you need to know which web server you are connecting to authenticate.
Any advice on even the most basic of security measure would be very welcome!
Regards,
MonkeyBusiness
Security is really a very broad topic. There is no short answer. In any case, both web service and client app need to implement security mechanisms. I would recommend, you provide both the web service and client app.
You likely need some user login with a password, "server verifies user identity" and "client verifies server identity" using certificates. Then you utilize HTTPS which ensures to transport confident data in a secure way. The web service should be implemented with one of the well known web application frameworks since security is a scary business, and tricky. Implementing everything yourself, might end in a suboptimal insecure application.
You should now read more about the complex topic and come back when you have specific questions.
... most basic would be to use https, which would secure the transaction, but anybody accessing the same link would be able to access the same data. Thus you will need some kind of authentication, starting with a simple secret key passed as POST request, username and password and/or via certificates.
I'd like to get an OAuth access token client-side (iPhone) and send the access token back to my server to make gdata requests on behalf of the user. Basically my question is, is this safe? Couldn't someone sniff the connection and pull the access token out and use it maliciously?
Google allows you to authenticate 'unregistered' applications by using 'anonymous' as the consumer key and secret in HMAC-SHA1 signature mode, which is what I'm doing. I'm then passing the acquired access token server-side to do my data manipulation. It works which is great, but I'm having security concerns about the solution.
Thanks for your comments!
Is your server secure? Are you issuing requests using https? Also, is registering to get an actual consumer key/secret out of the question? An access token is only good for the consumer key/secret that generated it. If you were to register, that would add another level of security (being that your consumer key/secret would only be known to you) but I would always suggest that communication from your app to your server should be done over a secure connection.