Обработка токенов Firebase ID на стороне клиента с помощью ванильного JavaScript

Ответ 1

Почему файлы cookie не защищены?

1. Данные cookie можно легко смягчить, если разработчик достаточно глуп, чтобы сохранить зарегистрированную роль пользователя в cookie, пользователь может легко изменить свои данные cookie, document.cookie = "role=admin". (Вуаля!)
2. Данные cookie могут быть легко взломаны хакером с помощью атаки XSS, и он может войти в вашу учетную запись.
3. Данные cookie могут быть легко собраны в вашем браузере, и ваш сосед по комнате может украсть ваш файл cookie и войти в систему, как вы со своего компьютера.
4. Любой, кто контролирует ваш сетевой трафик, может собирать ваш файл cookie, если вы не используете SSL.

Вам нужно беспокоиться?

1. Мы не храним ничего глупого в cookie, который пользователь может изменить, чтобы получить какой-либо несанкционированный доступ.
2. Если хакер может собирать данные cookie с помощью атаки XSS, он также может выбрать токен Auth, если мы не используем одностраничное приложение (потому что мы будем хранить токен где-нибудь, например localstorage).
3. Ваш сосед по комнате может также забрать ваши локальные данные.
4. Любой, кто следит за вашей сетью, также может забрать свой заголовок авторизации, если вы не используете SSL. Cookie и авторизация отправляются как обычный текст в заголовке http.

Что нам делать?

1. Если мы где-то сохраняем токен, нет никаких преимуществ в отношении безопасности над кукисами, токен Auth лучше всего подходит для приложений с одной страницей, добавляя дополнительную защиту или когда файлы cookie недоступны.
2. Если нас беспокоит кто-то, кто следит за сетевым трафиком, мы должны разместить наш сайт с помощью SSL. Cookies и http-заголовки не могут быть перехвачены, если используется SSL.

3. Если мы используем одностраничное приложение, мы не должны хранить токен в любом месте, просто сохраняем его в переменной JS и создаем запрос ajax с заголовком авторизации. Если вы используете jQuery, вы можете добавить обработчик beforeSend к глобальному ajaxSetup который отправляет заголовок маркера Auth всякий раз, когда вы делаете какой-либо запрос ajax.

   var token = false; /* you will set it when authorized */
   $.ajaxSetup({
       beforeSend: function(xhr) {
           /* check if token is set or retrieve it */
           if(token){
               xhr.setRequestHeader('Authorization', 'Bearer ' + token);
           }
       }
   });
   

Если мы хотим использовать Cookies

Если мы не хотим внедрять одностраничное приложение и придерживаться файлов cookie, то есть два варианта.

1. Непостоянные (или сеансовые) файлы cookie: Нестабильные файлы cookie не имеют максимальной продолжительности жизни/срока действия и удаляются, когда пользователь закрывает окно браузера, что делает его настолько предпочтительным в ситуациях безопасности.
2. Стойкие куки файлы: постоянными куками являются те, у которых максимальная продолжительность жизни/срок действия. Эти файлы cookie сохраняются до истечения периода времени. Персистентные куки файлы предпочтительнее, если вы хотите, чтобы cookie существовал, даже если пользователь закрывает браузер и возвращается на следующий день, тем самым предотвращая аутентификацию каждый раз и улучшая работу пользователя.

document.cookie = '__session=' + token  /* Non-Persistent */
document.cookie = '__session=' + token + ';max-age=' + (3600*24*7) /* Persistent 1 week */

Постоянный или непостоянный, который можно использовать, выбор полностью зависит от проекта. И в случае постоянных файлов cookie максимальный возраст должен быть сбалансированным, это не должно быть месяца или часа. 1 или 2 недели выглядят лучше для меня.

Ответ 2

Вы слишком скептически относитесь к хранению маркера ID Firebase в файле cookie. Сохраняя его в файле cookie, он будет отправлен с каждым запросом в вашу Firebase Cloud.

Идентификатор идентификатора Firebase:

Создано Firebase, когда пользователь входит в приложение Firebase. Эти жетоны являются подписанными JWT, которые надежно идентифицируют пользователя в проекте Firebase. Эти токены содержат основную информацию профиля для пользователя, включая строку идентификатора пользователя, которая уникальна для проекта Firebase. Поскольку целостность идентификационных маркеров ID может быть проверена, вы можете отправить их на серверный сервер, чтобы идентифицировать пользователя, который в настоящий момент вошел в систему.

