tree e2b5b8b22f7dfc81b4b10cfb75e13851c9125e26
parent ca89b200406e16a47195e132f2e47a1d2b9879c3
author Paul Fertser <fercerpav@gmail.com> 1718220527 +0000
committer Ed Tanous <ed@tanous.net> 1720717070 +0000

Send cookies to webui-vue from Sessions POST

Using Redfish-standard X-Auth-Token authentication is less secure
(against injected JS code) compared to an HttpOnly (not available to the
JS VM) SESSION cookie. Currently webui-vue authenticates connections to
WebSocket URIs not only by a JS-accessible token (passed as subprotocol
when upgrading to WS) but also via a SESSION cookie (even though it is
not subject to CORS policy).

To allow WebSocket-based functionality (IP KVM, SOL, VM) after creating
a Session object send a set of cookies instead of the X-Auth-Token
header if the request was made by webui-vue (detected by presence of
"X-Requested-With" header).

Factor out cookie setting and clearing functions and use explicit Path=/
attribute as the cookies are valid for the whole server, not just the
path of the endpoint they were created by.

Not specifying Path was functional for /login endpoint because
https://www.rfc-editor.org/rfc/rfc6265#section-5.3 point 7 for this case
says "set the cookie's path to the default-path of the request-uri" and
https://www.rfc-editor.org/rfc/rfc6265#section-5.1.4 tells how to
compute the default path. Basically, it was a "happy coincidence" that
/login defaults to / for the Path, if it was /openbmc/login then the
cookies would have been set to Path=/openbmc and not work at all for
/redfish/v1 endpoints.

Tested: Redfish-Service-Validator doesn't see a difference. Runtime
testing logging in via Sessions endpoint, getting data, using websockets
and logging out against webui-vue with a corresponding change while
carefully observing Request and Response headers. Creating a session
with curl without the special header shows just X-Auth-Token and no
cookies in the response.

Change-Id: I0b1774e586671874bb79f115e9cddf194f9ea653
Signed-off-by: Paul Fertser <fercerpav@gmail.com>