V1.6.4 Cryptographic Architecture

Requirement:

Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data.

Explanation:

Требование определяет порядок работы с клиентскими секретами, включая симметричные ключи, пароли или API-токены, в криптографической архитектуре приложения. В этом требовании подчеркивается, что такие секреты на стороне клиента следует рассматривать как небезопасные и никогда не использовать их для непосредственной защиты или доступа к sensitive data.

1 Client-Side Secrets:

• Под секретами на стороне клиента понимается конфиденциальная информация, которая хранится или обрабатывается на стороне клиента приложения. Это могут быть ключи шифрования, пароли, токены аутентификации и другие sensitive data.

2 Inherent Insecurity:

• Секреты на стороне клиента менее безопасны, чем секреты на стороне сервера. Код и данные на стороне клиента часто открыты для пользователей и могут быть доступны, манипулируемы или украдены злоумышленниками, имеющими физический или удаленный доступ к клиентскому устройству.

3 Sensitive Data Protection:

• Sensitive Data, такие как личная информация, финансовые отчеты или конфиденциальные документы. В компании обрабатывается три типа "sensitive data":

  • Project Sensitive
  • Personal Sensitive
  • Company Sensitive

  Sensitive Data включают информацию, связанную с приложением, например такую ​​как:

  • session tokens
  • file names
  • stack traces
  • Confidential data:
    • пароли
    • данные кредитной карты
    • конфиденциальные данные о состоянии здоровья
    • личные сообщения
    • интеллектуальную собственность
    • метаданные
    • исходный код приложения
    • и т. д. https://cwe.mitre.org/data/definitions/327.html

•  Полагаться только на секреты на стороне клиента для защиты sensitive data рискованно, поскольку они могут быть легко скомпрометированы.

4 Server-Side Protection:

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

5 Secure Communication:

• Если секреты на стороне клиента используются для аутентификации или шифрования, то их основная роль должна заключаться в создании защищенных каналов связи с сервером. Например, они могут использоваться для инициирования безопасного TLS/SSL-соединения или для аутентификации клиента на сервере.

6 Server-Side Decryption and Authentication:

• Сервер должен выполнять расшифровку данных и аутентификацию пользователей или клиентов. Он никогда не должен полагаться только на секреты на стороне клиента для выполнения этих критически важных функций безопасности.

7 Key Derivation:

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

8 Avoiding Client-Side Storage:

• Сведите к минимуму хранение sensitive data или секретов на стороне клиента. По возможности используйте токены или сессионные ключи, чтобы уменьшить раскрытие секретов на стороне клиента.

9 Secure Storage on Server:

• Sensitive data должны надежно храниться на сервере с соблюдением правил шифрования и контроля доступа.

10 Regularly Update and Rotate Secrets:

• Обеспечьте регулярное обновление или ротацию секретов на стороне клиента. Например, API-токены или сессионные ключи должны иметь ограниченный срок действия и заменяться на новые.

11 Logging and Monitoring:

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

---

В качестве примера, рассмотрим веб-приложение, которое использует секреты на стороне клиента (например, API-токены) для аутентификации и устанавливает безопасную связь с сервером:

1. Secure Authentication:

•  Веб-приложение позволяет пользователям входить в систему, используя имя пользователя и пароль.
•  Вместо того чтобы передавать пароль в открытом виде на сервер, код на стороне клиента перед отправкой пароля на сервер хэширует его с помощью надежного и безопасного алгоритма хэширования (например, bcrypt).

Пример хэширования пароля на стороне клиента

// Client-side authentication

const password = 'user123password';

const hashedPassword = hashFunction(password); // Securely hash the password

sendToServer(hashedPassword); // Send the hashed password to the server

2. Server-Side Authentication:

• На стороне сервера приложение получает хэшированный пароль и сравнивает его с сохраненным хэшированным паролем пользователя.
• Если хэшированные пароли совпадают, пользователь аутентифицируется.

Пример проверки хэшированного пароля на стороне сервера

# Server-side authentication

hashed_password = 'hashed_password_from_database'

if received_hashed_password == hashed_password:

# Authentication successful

3. Secure Communication:

• Код на стороне сервера проверяет валидность API-токена при каждом запросе API.
• Он гарантирует, что токен связан с аутентифицированным пользователем, и проверяет его целостность перед обработкой запросов на конфиденциальные данные.

Пример проверки api-токена

# Server-side secure communication

def validate_api_token(request):

api_token = request.headers.get('Authorization')

user = validate_token(api_token) # Verify the token's validity

if user:

# Process the request securely

else:

# Unauthorized access

4. Data Protection on Server:

• Код на стороне сервера отвечает за защиту конфиденциальных данных, включая механизмы шифрования и контроля доступа.

Remediation:

Чтобы выполнить требование и убедиться в том, что криптографическая архитектура приложения рассматривает секреты на стороне клиента как небезопасные и никогда не использует их для защиты или доступа к sensitive data, необходимо выполнить следующее:

1 Server-Side Data Protection:

• Убедитесь, что защита sensitive data и доступ к ним осуществляются в первую очередь на стороне сервера приложения. Для защиты конфиденциальной информации используйте надежное шифрование, контроль доступа и соответствующие механизмы аутентификации на сервере.

2 Secure Communication Initiation:

• Используйте секреты на стороне клиента, такие как API-токены или ключи, в основном для инициирования защищенных соединений с сервером. Эти секреты могут использоваться для установления защищенных TLS/SSL-соединений или для аутентификации клиента на сервере.

3 Hashing for Authentication:

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

4 Minimize Client-Side Storage:

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

5 Secure Storage on Server:

• Храните конфиденциальные данные на сервере в безопасном месте, следуя лучшим практикам в области шифрования и управления доступом. Реализуйте безопасное управление ключами для шифрования на стороне сервера.

6 Key Derivation:

• Реализуйте на сервере функции безопасной генерации ключей шифрования для их создания или токенов аутентификации на основе секретов на стороне клиента. Избегайте раскрытия необработанных секретов.

7 Regular Secret Rotation:

• Установите политику регулярной ротации клиентских секретов, таких как API-токены или сессионные ключи. Замените старые секреты на новые, чтобы снизить риск компрометации.

8 Logging and Monitoring:

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

9 Incident Response Plan:

•  Разработайте план реагирования на инциденты, включающий процедуры реагирования на компрометацию секретов на стороне клиента. Определите, каким образом скомпрометированные секреты должны быть аннулированы и заменены.

10 Security Testing:

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

Additional:

https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

https://owasp.org/www-pdf-archive/Owasp-top-10-proactive-controls-2018-russian.pdf