Почему можно сохранять параметр состояния для потока кода авторизации в режиме «Повар» ie? - PullRequest
1 голос
/ 21 февраля 2020

При реализации потока кода авторизации в обычном веб-приложении разрешается сохранять параметр состояния в файлах cookie. См. здесь и [здесь] (https://auth0.com/docs/protocols/oauth2/mitigate-csrf-attacks)

Почему сохранение состояния (иначе говоря, nonce) в поваре ie является приемлемым решением? Например, если мы сделаем это в nodejs, код будет выглядеть примерно так:

  app.use('/login', (_req, res) => {
    state = randomString(32)
    const authorizationEndpointUrl = new URL(`${activeConfig.authorization.domain}/authorize`);
    authorizationEndpointUrl.search = new URLSearchParams({
      audience: activeConfig.authorization.audience,
      response_type: 'code',
      redirect_uri: 'http://localhost:8443/callback',
      client_id: activeConfig.authorization.clientId,
      scope: activeConfig.authorization.scope,
      state,
    }).toString();
    res.cookie('state', state, { httpOnly: true }); // cookie set here
    res.redirect(authorizationEndpointUrl.toString());
  });

  app.use('/callback', req => {
     // check that url state matches req.cookie.state???
  })

Но если мы это сделаем, то, что мешает злоумышленнику просто установить такое же «поддельное» состояние в ответе URL и готовить ie? Что мне здесь не хватает?

Ответы [ 2 ]

1 голос
/ 21 февраля 2020

Повар ie, который вы используете для отслеживания состояния, не должен быть поддельным. Клиент должен как минимум подписать его, чтобы никто, кроме самого клиента, не мог его сгенерировать. На этом этапе злоумышленник сможет воспроизвести такого повара ie только в том случае, если он получит доступ к устройству сразу после того, как был сгенерирован запрос, и до того, как будет возвращен законный ответ, но не сможет подделать несанкционированный ответ авторизации от произвольное устройство.

0 голосов
/ 21 февраля 2020

Согласно ссылкам, которые вы разместили, параметр состояния (nonce) должен быть добавлен в качестве параметра url к запросу. oauth будет проверяться по параметрам URL, а не по параметру cook ie. Таким образом, наличие одноразового номера в поваре ie не должно быть проблемой, оно не ищет одноразовый номер в поваре ie. Атакующий не знает, что такое одноразовый номер, чтобы иметь возможность создать параметры URL-адреса, я думаю, в этом суть. где вы храните одноразовый номер, на самом деле не имеет значения.

Это сбивает с толку, они называют это «состоянием». Это специально для CSRF-атак. Не путать с жетонами oauth. Они уже зашифрованы.

...