Kibana: CSP breaks OIDC authentication flow

Created on 3 Sep 2019 · 5Comments · Source: elastic/kibana

As noted by @azasypkin in https://github.com/elastic/kibana/pull/43553#discussion_r319444103, the CSP change from using nonce to 'self' breaks the OIDC authentication flow which requires an inline script. I have not yet verified this manually.

I'm opening this issue to discuss the blocker status of this for the 7.4 release as well as how we should go about fixing this. It seems to me this will be a blocker.

For 7.4, I propose that we revert #43553 from the 7.4 branch while working on a solution in master and 7.x.

In terms of the solution, it's not clear to me how a nonce is strictly safer than simply allowing inline scripts since any malicious script can read the nonce off the page. That said, we may gain some protection from any malicious dependency that is just targeting any page that does not use a nonce policy.

CSP SecuritAuthentication Security blocker bug v7.4.0

Source

joshdover

All 5 comments

Pinging @elastic/kibana-security

elasticmachine on 3 Sep 2019

For 7.4, I propose that we revert #43553 from the 7.4 branch while working on a solution in master and 7.x.

Another potential solution would be a dedicated .js endpoint that would let us rely on self (mentioned by Alex B in Slack as well). We didn't do that initially because it makes code little bit more complex and we had nonce anyway. But if it's the the only kind of use cases we have in mind where we may need inline scripts we can just go this way. We can also have one endpoint (kind of silly to have same endpoint that returns two different types of content, but it's internal one :man_shrugging: )

server.route({
  method: 'GET',
  path: '/api/security/v1/oidc/implicit',
  config: {
    auth: false,
    validate: {
      query: Joi.object().keys({ script: Joi.boolean().default(false) }),
    }
  },
  async handler(request, h) {
    const legacyConfig = server.config();
    const basePath = legacyConfig.get('server.basePath');

    let response;
    if (request.query.script) {
      response = h.response(`
        window.location.replace(
          '${basePath}/api/security/v1/oidc?authenticationResponseURI=' + encodeURIComponent(window.location.href)
        );
      `).type('text/javascript');
    } else {
      response = h.response(`
        <!DOCTYPE html>
        <title>Kibana OpenID Connect Login</title>
        <script src="${basePath}/api/security/v1/oidc/implicit?script=true"></script>
      `).type('text/html');
    }

    return response
      .header('cache-control', 'private, no-cache, no-store')
      .header('content-security-policy', createCSPRuleString(legacyConfig.get('csp.rules')));
  }
});

azasypkin on 4 Sep 2019

👍1

For 7.4, I propose that we revert #43553 from the 7.4 branch while working on a solution in master and 7.x.

I'm not opposed to reverting the change; however, the solution that Aleh seems simple enough as well. At this point, I'm leaning toward the solution which Aleh mentions.

The proper solution, which was discussed in the initial OIDC implicit flow PR, would be allowing routes to render applications which don't have the "automatic Kibana URL fragment modifications" to support the traditional routing. I don't want to block 7.5 on us addressing this, because using self allows us to do dynamic imports which is critical to the NP.

kobelb on 4 Sep 2019

👍1

@azasypkin instead of using one route, how would you feel about using two dedicated routes /api/security/v1/oidc/implicit and /api/security/v1/oidc/implicit.js?

kobelb on 4 Sep 2019

@azasypkin instead of using one route, how would you feel about using two dedicated routes /api/security/v1/oidc/implicit and /api/security/v1/oidc/implicit.js?

Sounds good to me, I'll prepare PR for that.

azasypkin on 4 Sep 2019

Was this page helpful?

0 / 5 - 0 ratings