Security

Question 1

Что такое CORS?

Answer 1

CORS - это Cross-Origin Resource Sharing, браузерный механизм обеспечения безопасности загрузки данных от сторонних хостов.

По умолчанию браузера разрешает все запросы в рамках текущего хоста.

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

Для проверки перед отправкой основного запроса браузер отправляет prefligh-запрос OPTIONS с заголовками.
~~~
OPTIONS /url HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type
~~~
Ответ сервера:
~~~
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 86400
~~~

Question 2

Какие применяются заголовки запроса OPTIONS?

Answer 2

Браузер автоматически отправляет заголовки:

1. Access-Control-Allow-Origin: <origin> | *
   Разрешенные источники.
   Необходимо указывать <origin> для запросов с учетными данными.
2. Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
   Разрешенные хедеры для обработки браузером.
3. Access-Control-Max-Age: <delta-seconds>
   Разрешенная длительность кеширования результата preflight.
4. Access-Control-Allow-Credentials: true
   Разрешение запросов с учетными данными.
5. Access-Control-Allow-Methods: <method>[, <method>]*
   Разрешенные методы запросов.
6. Access-Control-Allow-Headers: <field-name>[, <field-name>]*
   Разрешенные хедеры запросов.

Question 3

Какие применяются заголовки ответа OPTIONS?

Answer 3

1. Origin: <origin>
2. Access-Control-Request-Method: <method>
3. Access-Control-Request-Headers: <field-name>[, <field-name>]*

Question 4

Какие применяются заголовки обеспечения безопасности?

Answer 4

1. Strict-Transport-Security: max-age=<expire-time>; includeSubDomains; preload
   Запрещает получение доступа к сайту не через HTTPS.
2. X-Frame-Options: DENY | SAMEORIGIN
   Запрещает сайту быть загруженным внутри IFrame вне источника.
3. X-Content-Type-Options: nosniff
   Запрещает запрос, если тип ресурса не совпадает с MIME-типом.
4. referrerPolicy: strict-origin-when-cross-origin
   Указывает возможность передачи информации об источнике перехода.

Question 5

Как передать авторизационные данные?

Answer 5

Авторизационные данные возможно передать через заголовок Authorization. Стандартом считается значение Bearer <token>.
Также token принято передавать через cookie.

Question 6

Что такое CSP?

Answer 6

CSP - Content Security Policy, заголовок Content-Security-Policy, который указывает разрешения для контента различных типов.
1. Fetch-директивы. Разрешенные источники ресурсов. Например, script-src, img-src и др. В значении указывается источник, hash-сумма и nonce-значение.
2. Директивы документа.
3. Директивы навигации.

Question 7

Что такое JWT?

Answer 7

JWT - JSON Web Token, стандарт для обмена информацией между элементами системы, обычно клиентом и сервером.
Каждый JWT подписывается, чтобы гарантировать, что содержание не может быть изменено клиентом или вредоносным агентом.
Токен нужен для проверки разрешения для получения данных (авторизации доступа) клиента сервером.

Question 8

Какова структура JWT?

Answer 8

JWT состоит из трех частей:
1. Заголовок (Header) состоит из дух частей:
- Алгоритм шифрования токена
- Тип токена. Обычно JWT
Например:

json
{
"alg": "HS256",
"type": "JWT"
}
~~~
2. Нагрузка (Payload) содержит JSON
Например:

json
{
“sub”: “1234567890”,
“name”: “John Joe”,
“admin”: true,
“iat”: 13353443234234
}
~~~
Стандартные свойства, применяемые в JWT:
- iss - инициатор (issuer)
- sub - субъект (subject), идентификатор пользователя
- aud - аудитория (audience), идентификатор приложения или идентификатор API
- exp - время устаревания (expiration)
- nbf - не ранее времени (not before)
- iat - дата создания
- jti - идентификатор токена (JWT ID)
Возможно использование любых свойств, которые помогут идентифицировать пользователя.
3. Подпись (Signature) строка, которая генерируется для проверки правдивости передаваемого Payload.

Question 9

Как создается JWT-токен?

Answer 9

1. Создание Payload
2. Генерация ключа подписи
3. Создание Header
4. Создание подписи:
   
   1. Шифрование Payload в Base64
   2. Шифрование Header в Base64
   3. Объединение в строку ${Header}.${Payload}
   4. Генерация Signature по объединенной строке
   5. Шифрование Signature в Base64
5. Объединение в строку ${Header}.${Payload}.${Signature}

Question 10

Как проверяется JWT-токен?

Answer 10

1. Получение Header
2. Расшифровка Header из Base64
3. Проверка Header
4. Отказ при неверном Header
5. Создание подписи:
   
   1. Генерация Signature по ${Header}.${Payload}
   2. Шифрование Signature в Base64
