Для целей настоящих Требований Стороны используют следующую терминологию:
Договор – соглашение между Сторонами об установлении гражданских прав и обязанностей, в котором содержится отсылка к настоящим Требованиям.
Хофф Тех – ООО «Хофф Тех», Сторона по Договору.
Контрагент – лицо, являющееся контрагентом ООО «Хофф Тех» и Стороной в Договоре.
Положения настоящих Требований применяются к отношениям Сторон в силу соответствующей отсылки в Договоре, если иные условия прямо не предусмотрены Договором.

1. Общие требования:
1.1 Учетные данные (пароли, конфигурационные файлы, API-токены и т.д.) для разных сред должны различаться.
1.2 При разработке используются библиотеки и протоколы актуальных версий с учетом лучших практик в сфере разработки и обеспечения информационной безопасности.
1.3 Алгоритмы шифрования должны соответствовать требованиям законодательства РФ.
1.4 Запрещено использовать самописные алгоритмы шифрования и протоколы.
1.5 В журналах приложения не должны включаться чувствительные сведения (пароли, токены, ПДн и т.п.).
1.6 Все используемые в разрабатываемых продуктах сторонние компоненты должны быть получены из подтвержденных внутренних источников (artifactory) и проверены на уязвимости.
1.7 В исходном коде не должны содержаться уязвимости высокого и среднего уровней.
1.8 ПО и его компоненты должны функционировать с минимально возможными полномочиями, в том числе при осуществлении подключений к другим ресурсам (службам, сервисам, базам данных, файловым системам и т.п.).

2. Аутентификация и авторизация
2.1 Все интерактивные формы HTML должны быть защищены от Cross-Site Request Forgery (CSRF).
2.2 Механизм аутентификации должен быть защищен от атак Password spraying и Credential Stuffing – реализован механизм определения и предотвращения необычно большого количества попыток аутентификации от одного или нескольких источников.
2.3 Парольная политика разрабатываемого приложения должна соответствовать парольной политике Хофф Тех. Максимальная длина пароля и количество типов используемых символов не ограничиваются.
2.4 Запрещено включать пароли и другие аутентификационные данные в исходный код.
2.5 Пароли и другие аутентификационные данные должны передаваться только через шифрованные и аутентифицированные протоколы.
2.6 Необходимо обрабатывать пароли необратимыми хэш-функциями при их вводе. Запрещено проводить операции с паролями в незащищенном виде.
2.7 Аутентификационные и авторизационные данные не должны передаваться на сторону клиента.
2.8 Процесс аутентификации должен быть защищен от атак на подбор паролей методом перебора (brute force).
2.9 Пароли и другие чувствительные данные, такие как Session IDs и Database IDs, запрещено передавать как URL-параметр в HTTP Get запросах.
2.10 В приложении должно быть реализовано разграничение доступов, полномочий и создан механизм настройки модели доступа к функциональности и данным приложения.
2.11 Запрещено показывать пароль в открытом виде (при вводе и в других формах).
2.12 Для приложений, предназначенных для работы корпоративных пользователей, следует использовать доменную аутентификацию.
2.13 При изменении чувствительных данных (личные сведения пользователя, контактные данные, настройки безопасности и т.п.) рекомендуется реализовать процесс повторной аутентификации пользователя.
2.14 Рекомендуется реализовать многофакторную аутентификацию при обработке чувствительных данных, в т.ч. через удаленный доступ.

3. Сессии.
3.1 Механизм установления сессий (Session management) должен быть защищен от атак на перехват сессии (Session Fixation attacks).
3.2 Длинна идентификатора сессии должна составлять не менее 128бит, а идентификатор сессии должен быть абстрактным относительно функционала ПО.
3.3 Должна соблюдаться высокая степень энтропии нумерации сессий (рекомендуется применять метод случайных чисел).
3.4 Запрещено передавать идентификатор сессии как часть URL (рекомендуется использовать параметризированные HTTPS запросы или Cookies).

4. Транспорт.
4.1 Все клиент-серверные взаимодействия должны осуществляться с использованием защищенного транспортного протокола через TLS версии не ниже 1.2.
4.2 Для принудительного использования HTTPS для всех запросов должны использоваться strict-transport-security (HSTS) заголовки.
4.3 Используемые Cookies должны являться httpOnly и быть ограничены путем и доменом.
4.4 Запрещено использовать маски типа «*» при формировании Content Security Policy.
4.5 При передаче данных через CDN должно использоваться CSP Subresource Integrity.
4.6 Для защиты от XSS-атак в заголовки ответов должны быть добавлены параметры X-Frame-Option и X-XSS-Protection.

5. Базы данных.
5.1 Доступ к базам данных должен предоставляться только аутентифицированным пользователям по принципу минимальных привилегий. Запрещено использовать: анонимный доступ, пароли по умолчанию, а также всем известные пароли (Well-Known passwords).
5.2 Информацию из баз данных в приложение следует передавать только по защищенному каналу.
5.3 Требуется использовать только параметризированные запросы к базам данных. В целях избежания SQL-инъекций механизмы конкатенации при обработке запросов использовать запрещено.
5.4 При необходимости хранить аутентификационные данные пароли должны хранится в защищенном виде. Для этого следует использовать методы одностороннего хэширования (one-way hashing) и строгие алгоритмы для невозможности обратного восстановления пароля по значению хэша.

6. Ввод и вывод данных.
6.1 Вводимые в приложение данные должны подвергаться синтаксической и семантической проверкам.
6.2 Все вводимые пользователем данные должны проверяться на потенциально опасные символы - символы экранирования (рекомендуется применять «белый список», а не «черный список»).
6.3 Должны использоваться надежные механизмы экранирования при передаче вводимых пользователем данных для предотвращения SQL-инъекций. Аналогичный подход должен применяться при передаче файлов.
6.4 Все вводимые пользователем или внешними приложениями данные рассматриваются как потенциально опасные. Должен быть реализован механизм проверки этих данных на стороне клиента, а затем на принимающей стороне. Проверки должны содержать контроль минимального и максимального размера передаваемых данных, а также их тип.
6.5 Кодировка выводимых данных для предотвращения XSS-атак должна проверяться. Кодировка данных должна соответствовать контексту страницы.