Possible race condition when processing login_hint or resource -parameters in authorization endpoint
Basics
Logistics
Basics
Logistics
Description
By mistake, two lookup functions for authorization/authentication request parameters are missing scope in the bean declaration, even though they are not thread-safe. This means that their scope is singleton, and not a prototype that we should use in non-thread-safe cases.
The beans are DefaultRequestLoginHintLookupFunction and AuthenticationRequestAudienceLookupStrategy, located in authorize-beans.xml for the authorize flow. They are used for reading the login_hint and resource -parameter values from the request. The value may possibly exist either in the request parameters or in the request object.
The abstract lookup function exploited by the lookup functions mentioned above first reads the request object from the context state and stores it to a class variable. This same class variable is later exploited for accessing the request object state. As the bean declarations are missing the scope definition, the values of the class variable could be set to point to some other value by another thread.
We consider this as "low" severity, and neither is likely to manifest without significant load on the server.
By mistake, two lookup functions for authorization/authentication request parameters are missing scope in the bean declaration, even though they are not thread-safe. This means that their scope is singleton, and not a prototype that we should use in non-thread-safe cases.
The beans are DefaultRequestLoginHintLookupFunction and AuthenticationRequestAudienceLookupStrategy, located in authorize-beans.xml for the authorize flow. They are used for reading the login_hint and resource -parameter values from the request. The value may possibly exist either in the request parameters or in the request object.
The abstract lookup function exploited by the lookup functions mentioned above first reads the request object from the context state and stores it to a class variable. This same class variable is later exploited for accessing the request object state. As the bean declarations are missing the scope definition, the values of the class variable could be set to point to some other value by another thread.
We consider this as "low" severity, and neither is likely to manifest without significant load on the server.