6. Проверка равенства сгенерированной и полученной подписей
7. Отказ при неравенстве подписей
8. Расшифровка Payload
9. Отказ при превышении текущего времени “exp”

Question 11

Какие плюсы и минусы JWT?

Answer 11

Плюсы:
1. Защищенность от модификации с помощью подписи
2. Хранение токена только на клиенте, отсутствует необходимость обращаться с базе данных с целью проверки клиента
3. Быстродействие за счет отсутствия лишних запросов в базе данных

Минусы
1. Невозможно отозвать токен, пока он не устареет.
Необходимо создание черных списков токена, что лишает токен достоинств быстродействия.
Лучшим решением будет создание связки “access” и “refresh” для обращения токенов.
2. Привязанность к ключу подписи влечет за собой кражу данных всех клиентов при его обнародовании.

Question 12

Как работает обращение токенов?

Answer 12

Для каждого клиента создается пара токенов: прозрачный долгосрочный refresh-токен и приватный краткосрочный access-токена.
Когда пользователь совершает попытку получения доступа к ресурсу, он должен отослать access-токен с каждым запросом.
Когда access-токен устаревает, клиент использует refresh-токен и посылает запрос к сервису авторизации, чтобы получить новый access-токен и новый refresh-токен.
При необходимости отзыва доступа у клиента внедряется проверка на случай устаревания refresh-токена.

Question 13

Какие существуют варианты храниния токена на клиента? Какие плюсы и минусы?

Answer 13

1. Cookie.
   Сервер авторизации записывает access- и refresh-токены в недоступном для чтения виде (Http-Only), а также запрещает отсылать такой Cookie вне HTTPS с флагом secure=true и вне контекста с флагом SameSite=Strict.
   Сервер автоматически производит ротацию токенов в Cookies при обращении к сервер авторизации.
   Для решения такой проблемы возможно запрограммировать редиректы между разными хостами и сервисами авторизации для получения токенов по всем хостам.
   Для отправки токена возможно использование флага SameSite=None во и параметра credentials: ‘include’ в запросе в новых браузерах.
2. Local Storage
   Хранение в локальном хранилище токена приводит к вероятности хищения данных в случае внедрения вредоносного кода (XSS-атаки), например, установки вредоносного расширения в браузер.
   Возможно частично защититься от внедрения с помощью Content Security Policy, которые гарантируют запуск только подписанного кода. Тем не менее, чтение данных из Local Storage теоретически возможно в неофициальных версиях браузеров.
3. Session Storage
   Действует аналогично Local Storage, но данные стираются при закрытии вкладки.
4. Память браузера
   С целью получения возможностей доступа по access-токен к другим хостам и сохранения защиты от полной кражи токенов возможно хранение access-токена в памяти или Session Storage, а refresh-токена в Cookies.

Question 14

Какие существуют способы атаки?

Answer 14

1. XSS - Cross-Site Scripting.
   Атака через внедрение вредоносного кода в JavaScript для кражи секретных данных.
   Три варианта атаки:
   
   1. Stored XSS.
      Добавление кода в поле, которое сохранит код.
      В дальнейшем этот код будет загружен другими пользователями вместе с полем.
      Например, доска объявлений.
      Для защиты необходимо проверять данные на промежуточном слое перед сохранением и/или отправкой.
      На клиентской стороне необходимо экранировать опасные символы перед отправкой или внедрением на страницу, подписывать ресурсы через CSP, хранить секретные данные в HttpOnly-куки.
   2. Reflected XSS.
      Браузер исполняет вредоносный код в ходе обработки ответа HTTP.
      Код из ссылки или адресной строки попадают на страницу и исполняются без ведома пользователя.
      Для защиты необходимо проверять данные на промежуточном слое перед сохранением и/или отправкой.
      На клиентской стороне необходимо экранировать опасные символы перед внедрением на страницу, подписывать ресурсы через CSP, хранить секретные данные в HttpOnly-куки.
   3. DOM XSS.
      Браузер исполняет код в результате внедрения на страницу HTML-элемента.
      Например, внедрение тега с невалидным src для вызова ошибки и атрибутом onerror для исполнения вредоносного кода.
      Для защиты необходимо использовать безопасные источники для записи в DOM.
      На клиентской стороне необходимо экранировать опасные символы перед внедрением на страницу, подписывать ресурсы через CSP, хранить секретные данные в HttpOnly-куки.
2. CSRF - Cross-Site Request Forgery
   Атака через вызов методов взаимодействия с API без ведома пользователя со стороннего ресурса.
   Защититься можно с помощью отправки CSRF-токена при выполнении запроса на изменение, либо необходимо использовать защищенные куки.
3. Перехват траффика.
   Атака с помощью подделки запросов или ответов HTTP.

Question 15

Как реализовать CSRF-токен?