Session elevation duration is unbounded, and large values silently overflow to a past timestamp

[lbellows]

ElevateRequest.DurationSeconds (model/elevate.go) is only validated as non-zero, and both elevation paths multiply it straight into a time.Duration:

• api/client.go:128 — POST /client/:id/elevate
• api/oidc.go:186 — the OIDC elevation callback

Two consequences, both reproduced on v3.1.1:

1. Elevation can be made effectively permanent. One call turns the hour-long elevation from login into a century:

$ curl -s -o /dev/null -w '%{http_code}\n' -X POST localhost:8791/client/1/elevate \
    -H "X-Gotify-Key: $TOK" -H 'Content-Type: application/json' -d '{"durationSeconds":3153600000}'
204
$ curl -s localhost:8791/current/user -H "X-Gotify-Key: $TOK"
{"id":1,...,"elevatedUntil":"2126-08-23T23:11:49.409030064-04:00"}

The caller must already be elevated, so this is not a privilege jump on its own — but it means a single moment of elevation (or a token stolen inside the hour after login) yields a session that never needs basic auth again, which is the opposite of what elevation is for. The UI has no way to show or revoke "elevated until 2126" other than deleting the client.

2. Large values silently overflow instead of erroring. time.Duration(DurationSeconds) * time.Second wraps for anything past ~292 years:

$ curl -s -o /dev/null -w '%{http_code}\n' -X POST localhost:8791/client/1/elevate \
    -H "X-Gotify-Key: $TOK" -H 'Content-Type: application/json' -d '{"durationSeconds":9223372036854775807}'
204
$ curl -s localhost:8791/current/user -H "X-Gotify-Key: $TOK"
{"id":1,...}        # elevatedUntil now in the past — 204, but elevation silently dropped

Suggestion: clamp durationSeconds with a binding:"min=1,max=…" tag (model.DefaultElevationDuration, or some multiple of it, seems like the natural ceiling) so both the century case and the overflow case become a 400.

[jmattheis]

When the attacker has an elevated session, they can just change the password, create new admin users. Which is much more intrusive than having an unlimited elevated session.

If there was a limit to the duration, the attacker still can extend the elevation period before it expires, so I don't think adding it makes much difference.

We can probably fix the overflow with having a really high limit, but I see this as low priority.