Как указано в определении токена ID Firebase, целостность токена может быть проверена, поэтому его следует хранить в безопасном месте и отправлять на сервер. Проблема возникает из-за того, что вы не хотите предоставлять этот токен в заголовке Authentication для каждого запроса вашей облачной функции Firebase, так как вы хотите избежать использования запросов AJAX для маршрутизации.

Это возвращает его к использованию файлов cookie, поскольку файлы cookie автоматически отправляются с запросами сервера. Они не так опасны, как вы думаете. Firebase даже имеет пример приложения " Созданные на стороне сервера страницы с шаблонами Handlebars tempating и пользовательские сеансы ", в которых используются куки сеанса для отправки идентификатора идентификатора Firebase.

Вы можете увидеть их пример здесь:

// Express middleware that checks if a Firebase ID Tokens is passed in the 'Authorization' HTTP
// header or the '__session' cookie and decodes it.
// The Firebase ID token needs to be passed as a Bearer token in the Authorization HTTP header like this:
// 'Authorization: Bearer <Firebase ID Token>'.
// When decoded successfully, the ID Token content will be added as 'req.user'.
const validateFirebaseIdToken = (req, res, next) => {
    console.log('Check if request is authorized with Firebase ID token');

    return getIdTokenFromRequest(req, res).then(idToken => {
        if (idToken) {
            return addDecodedIdTokenToRequest(idToken, req);
        }
        return next();
    }).then(() => {
        return next();
    });
};

/**
 * Returns a Promise with the Firebase ID Token if found in the Authorization or the __session cookie.
 */
function getIdTokenFromRequest(req, res) {
    if (req.headers.authorization && req.headers.authorization.startsWith('Bearer ')) {
        console.log('Found "Authorization" header');
        // Read the ID Token from the Authorization header.
        return Promise.resolve(req.headers.authorization.split('Bearer ')[1]);
    }
    return new Promise((resolve, reject) => {
        cookieParser(req, res, () => {
            if (req.cookies && req.cookies.__session) {
                console.log('Found "__session" cookie');
                // Read the ID Token from cookie.
                resolve(req.cookies.__session);
            } else {
                resolve();
            }
        });
    });
}

Это позволит вам не нуждаться в AJAX и позволяет маршрутам управлять вашей облачной функцией Firebase. Просто не забудьте взглянуть на шаблон Firebase, где они проверяют заголовок на каждой странице.

<script>
    function checkCookie() {
    // Checks if it likely that there is a signed-in Firebase user and the session cookie expired.
    // In that case we'll hide the body of the page until it will be reloaded after the cookie has been set.
    var hasSessionCookie = document.cookie.indexOf('__session=') !== -1;
    var isProbablySignedInFirebase = typeof Object.keys(localStorage).find(function (key) {
            return key.startsWith('firebase:authUser')
}) !== 'undefined';
    if (!hasSessionCookie && isProbablySignedInFirebase) {
        var style = document.createElement('style');
    style.id = '__bodyHider';
        style.appendChild(document.createTextNode('body{display: none}'));
    document.head.appendChild(style);
}
}
checkCookie();
    document.addEventListener('DOMContentLoaded', function() {
        // Make sure the Firebase ID Token is always passed as a cookie.
        firebase.auth().addAuthTokenListener(function (idToken) {
            var hadSessionCookie = document.cookie.indexOf('__session=') !== -1;
            document.cookie = '__session=' + idToken + ';max-age=' + (idToken ? 3600 : 0);
            // If there is a change in the auth state compared to what in the session cookie we'll reload after setting the cookie.
            if ((!hadSessionCookie && idToken) || (hadSessionCookie && !idToken)) {
                window.location.reload(true);
            } else {
                // In the rare case where there was a user but it could not be signed in (for instance the account has been deleted).
                // We un-hide the page body.
                var style = document.getElementById('__bodyHider');
                if (style) {
                    document.head.removeChild(style);
                }
            }
        });
    });
</script>

Ответ 3

Используйте Генерирование защищенных Token-библиотек и добавьте токен непосредственно (Пользовательская полезная нагрузка для справки):

var token = tokenGenerator.createToken({ "uid": "1234", "isModerator": true });

Ваши данные токена - это uid (или app_user_id) и isModerator внутри выражения правила, например:

{
  "rules": {
    ".read": true,
    "$comment": {
      ".write": "(!data.exists() && newData.child('user_id').val() == auth.uid) || auth.isModerator == true"
    }
  }
}