Заметки с тегом «security»

Автоматический вход на сайт с использованием Credential Management API

Современные браузеры предоставляют возможность пользователям сохранять пароль, когда пользователь входит на сайт. После этого сохранённые логин и пароль автоматически подставляется в форму входа, когда пользователь возвращается на сайт. Для сайта этот процесс проходит абсолютно незаметно. Однако автозаполнение не всегда работает правильно.

Credential Management API позволяет разработчикам сайта сохранять и получать данные для аутентификации. Обязательным условием работы этого API является безопасное соединение с сервером.


if (window.PasswordCredential) {
  navigator.credentials
    .get({
      password: true,
      mediation: 'optional'
    })
    .then(credential => {
      if (!credential) {
        return;
      }

      console.log(`Username: ${credential.id}`);
      console.log(`Password: ${credential.password}`);
    });
}

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

Свойство mediation у параметра метода .get() определяет сценарий запроса подтверждения у пользователя. Допустимые значения:

  • required — браузер всегда будет запрашивать разрешение;
  • optional — браузер будет запрашивать разрешение, если пользователь до этого момента не дал его;
  • silent — браузер не будет явно запрашивать разрешение.

Sign in with your account saved with Google Chrome

Чтобы отозвать ранее выданное разрешение (например, когда пользователь выходит из системы) нужно вызвать метод .preventSilentAccess().


if (navigator.credentials && navigator.credentials.preventSilentAccess) {
  navigator.credentials.preventSilentAccess();
}
Комментарии к заметке: 2

CSRF-атака на ваш API

Иван Гришаев в своей статье Руководство по кросс-доменным запросам (CORS) подробно рассказываем про механизм осуществления запроса на другой сервер. В частности, он описывает «простые» и «сложные» запросы.

Простым считается запрос методами:

  • HEAD
  • GET
  • POST

и заголовками:

  • Accept
  • Accept-Language
  • Content-Language
  • Last-Event-ID
  • Content-Type, но только со значениями:
    — application/x-www-form-urlencoded
    — multipart/form-data
    — text/plain

Если ваш запрос удовлетворяет этим критериям, можно слать Аякс к другому домену из любого современного браузера.

Вот такие простые запросы злоумышленники могут эксплуатировать для CSRF-атак.

fetch('https://jsfiddle.net/echo/html/', {
  method: 'POST',
  credentials: 'include',
  body: new URLSearchParams({
    html: 'My test response'
  })
});

Даже если ответ не был принят браузером, тем не менее сервер уже совершил какие-то операции. А так как вместе с запросом автоматически передаются cookie, то эти операции могу быть выполнены от лица авторизованного пользователя или администратора.

Как защититься?

  1. Принимаем только запросы с заголовком Content-Type: application/json.

    Это автоматически делаем запрос «сложным». Он будет выполнен в 2 этапа: сначала браузер проверит какие заголовки разрешены для CORS-запроса, а затем выполнит основной запрос.

  2. Правильно выставляем заголовки Access-Control-Allow-Origin, Access-Control-Allow-Headers, Access-Control-Allow-Methods и Access-Control-Max-Age.

  3. Авторизацию пользователя выполняем только по значению в заголовке, а не по cookie.

    Стоит отметить, что хранить авторизационный токен в cookie не опасно. Но использовать его на сервере нельзя так как все cookie для домена, на который выполняется запрос, как я уже упомянул, пересылаются автоматически.

    Заголовки же можно выставить только явно при формировании запроса. Но злоумышленник не будет иметь доступа к нужным данным в браузере и, соответственно, физически не сможет совершить запрос от лица авторизованного пользователя.

Оставте свой комментарий

Обновление сертификата Let’s Encrypt

Сертификаты Let’s Encrypt «живут» всего 90 дней. Такой короткий срок авторы проекта выбрали исходя из того, что выпущенные сертификаты легко обновить. Для этого нужно запустить инсталлятор с теми же параметрами, которые были использованы во время получения сертификата. Инсталлятор обнаружит, что на сервере уже есть сертификат для этих доменов и предложит обновить их.

После успешной загрузки обновлённых сертификатов инсталлятор сообщит дату окончания их действия.

Конфигурационные файлы сервера изменять при этом не нужно. На сервере хранятся все версии выпущенных сертификатов в папке /etc/letsencrypt/archive/, а в папке /etc/letsencrypt/live/ создаются симлинки на актуальные версии.

Запуск инсталлятора можно запланировать в crontab.

