Обеспечьте безопасность подмножества пользовательских данных на нескольких страницах, используя JavaScript - PullRequest
0 голосов
/ 08 июня 2019

Я не уверен, что это вообще возможно, но есть ли способ защитить информацию пользователя на нескольких страницах, используя только javascript?

У меня есть предопределенный набор деталей, восстановленный из трех отдельных запросов API, при первоначальном вызове учетные данные пользователя отправляются в login_api через POST и возвращает небольшой набор данных (токен OAuth2, имя рождения пользователя и т. Д.), Последующие вызовы При успешном завершении для двух линий продуктов через вызовы GET эти запросы возвращают список продуктов для каждой линии, который воспринимается как то, что этот пользователь имеет на просмотр.

У меня не было большого опыта в настройке безопасной аутентификации пользователей, и я запомнил данные на многостраничном веб-сайте, поэтому я хочу убедиться, что выбрал правильный подход.

С помощью функций ниже я могу создавать _приватные переменные внутри функций, которые используют эти данные.

Все запомненные данные применяются в XHR-ответах к области хранения cookie, они никогда не покидают область действия функции запроса.

С этого момента все данные извлекаются с помощью файлов cookie, используемых в рамках отдельной функции, никогда не покидая область действия функции, в которой они используются. Каждый раз, когда требуются данные, они извлекаются из файлов cookie. Я не уверен, насколько безопасны cookie-файлы. Я обсуждал вопрос об очистке cookie-файлов при каждом восстановлении данных и повторном применении обновленных значений после завершения функции, но подумал, что это излишне.

Если какая-либо часть соответствующих данных cookie отсутствует при загрузке страницы, они перенаправляются на страницу входа и все соответствующие данные cookie, если они есть, удаляются.

Есть ли способ улучшить сохранение токена OAuth2 и нескольких пользовательских данных на нескольких страницах без утечки пользовательской информации только с помощью javascript?

Примечание Он находится на довольно старом внутреннем веб-сайте, и, учитывая то, что для команды, которую мы используем ES5 и ниже, он знаком с внутренним использованием.

var config = Object.create(null);
config.expire_item = 30; // minutes

function dataref() {

  // setup objects to store details in
  var output;
  output = Object.create(null);
  output.access = Object.create(null);
  output.licensed = Object.create(null);
  output.token = "_token"; 

  // apply predefined names as object values
  // cookies in this namespace holds user name
  output.fname = "_fname"; 
  // cookies in this namespace store true/false flags
  output.has_access.ces = "ces_license";
  output.has_access.ezg = "ezg_license";
  // cookies in this namespace hold pipe & comma delimited product lists
  output.licensed_for.ces = 'ces_products'; 
  output.licensed_for.ezg = 'ezg_products';
  // ...etc.

  return function () {
    // return object with predefined names for cookies
    return output;
  }();

}

function apply_userdata(fn) {
  // get predefined cookie names
  var _data = dataref();
  return function () {
    // apply function to all namespaces
    fn(_data.token);
    fn(_data.fname);
    fn(_data.access.ces);
    fn(_data.access.ezg);
    fn(_data.licensed.ces);
    fn(_data.licensed.ezg);
  }();
}

function resetCookieExpire(name) {
  // updates cookie expiration period.
  return setCookie(name, getCookie(name), option.expire_item);
}

function getUserSensativeData(name) {
  // retrieve cookie value
  return getCookie(name)
}

function deleteUserSensativeData(name) {
  // remove cookie name/value
  return deleteCookie(name);
}

1 Ответ

1 голос
/ 08 июня 2019

Мне следует предвосхитить это словами «Я тоже не эксперт по аутентификации», однако в прошлом я работал с несколькими различными типами аутентификации пользователей в нескольких проектах. Есть немного недостающей информации, которая, как кажется, подразумевается тем, что вы говорите, но похоже, что вы используете неявный поток oauth2 или поток кода авторизации oauth2. в любом случае, чтобы сохранить постоянную загрузку отдельных страниц, вам придется использовать файлы cookie или локальное хранилище в том виде, в котором вы находитесь в данный момент, если только это не одностраничное приложение, в этом случае это звучит так, как будто это не так. Исходя из того, как вы описали этот проект, звучит так, как будто вы пытаетесь утвердить его, как говорится, если вы действительно плохо относитесь к сохранению этих учетных данных на стороне клиента, вы можете переключиться на поток стилей OIDC, который использует secure = true; httpOnly = истинные куки, которые автоматически отправляются с каждым запросом. Похоже, это не вариант для вас. Oauth2 считается безопасным, и хранение учетных данных на стороне клиента для повторного использования не нарушает никаких правил. Хранение учетных данных на стороне клиента может считаться уязвимым из-за XSS или CSRF атак

Наличие политики безопасности контента также имеет большое значение.

Есть дополнительные меры предосторожности, которые вы можете предпринять, такие как короткое время истечения (обычно 1 час) или даже возможность ручного истечения срока действия access_tokens в чрезвычайной ситуации. Надеюсь, это поможет.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...