Fix www-authenticate behavior

bmcweb is in a weird position where, on the one hand, we would like to
support Redfish to the specification, while also supporting a secure
webui.  For better or worse, the webui can't currently use non-cookie
auth because of the impacts to things outside of Redfish like
websockets.

This has lead to some odd code in bmcweb that tries to "detect" whether
the browser is present, so we don't accidentally pop up the basic auth
window if a user happens to get logged out on an xhr request.  Basic
auth in a browser actually causes CSRF vulnerabilities, as the browser
caches the credentials, so we don't want to make that auth method
available at all.

Previously, this detection was based on the presence of the user-agent
header, but in the years since this code was originally written, a
majority of implementations have moved to sending a user-agent by
default, which makes this check pretty much useless for its purpose.  To
work around that, this patchset relies on the X-Requested-With header,
to determine if a json payload request was done by xhr.  In theory, all
browsers will set this header when doing xhr requests, so this should
provide a "more correct" solution to this issue.

Background:
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
"X-Requested-With Mainly used to identify Ajax requests (most JavaScript
frameworks send this field with value of XMLHttpRequest)"

Tested:
curl -vvvv --insecure  https://192.168.7.2/redfish/v1/SessionService/Sessions
Now returns a WWW-Authenticate header

Redfish-protocol-validator now passes 7 more tests from the
RESP_HEADERS_WWW_AUTHENTICATE category.

Launched webui-vue and logged in.  Responses in network tab appear to
work, and data populates the page as expected.
Used curl to delete redfish session from store with
DELETE /redfish/v1/SessionService/Sessions/<SessionId>
Then clicked an element on the webui, page forwarded to login page as
expected.

Opened https://localhost:8000/redfish/v1/CertificateService in a
browser, and observed that page forwarded to the login page as it
should.

Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I60345caa41e520c23fe57792bf2e8c16ef144a7a

1 files changed, 13 insertions, 6 deletions

diff --git a/include/forward_unauthorized.hpp b/include/forward_unauthorized.hpp
index 29fef337f0..5b437b1695 100644
--- a/include/forward_unauthorized.hpp
+++ b/include/forward_unauthorized.hpp
@@ -8,7 +8,8 @@ namespace forward_unauthorized
 
 static bool hasWebuiRoute = false;
 
-inline void sendUnauthorized(std::string_view url, std::string_view userAgent,
+inline void sendUnauthorized(std::string_view url,
+                             std::string_view xRequestedWith,
                              std::string_view accept, crow::Response& res)
 {
     // If it's a browser connecting, don't send the HTTP authenticate
@@ -33,12 +34,18 @@ inline void sendUnauthorized(std::string_view url, std::string_view userAgent,
     else
     {
         res.result(boost::beast::http::status::unauthorized);
-        // only send the WWW-authenticate header if this isn't a xhr
-        // from the browser.  Most scripts, tend to not set a user-agent header.
-        // So key off that to know whether or not we need to suggest basic auth
-        if (userAgent.empty())
+
+        // XHR requests from a browser will set the X-Requested-With header when
+        // doing their requests, even though they might not be requesting html.
+        if (!xRequestedWith.empty())
         {
-            res.addHeader("WWW-Authenticate", "Basic");
+            // Only propose basic auth as an option if it's enabled.
+            if (persistent_data::SessionStore::getInstance()
+                    .getAuthMethodsConfig()
+                    .basic)
+            {
+                res.addHeader("WWW-Authenticate", "Basic");
+            }
         }
     }
 }