I am running a tomcat web application on AWS Elastic Beanstalk using load balancing. I have two cookies for each session (1) JSESSIONID (2) XSRF-TOKEN (csrf token*).
I set the JSESSIONID as the application-controlled session stickiness cookie, in Load Balancer Port Configuration. It works perfectly. But I can not set the second session cookie as it is only possible to set ONE sticky cookie in the Load Balancer.
Any idea how I can set multiple cookies for a session in Elastic Beanstalk Load Balancer?
I appreciate your help as Im stuck with this big time!
Migan
*On every request to the backend, backend generates an CSRF-TOKEN and hands it over to the client by setting it as an HTTP response header. The client is required to submit this token on every state changing request in order to prevent cross-site request forgery.
Problem solved!
The reason I could not see my XSRF_TOKEN cookies was that in the test environment I was using http to access my ElasticBeanstalk environment. Once I generate an SSL certificate and accessed my instance using https, my lovely XSRF_TOKEN cookie appeared again!
Related
We are in the process of migrating our on-prem environment to GCP. In our on-prem environment, we have an F5 Application Load Balancer(LB) that routes traffic to app nodes based on JSESSIONID cookie. The way it works is,
If the incoming request to LB doesn't have the JSESSIONID cookie then request is forwarded to one of the available app node in the pool in round robin fashion
If the request does have JSESSIONID, then the request is forwarded to the app node that previously set the cookie
How do I replicate this in GCP internal Load Balancer? If I set session affinity based JSESSIONID cookie, the load balancer creates a cookie before forwarding the request to the app node. This as a result causes the browser to receive two set-cookie for JSESSIONID on the response.
I have an application which uses AWS load balancer. The application shows that the AWSALB Cookie is not marked with the "secure" attribute.Attached image shows the cookies used in the application where AWSALB cookie marked without secure attribute
I have implemented a Django web app on AWS Fargate using Docker behind Application Load balancers.
When I try to log in to the web app I get the following:
Error 403 CSRF verification failed. Request aborted.
Environment:
I am using Application Load Balancer (ALB) as per the best practices of AWS. The ALB also has a TLS certificate to properly handle HTTPS when I run multiple instances of the web app.
I tried to resolve the issue by forcing stickiness of the ALB targets assuming that the Round-Robin lands the requests on different servers. I also reduced the number of docker instances to one (so there is no Round-Robin).
None of this made any difference.
I managed to log in (to get CSRF to work well) was when I connected directly to a docker instance (no Load Balancer) and when I used only HTTP on the Application Load Balancer - disabling redirect to HTTPS. This leads me to believe that the issue is between the HTTPS part of the load balancer and the Django web app.
Disabling HTTPS is not production ready, so I am back at square one. I saw a similar question posted here, without answers:
django posts receive CSRF verification failed after switching to load balancer
After placing a debug on the live system as a temporary measure the underlying issue became clear.
Referer checking failed -
https://test.domain.tld/path/ does not match any
trusted origins.
The solution is through the CSRF_TRUSTED_ORIGINS parameter in Django. A quote from the Django documentation:
CSRF_TRUSTED_ORIGINS
Default: [] (Empty list)
A list of hosts which are trusted origins for unsafe requests (e.g. POST).
For a secure unsafe request, Django’s CSRF protection requires that the request have a Referer header that matches the origin present in the Host header.
This prevents, for example, a POST request from subdomain.example.com from succeeding against api.example.com.
If you need cross-origin unsafe requests over HTTPS, continuing the example, add "subdomain.example.com" to this list.
The setting also supports subdomains, so you could add ".example.com", for example, to allow access from all subdomains of example.com.
A similar discussion and solution can be found in this thread.
CSRF validation does not work on Django using HTTPS
recently we had switched from aws elb to aws alb; but we are facing issue in aws alb; cookie stickiness is not working at all; for each request (event ajax request on the page) generates a new cookie;
if we switch back to aws elb again cookie stickiness working perfectly fine.
AWSALB is a cookie generated by the Application load balancer in the AWS. It works slightly different from AWSELB.
The ASWALB cookie is load balancer generated cookie. Once the load balancer routes your request to one of the servers, it generates a new cookie and sends it to the client in the response header. Though AWSALB works fine when you just send the webapp_session for consecutive request, it is better to integrate the AWSALB cookie along with the webapp_session and send it for each request to the server. This way, the load balancer will identify your target server and direct your request to the same target in each request call to the server. This preserves the stickyness of the server.
However, if you send AWSALB along with the webapp_session in the request header for each request to the sever, even if the target that processed your previous requests gets busy for future requests, the AWSALB generated in each call will help the load balancer identify your credentials and route your request to the new target. I faced similar situation and this helped me solve the problem.
The "STICKY SESSION" topic in this https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#sticky-sessions will perhaps help you have some idea.
For Application LB you have to set up session stickiness in target group not directly in LB like in Classic LB. Session stickiness doesn't work when your browser blocks AWSALBCORS, AWSALB - this seems to be obvious, but Internet Explorer can block these cookies and doesn't show any warning/info in console.
I have an application with multiple EC2 instances behind an ELB. Previously, we enabled sticky session on ELB using AWSELB cookie (AWS generated cookie strategy) and it was working smoothly.
Now, due to some requirement, we have to use application cookie to set up sticky session on ELB.
In the request we are sending this application generated cookie but it is not working.
Can anyone please assist me?