In December when  was reported. The bug never made it to the release because it was Yadnyawalk Tale from our QE who found the problem in a test build. But anyway I started thinking and looking into how we authenticate in the Service UI.
First some technical background: We need to understand why in Rails (and other libraries) we use two authentication tokens.
- the session cookie,
- the CSRF token.
Why do we do that?
Because the 2 even though being transferred basically the same way have very different properties.
Cookies are vulnerable to CSRF (cross site request forgery). Well that’s an oversimplification. Using cookies as the bearer of identity of the authenticated user (or the authentication user session) makes the authenticated session vulnerable to CSRF. See  for more info on CSRF.
To put it simple: If an attacker’s page manages to fire a request against your ManageIQ in the same browser session where you are logged in into ManageIQ, the request will have the correct cookie.
In this aspect the CSRF token is equivalent to the API tokens that we use in ManageIQ to authenticate to the API.
Checking the CSRF token is mandatory on POST requests to prevent the CSRF that using just cookies would allow.
CSRF tokens are vulnerable to XSS (cross site scripting)  any malicious code that manages to run inside the page can read the token, use the token to do requests or even steal the token (e.g. by firing a request with that token against an attacker controller server).
As long as we use both CSRF token plus the session cookie, we are relatively safe. One deals with the weakness of the other.
BUT if we use just the API and all we use to authenticate against the API is the token, then the attacker can comfortably elevate his abilities. He can simply take the token and open his own session with the server. He does not need the privileged user to keep his browser window opened to carry on his attack. He has the full power of the privileged user.
By using just the API token we are making the situation simple for the attacker. Once a simple programming oversight happens somewhere in future, the attacker would have a simple job.
 provides an example of such oversight.
This applies to the Service UI and also parts of the OPS UI that already use the REST API.
Let me elaborate in a an example:
- A low privileged user will create a snapshot on a VM with the malicious payload in the name of the snapshot using either OPS UI or the Service UI.
- Then a more privileged user displays the timeline in the UI and the payload gets executed in the context of the more privileged user.
- The token is all the attacker needs to fire his requests against the ManageIQ in whatever way he wants. He can create his own SUI session in a browser or use CURL or anything else.
I was searching yesterday for someone pointing out this problem elsewhere and I did find this  nice article that has many parts directly relevant to our situation with the API.
What to do next?
We should use hybrid API authentication:
- Keep the current mechanism for command-line or other clients.
- And implement cookie + token checking for web browser access.
Let’s get this fixed before there’s the next oversight and someone makes advantage of the situation.