Possibly suspicious activity randomly

Hi there,

I experience the following warning everye once in a while:
axum_session::sec::signed: possibly suspicious activity: Verification failed for Cookie. err=value did not verify

The result is that the session gets discarded and the user has to login again. I sometimes see this locally while developing, but more frequent on the deployed application on a server.

Any idea what might cause this behavior?

Notes:
I use the following dependencies

sqlx = { version = "0.7", features = [
  "runtime-tokio",
  "tls-native-tls",
  "any",
  "postgres",
  "chrono",
] }
axum_session = { version = "0.12.4", default-features = false, features = [
  "postgres-native",
  "key-store",
] }

this occurs if the verification of the cookies Signature could not be verified.

AxumSession/src/sec/signed.rs

Line 143 in da387c2

"possibly suspicious activity: Verification failed for Cookie."

Possible causes

Servers Signing Key got changed
config.with_ip_and_user_agent = true and their IP or user agents Changed. This is Defaulted to true.
they are tampering with or creating the cookie.

Make sure your adding

axum::serve(
        listener,
        // We set it with connection info so we can get the ip address of the user from the socket.
        // Otherwise if we try to get this and this is not set the ip address will be empty.
        // This is needed for the ip and user agent stuff to get the correct information.
        app.into_make_service_with_connect_info::<SocketAddr>(),
    )
    .await
    .unwrap();

As shown in the readme's https://github.com/AscendingCreations/AxumSession/blob/da387c2b4458c944d683235e9df4028290cd3e16/README.md#enable-cookie-and-header-uuid-signing-and-database-key-encryption-for-session-data

For the IP address and user agent we are hashing them as follows
https://github.com/AscendingCreations/AxumSession/blob/main/src/headers.rs#L367

So any changes to those categories will result in a signed cookie being unverifiable.

@genusistimelord thanks for your quick response. Ok that explains why I observe the dropping session on the installed PWA. I have not directly looked into it, but it feels like that the cookie somehow gets dropped after reopening the PWA app from iOS homescreen.

I was wondering why this also happens locally, since my browser and ip did not change, but locally it does not happen that often.

it you happen to use a random Encryption key on start up each time you restart the Server the cookies would not be Valid.
Of you have a Setting set to invalidate a cookie much sooner or you were like me who forgot to add the app.into_make_service_with_connect_info::() this can occur too.

Other than that if its caused by something else please let me know so it can be fixed right away.

I would try disabling the IP/UserAgent checks and test it without first.

@c0nscience were you able to get the issue resolved? Or did you spot a bug?

hi @genusistimelord sorry didn't had time yet to look again into it. Tomorrow I have more time and will have another look. Thanks for checking in again. I'll let you know.

@genusistimelord I keep getting the warning. It feels random. Sometimes its on request A another time it is request B. Since I am still very new to rust I don't have the skill to really dig into it. Another issue I have is that it seems to be depended on my 'production' server.

Some notes: True I have the feature enabled you described above, which sounded like a good option to have an extra layer of security. The thing is: It is the same encryption key, same device, same IP and sometimes I can use it minutes long and sometimes it fails to verify the signature almost every request.

I think in the end I will disable the feature for now to have a better experience not to log in every time.

Do you have any suggestions what I could do to debug further?
I've enabled debug logging in trace and added the trace layer to my axum app. Is there something else I could do?

well I wanted you to try it disabled first as its still a new change to security I don't know fully how the Extra IP address types for forwarders and such works on the local machine. so those could be whats invalidating it. So a good test is first disable that feature and give it a try to see if you still get the warning or not. If so we will need to look into why more closely.

I am working on adding some more information to the warning message so you will be able to see the ip and such that it gave for debugging purposes.

Also making it so the different types added can be controlled by the config if they will add or not.

If you get a chance could you give the config branch a try? It will invalidate current session's though since i reworked the ip and username string collector.

Thanks @genusistimelord once you have it implemented I'll have another look.

So far with the option disabled everything works fine. I have misunderstood you. Sorry about that.

I appreciate your support.

Ill be pushing this new update soonish but its a breaking change so it needs to be incremented higher.

ok update to allow customizing the ip types that are used for signing the cookie are up in v 0.13.0

Defaults are set to socket ip and user agent. the rest you will need to enable and test if it fits your needs or not. that should however fix the issue on some devices that are really picky.