2

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!

Choucri
  • 250
  • 1
  • 7
  • Have you tried disabling caching for this page? You can do that by adding .withHeaders(CACHE_CONTROL -> "no-cache, max-age=0, must-revalidate, no-store") to your response. – aleck Dec 20 '18 at 06:28

2 Answers2

0

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

mrxelik
  • 41
  • 2
  • Thanks for your answer! I use Play 2.4, so I tried what you suggested by configuring 'trustedProxies' and redeployed in production. I cannot reproduce the issue but it doesn't mean it's fixed. So I will keep you posted! – Choucri Mar 11 '16 at 10:32
  • The problem is still occurring. Unfortunately, this didn't fix the issue. – Choucri Mar 11 '16 at 11:09
0

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

Community
  • 1
  • 1
Tim
  • 12,318
  • 7
  • 50
  • 72
  • Thanks Timur! The application secret is indeed the same across instances, I use it to encrypt certain fields in database. If it were not the case, I would not be able to share the same db in the cluster. – Choucri Mar 11 '16 at 10:29
  • Oh, OK, sorry, so I totally misunderstood your question then. So, secret is same, but tokens are, still, not accepted by "another" server - that's the issue? Is it systematic or random? – Tim Mar 11 '16 at 11:08
  • It's completely random! – Choucri Mar 11 '16 at 11:10