Hello,
This issue was found by a security agent and review by myself.
The vulnerability is in the Remember-Me (gitea_incredible) token validation logic, specifically when handling a compromised token (hash mismatch).
The vulnerable function is this one:
|
func CheckAuthToken(ctx context.Context, value string) (*auth_model.AuthToken, error) { |
|
if len(value) == 0 { |
|
return nil, nil //nolint:nilnil // the auth method is not applicable |
|
} |
|
|
|
parts := strings.SplitN(value, ":", 2) |
|
if len(parts) != 2 { |
|
return nil, ErrAuthTokenInvalidFormat |
|
} |
|
|
|
t, err := auth_model.GetAuthTokenByID(ctx, parts[0]) |
|
if err != nil { |
|
if errors.Is(err, util.ErrNotExist) { |
|
return nil, ErrAuthTokenExpired |
|
} |
|
return nil, err |
|
} |
|
|
|
if t.ExpiresUnix < timeutil.TimeStampNow() { |
|
return nil, ErrAuthTokenExpired |
|
} |
|
|
|
hashedToken := sha256.Sum256([]byte(parts[1])) |
|
|
|
if subtle.ConstantTimeCompare([]byte(t.TokenHash), []byte(hex.EncodeToString(hashedToken[:]))) == 0 { |
|
// If an attacker steals a token and uses the token to create a new session the hash gets updated. |
|
// When the victim uses the old token the hashes don't match anymore and the victim should be notified about the compromised token. |
|
return nil, ErrAuthTokenInvalidHash |
|
} |
|
|
|
return t, nil |
|
} |
Affected Endpoint
POST /user/login (and any endpoint triggering autoSignIn via the Remember-Me cookie).
Description
Gitea implements Remember-Me cookies using a split token design (ID:Hash), citing the Paragonie secure remember-me guide. When a token is used, its Hash is rotated, but the ID remains the same.
If an attacker steals a user's Remember-Me token and uses it to authenticate, the attacker is issued a new rotated token (same ID, new Hash). When the legitimate user later attempts to use their original token, Gitea correctly detects a hash mismatch for the given ID.
According to the referenced Paragonie specification, this indicates a compromised token, and ALL active remember-me sessions for that user MUST be invalidated. However, Gitea's CheckAuthToken function simply returns ErrAuthTokenInvalidHash. The calling code (autoSignIn) catches this error and deletes the victim's local cookie via ctx.DeleteSiteCookie, but fails to delete the compromised token from the database.
As a result, the attacker's active session is never invalidated, and the attacker maintains persistent, indefinite access to the victim's account, entirely defeating the purpose of the split-token security design.
Hello,
This issue was found by a security agent and review by myself.
The vulnerability is in the Remember-Me (gitea_incredible) token validation logic, specifically when handling a compromised token (hash mismatch).
The vulnerable function is this one:
gitea/services/auth/auth_token.go
Lines 33 to 64 in 689ace1
Affected Endpoint
POST
/user/login(and any endpoint triggeringautoSignInvia the Remember-Me cookie).Description
Gitea implements Remember-Me cookies using a split token design (ID:Hash), citing the Paragonie secure remember-me guide. When a token is used, its Hash is rotated, but the ID remains the same.
If an attacker steals a user's Remember-Me token and uses it to authenticate, the attacker is issued a new rotated token (same ID, new Hash). When the legitimate user later attempts to use their original token, Gitea correctly detects a hash mismatch for the given ID.
According to the referenced Paragonie specification, this indicates a compromised token, and ALL active remember-me sessions for that user MUST be invalidated. However, Gitea's
CheckAuthTokenfunction simply returnsErrAuthTokenInvalidHash. The calling code (autoSignIn) catches this error and deletes the victim's local cookie viactx.DeleteSiteCookie, but fails to delete the compromised token from the database.As a result, the attacker's active session is never invalidated, and the attacker maintains persistent, indefinite access to the victim's account, entirely defeating the purpose of the split-token security design.