WrenSecurity / wrenam

Community fork of OpenAM, an authentication and authorization system originally developed by ForgeRock.
Other
43 stars 27 forks source link

Do not send SSO cookie as query parameter during login #169

Closed pavelhoral closed 5 months ago

pavelhoral commented 8 months ago

XUI sends SSO cookie as a query parameter at the end of the login process to obtain session information:

POST /auth/json/sessions?_action=getSessionInfo&tokenId=AQIC5w....

This has been reported repeatedly by pentesters. It would be nice if the request could be rewritten to request body. If this is not possible, we need a good reason why.


There is a related issue regarding getSessionInfo - #109.

krausvo1 commented 6 months ago

I've been debugging the problem and I've found that the mentioned request is already a POST request. However, the token is actually being sent in a query parameter, which is wrong.

I have tried sending the token in the body of the POST request instead, but it is ignored that way. However, I have found that the token is read from the iPlanetDirectoryPro cookie sent with the request. This cookie should always be included because it is set after the previous POST /authenticate request.

So I think the token can actually be omitted from the request altogether.

pavelhoral commented 6 months ago

I've been debugging the problem and I've found that the mentioned request is already a POST request.

The mentioned GET method was a mistake on my side... I have updated the original report.

I did not realize that the resource is explicitly checking only the URL as the content is application/json and no application/x-www-form-urlencoded (which obviously makes sense for JSON REST API 🙄).

I will have to look at the UI logic if we can simply drop the query parameter. There might be use-cases when the cookie is different from what the front-end want to check.

Or as an alternative we might add support for something like { "tokenId": "..." } as the request body. But that would require some additional research as well.

pavelhoral commented 6 months ago

I have searched through the openam-ui-ria code and it is true that the token is always exclusively read from the cookie value and then passed to other components. The only place where the token can be different is in the token validator that can have stale cookie value.

I understand why we might want to check consistency between the UI state (e.g. Signed in as information) and the currently active session. For example when user reauthenticates in a different window, that might break UI state in the previously active window.

I am fine with simply removing support for the "tokenId" query parameter in the UI. However we should do it in a way that keeps the code clean.