PrOfESSOS is our open source implementation for fully automated Evaluation-as-a-Service for SSO. PrOfESSOS introduces a generic approach to improve the security of OpenID Connect implementations by systematically detecting vulnerabilities.
I am testing a client and it is passing CSRF 2, where you use the state from another session.
However, the test log shows that the client is not rejecting the authentication response but is rejecting the token response. Checking the source code of the client reveals that it is saving the state, but in a global table and not tied to the session. Thus accepting the state value when it is returned by another session. It then goes ahead and request the token, but will reject it because it has a nonce that does not match the one used for the given state (similar to Replay Attack 5).
The test description says that an attack is successful if "the next protocol steps are executed". PrOfESSOS will not check for this, but will just monitor if the user has been logged in or not.
If a client does not save or check the state then it most likely would expect the latest nonce. So #2 (now closed) would fix the issue with the client I am validating, but would introduce a false negative for other clients that are missing state checks entirely.
What should the solution be? Check if the next protocol steps are executed? Add a new CSRF test that will save both the state and the nonce?
I am testing a client and it is passing CSRF 2, where you use the state from another session.
However, the test log shows that the client is not rejecting the authentication response but is rejecting the token response. Checking the source code of the client reveals that it is saving the state, but in a global table and not tied to the session. Thus accepting the state value when it is returned by another session. It then goes ahead and request the token, but will reject it because it has a nonce that does not match the one used for the given state (similar to Replay Attack 5).
The test description says that an attack is successful if "the next protocol steps are executed". PrOfESSOS will not check for this, but will just monitor if the user has been logged in or not.
If a client does not save or check the state then it most likely would expect the latest nonce. So #2 (now closed) would fix the issue with the client I am validating, but would introduce a false negative for other clients that are missing state checks entirely.
What should the solution be? Check if the next protocol steps are executed? Add a new CSRF test that will save both the state and the nonce?