UI authentication problems (Cookie missing or bad)

Building from Source and Advanced Topics
1

I have a Community Edition built from source. I can login into UI, but occasionally it logs me out. And sometimes I can login again right after, sometimes I can’t.
The response is:
Authentication required: handler_send_reauthentication:479 (GSA 22.07.0)
Cookie missing or bad. Please login again.

What I have tried:

  1. use different browsers (chrome, firefox), incognito and usual mode
  2. clear cookies
  3. connect by nginx proxy, connect without proxy by IP and port (192.168.111.111:9392)
  4. set logs level of gsad to maximum (128)
  5. change gsad systemd unit file (/etc/systemd/system/gsad.service), add --timeout=1440 to the ExecStart line

Still have this problem.
The only suspicion I have is VPN (I can’t connect to greenbone server without VPN)
I saw people discuss a similar problem and blame “too large MTU”

Please help me. If too large MTU can be relevant in my case please explain why and how to solve it.

2

Hi,

this is caused by using nginx as a proxy. See Stuck on Login loop on the Login page - #3 by bricks

1 Like
3

Unfortunately not. I’m connecting by IP:port bypassing nginx and have the same problem.

4

This means that the session cookie is not available or has a mismatch. Check the network console in your browser if it is send to gsad. The cookie is named GSAD_SID.

1 Like
5

In other words problem may be in my browser? I have tried to clear cookies , reload a page and login again. Nothing.

I’m checking developing tools/network in my browser.
There are normal (200) request, Set-Cookie: GSAD_SID=###########; expires=Wed, 07 Feb 2024 ##:##:## GMT; max-age=###; path=/; HTTPonly; SameSite=strict
and a bad one (401), Set-Cookie:
GSAD_SID=0; expires=Wed, 07 Feb 2024 ##:##:## GMT; path=/; HTTPonly; SameSite=strict

6

It’s somewhere in your http request/response path which includes the browser of course.

That’s the response from gsad. You need to look at the next request to gsad.

That’s the response of gsad if the session id doesn’t match. You need to look at the request for this reponse.

See https://github.com/greenbone/gsa/issues/2973#issuecomment-857582302

2 Likes
7

I’ve check connection without VPN and problem was solved!
So, any ideas why our VPN (we use cloudflare zero trust) may cause cookies issue?

8

There are many reasons. Judging simply from it’s name, Cloudflare Zero Trust likely applies various security policies that can include inspecting and filtering HTTP headers. Also, VPNs and load balancers can affect how traffic is routed, potentially causing session persistence issues if the session association is lost. You need to verify the settings with CloudFlare Zero Trust. :slight_smile:

1 Like
9

And if in doubt: Contacting the support of this provider would be another option.

1 Like
10

Have taken a into this as we’ve been seeing the same issue, in our case we are using -

  • Cloudflare Zero Trust (using 2x for failover/load balance)
  • Traefik (using 2x for failover/load balance)
  • gsad on Docker

The issue for us was that we could sometimes login, get a few pages and then we’d get logged out in a way that is consistent with the various descriptions -

The description on the Azure ticket (73) describes a solution that involves adding the X-Real-IP header but does not explain why this works.

A hint for us came when we noticed different source (internal) ip-addresses logged when users authenticated - it appears the gsad session is bound with the observed client IP address and when you have a load-balancer in front of gsad the internal client-address that connects can change which in turn then invalidates the auth session token.

Have taken a look through the gsad code but do not know the code well enough to be able to pinpoint and confirm this - but empirically setting the X-Real-IP address in our setup does indeed resolve the issue.

Several things we tried -

  • We tried setting the X-Real-IP using a Cloudflare transform rule - does not work out because CF treat this header as protected
  • We tried using Traefik header manipulation rules - does not work out because Traefik does not do dynamic rewrites

We ended up using a Traefik plugin to rewrite the X-Real-IP header using the CF-Connecting-IP header as the input value - this is similar to writing an Nginx rule or applying an upstream load-balancer rule that assigns a X-Real-IP that does not jump around.

Happy days.