Оставте свой комментарий

Как получить сертификат Let’s Encrypt в ручном режиме

На данный момент инсталлятор Let’s Encrypt, со слов авторов проекта, может автоматически исправлять конфигурацию только Apache . Поддержка nginx и других HTTP-серверов находится в разработке. Тем не менее, это не помешает вам получить сертификат.

Если у вас уже работает какой-то веб-сервер, то инсталлятор следует запустить с ключом --webroot. Ключ certonly указывает, что мы только хотим получить сертификат. Ключом -w мы сообщаем расположение корневой папки сайта.

Так же следует перечислить домены, на которых работает сайт, с помощью ключа -d.

Через несколько секунд вы получите сообщение о том, что сертификат получен и его можно использовать.

Работающий веб-сервер нужен инсталлятору, чтобы подтвердить ваше право владения доменом. Если вы ещё не настраивали его, то инсталлятор может сам запустить такой временный сервер на 80 или 443 порту.

Это делается с помощью ключа --standalone.

В отличие от режима webroot, в режиме standalone можно не указывать домены в командной строке.

Инсталлятор запросит их позже в диалоговом окне.

Все генерированные ключи и выпущенные сертификаты лежат в папке /etc/letsencrypt/live/$domain.

  • privkey.pem — приватный ключ. Он должен всё время храниться в секрете. Это тот файл, который указывается в опции SSLCertificateKeyFile у Apache или в опции ssl_certificate_key у nginx.
  • cert.pem – сертификат для домена. Этот файл указывается в опции SSLCertificateFile у Apache.
  • chain.pem — цепочка из промежуточных и корневого сертификатов центра сертификации. Путь до этого файла указывается в опции SSLCertificateChainFile у Apache.
  • fullchain.pem — Все сертификаты в одном файле, включая сертификат для домена. Данный файл нужно указать в опции ssl_certificate у nginx.
Оставте свой комментарий

Настройка сертификатов Let’s Encrypt в Apache

В статье про бесплатные сертификаты для доменов я упомянул, что получить его и настроить сервер с появлением центра сертификации Let’s Encrypt стало очень просто. Покажу все шаги для настройки Apache.

Для начала, нужно загрузить установщик Let’s Encrypt. Если у вас чистая виртуальная машина, то кроме Git ничего не понадобится. Все остальные зависимости будут установлены позже.

apt-get install git

Установка Git

Клонируем репозиторий из Github.

git clone https://github.com/letsencrypt/letsencrypt

Клонирование репозитория Let’s Encrypt из Github

Переходим в папку с инсталятором.

cd letsencrypt

Переходим в папку с Let’s Encrypt

Инсталятор запускается командой:

./letsencrypt-auto

У него много параметров, посмотреть которые можно в справке.

./letsencrypt-auto --help all

Нас интересует получение сертификатов и установка их в Apache.

./letsencrypt-auto --apache

Запускаем установщик, который получит сертификаты и сконфигурирует сервер Apache

Установщик проверяет конфигурацию сервера. Если вы явно не указали доменные имена, то он предложит их ввести вручную.

Если в конфигурации Apache не указаны домены, то установщик запросит их у вас

Если домены были явно указаны, то инсталлятор предложит выбрать для каких из них он должен получить сертификат.

Установщик нашёл сконфигурированные домены

Он так же попросит указать email для обратной связи. Этот адрес электронной почты не будет добавлен в сертификат.

Требуется указать email для обратной связи

Перед полученим сертификатов требуется принять условия предоставления услуг.

Перед полученим сертификатов требуется принять условия предоставления услуг

Установщик может добавить правила для перенаправления пользователей с обычной версии сайта на версию с безопасным подключением.

Установщик может добавить правила для перенаправления пользователей с обычной версии сайта на версию с безопасным подключением

Настройка завершена. Инсталлятор предлагает проверить конфигурацию сервера с помощью онлайн сервиса Qualys SSL Lab .

Настройка завершена

Сайт уже можно попробовать открыть в браузере.

Проверяем полученный сертификат в браузере

Инсталлятор скопировал существующую конфигурацию сайта, добавил в оригинальный файл редирект на HTTPS-версию, а в копии указал пути до приватного ключа, сертификата домена и промежуточных сертификатов. Так же он подключил файл с дополнительными настройками для mod_ssl.

Изменения в конфигурационных файлах Apache

Как видите, настройка безопасного соединения для вашего сервера оказалась не такая уж и сложная.

Комментарии к заметке: 11