Атаки и уязвимости

Июль 25, 2022

Главная
Информатика
Атаки и уязвимости

Содержание

2. Пройденные темы Аутентификация Токенизация и управление сессией Управление ключами и криптография Авторизация Протоколы TLS и Oauth
3. Оставшиеся темы Безопасность приложений: anti-tampering software, anti-subversion, intrusion detection. Мониторинг, анализ действий пользователя, аудит Безопасность разработки.
4. Тестирование аутентификации Имена пользователей Корректная проверка e-mail Использование сильных паролей >=10 символов Считать все символы, чувствительные
5. 3 из 4 Нижний регистр Верхний регистр Особый символ Цифра Правила упомянуты на странице смены пароля
6. Процедура забытого пароля Хороший вопрос – универсальный, запоминаемый, постоянный, безопасный Отправка по стороннему каналу Безопасное хранение.
7. Хранение пароля Использовать PBKDF2, bcrypt, scrypt Соль (генератор), PBKDF2(cоль, пароль) – запись в бд HMAС SHA
8. TLS для аутентификации Использовать только TLS для страницы логина и последующих: Атака на страницу логина -
9. Дополнительно Для избежания CSRF, clickjacking, session hijacking – требование переаутентификации про каждом важном действии (смена пароля
10. Сообщения об ошибках и блокировка Не давать инфо об статусе пользователя: Устарел Блокирован Неверный ID Неверный
11. Сторонние приложения (аутентификация без пароля) Использовать Oauth для аутентификации (1.0а или 2.0) Open ID (private) SAML
12. Дополнительно Доступ к истории Логины по умолчанию Выход из аккаунта Запоминание пользователя CAPTCHA
13. OWASP Authentication: https://www.owasp.org/index.php/Authentication_Cheat_Sheet https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet http://goodsecurityquestions.com/
14. Управление сессией Требовать подтверждение (clickjacking) Генерация токена для защиты от CSRF(криптографически или случайно) Защита токена, защита
15. Transaction authentication Users should be able to easily distinguish the authentication process from the transaction authorization
16. Криптографическое хранение данных Архитектура и дизайн CCM, GCM – аутентифицированное шифрование (AES+time+message ID) NIST approved algorithms
17. Управление ключами Устаревание ключей Безопасное хранение ключей (доступ) Ключи отдельно от данных Ключи генерируются независимо Документировтаь
18. Транспорт ключа Протокол – Диффи Хеллман+сертификаты Транспорт – TLS (не SSLv3) Разделенное хранение
19. Криптомодуль Проверен сертифицирован Функции, доступ к ним и хранилище
20. Session Management ID сессии – 128 бит, случайно, криптографически Встроенное управление вместо своего Secure Cookies (Id
21. Cookies Httponly Encrypted Указывать домен и путь Устаревание
22. Устаревание сессии В режиме простоя Обновление или абсолютное устаревание "Cache-Control: no-cache,no-store« and "Pragma: no-cache« Закрытие сессии
23. AC Implement role based access control to assign permissions to application users for vertical access control
24. Best practices Централизованный контроль Проерять авторизацию всех запросов Проверять данные пользователя
28. Скачать презентацию

Слайд 2

Пройденные темы
Аутентификация
Токенизация и управление сессией
Управление ключами и криптография
Авторизация
Протоколы TLS и Oauth

Слайд 3

Оставшиеся темы
Безопасность приложений: anti-tampering software, anti-subversion, intrusion detection.
Мониторинг, анализ действий пользователя,

аудит
Безопасность разработки.
Безопасность веб приложений.

Слайд 4

Тестирование аутентификации
Имена пользователей
Корректная проверка e-mail
Использование сильных паролей
>=10 символов
<=128 (чтобы не создавать

фраз)
<= 20 символов только из букв – слабые
Считать все символы, чувствительные к регистру
Не разрешать подряд больше двух одинаковых
Ясно указывать и неразрешать установить слабый пароль

Слайд 5

3 из 4
Нижний регистр
Верхний регистр
Особый символ
Цифра
Правила упомянуты на странице смены пароля

Слайд 6

Процедура забытого пароля
Хороший вопрос – универсальный, запоминаемый, постоянный, безопасный
Отправка по стороннему

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

Слайд 7

Хранение пароля
Использовать PBKDF2, bcrypt, scrypt
Соль (генератор), PBKDF2(cоль, пароль) – запись в

бд
HMAС SHA 256

Слайд 8

TLS для аутентификации
Использовать только TLS для страницы логина и последующих:
Атака на

страницу логина - данные могут быть переданы
Атака на ID сессии – сессия может быть скомпрометирована
Взаимный обмен сертификатами у клиента и сервера при рукопожатии (испольщуется постоянный компьютер, комптютер организации и пользователь не боится сертификатов)

Слайд 9

Дополнительно
Для избежания CSRF, clickjacking, session hijacking – требование переаутентификации про каждом

важном действии (смена пароля установка адреса покупка и тд) – атака на ID сессии
Многофакторная аутентификация – знать, иметь, быть
OTP + hardware token

Слайд 10

Сообщения об ошибках и блокировка
Не давать инфо об статусе пользователя:
Устарел
Блокирован
Неверный

ID
Неверный пароль
По коду ошибки
Блокировать после нескольких попыток

Слайд 11

Сторонние приложения (аутентификация без пароля)
Использовать Oauth для аутентификации (1.0а или 2.0)
Open

ID (private)
SAML (enterprise)
FIDO: UAF+U2F (PKC) – защита от фишинга, хранение ключа на устройстве, hardware token, biometry

Слайд 12

Дополнительно
Доступ к истории
Логины по умолчанию
Выход из аккаунта
Запоминание пользователя
CAPTCHA

Слайд 13

OWASP
Authentication: https://www.owasp.org/index.php/Authentication_Cheat_Sheet
https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet
http://goodsecurityquestions.com/

Слайд 14

Управление сессией
Требовать подтверждение (clickjacking)
Генерация токена для защиты от CSRF(криптографически или случайно)
Защита

токена, защита ID сессии

Слайд 15

Transaction authentication
Users should be able to easily distinguish the authentication process

from the transaction authorization process
Malware can trick users in authorizing fraudulent operations, when an application requires a user to perform the same actions for authentication as for transaction authorization. Consider the following example:
An application is using the same method for user authentication (usually as a second factor to traditional login/password) and for transaction authorization. E.g. by using a OTP token, Challenge-response codes, operation signing using external smartcard, ...
A malware may present the user a false error message after the first step (authentication to the application) and trick the user into repeating the authentication procedure. The first authentication code will be used by the malware for authentication, whereas the second code would be used to authorize a fraudulent transaction. Even challenge-response schemes could be abused using this scenario as malware can present a challenge taken from a fraudulent transaction and trick the user to provide response. Such an attack scenario is used widely in malware attacks against electronic banking.
In the abovementioned scenario, the same method was used to authenticate the user and to authorize the transaction. Malware can abuse this behaviour to extract transaction authorization credentials without the user’s knowledge. Social engineering methods can be used despite utilized authentication and operation authorization methods but the application shouldn’t simplify such attack scenarios.
Safeguards should allow the user to easily distinguish authentication from transaction authorization. This could be achieved by:
using different methods to authenticate and to authorize,
or using different actions in an external security component (e.g. different mode of operation in CAP reader),
or presenting the user a clear message about what he/she is “signing” (What You See Is What You Sign Principle).

Слайд 16

Криптографическое хранение данных
Архитектура и дизайн
CCM, GCM – аутентифицированное шифрование (AES+time+message ID)
NIST

approved algorithms
ISO TR 14742 "Recommendations on Cryptographic Algorithms and their use" or Algorithms, key size and parameters report – 2014
AES 256, RSA 3072, SHA 256
Режимы шифрования AES – CCM, GCM, CBC+HMAC
Библиотека – FIPS 140-2
Не реализовывать
Сильный пароль для хранения ключейб хранить пароли защищенно
Генератор псевдослучайных NIST RNG Test tool
Разные ключи для разных данных
XTS для шифрования диска
Шифрование работает независимо от доступа к паролям

Слайд 17

Управление ключами
Устаревание ключей
Безопасное хранение ключей (доступ)
Ключи отдельно от данных
Ключи генерируются независимо
Документировтаь

управление ключами
Ключи хранятся в обособленном хранилище
1-3 года – обновление ключей
PCI DSS requirement 3 – хранение PAN
Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or "one way"). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).
KEK(master key)
Аудит, логи
Генерация ключей

Слайд 18

Транспорт ключа
Протокол – Диффи Хеллман+сертификаты
Транспорт – TLS (не SSLv3)
Разделенное хранение

Слайд 19

Криптомодуль
Проверен сертифицирован
Функции, доступ к ним и хранилище

Слайд 20

Session Management
ID сессии – 128 бит, случайно, криптографически
Встроенное управление вместо своего
Secure

Cookies (Id по зашифрованному каналу)
encrypted HTTPS (SSL/TLS) connection
Различные хосты и соединения для защищенных и незащищенных данных
SSL/TLS (HTTPS) does not protect against session
ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today

Слайд 21

Cookies
Httponly
Encrypted
Указывать домен и путь
Устаревание

Слайд 22

Устаревание сессии
В режиме простоя
Обновление или абсолютное устаревание
"Cache-Control: no-cache,no-store« and "Pragma: no-cache«
Закрытие

сессии при закрытии окна броузера
Аудит и ведение лога
Одновременный вход одного пользоваиекоя

Слайд 23

AC
Implement role based access control to assign permissions to application users

for vertical access control requirements
Avoid assigning permissions on a per-user basis
Perform consistent authorization checking routines on all application pages
Where applicable, apply DENY privileges last, issue ALLOW privileges on a caseby-case basis
Where possible restrict administrator access to machines located on the local area network (i.e. it’s best to avoid remote administrator access from public facing access points)
Log all failed access authorization requests to a secure location for review by administrators
Perform reviews of failed login attempts on a periodic basis

Слайд 24

Best practices
Централизованный контроль
Проерять авторизацию всех запросов
Проверять данные пользователя

Слайд 25

Слайд 26

Атаки и уязвимости

Содержание

Пройденные темыАутентификацияТокенизация и управление сессиейУправление ключами и криптографияАвторизацияПротоколы TLS и Oauth

Оставшиеся темыБезопасность приложений: anti-tampering software, anti-subversion, intrusion detection.Мониторинг, анализ действий пользователя,

Тестирование аутентификацииИмена пользователейКорректная проверка e-mailИспользование сильных паролей>=10 символов<=128 (чтобы не создавать

3 из 4Нижний регистрВерхний регистрОсобый символЦифраПравила упомянуты на странице смены пароля

Процедура забытого пароляХороший вопрос – универсальный, запоминаемый, постоянный, безопасныйОтправка по стороннему

Хранение пароляИспользовать PBKDF2, bcrypt, scryptСоль (генератор), PBKDF2(cоль, пароль) – запись в

TLS для аутентификацииИспользовать только TLS для страницы логина и последующих:Атака на

ДополнительноДля избежания CSRF, clickjacking, session hijacking – требование переаутентификации про каждом

Сообщения об ошибках и блокировкаНе давать инфо об статусе пользователя: УстарелБлокированНеверный

Сторонние приложения (аутентификация без пароля)Использовать Oauth для аутентификации (1.0а или 2.0)Open

ДополнительноДоступ к историиЛогины по умолчаниюВыход из аккаунтаЗапоминание пользователяCAPTCHA

OWASPAuthentication: https://www.owasp.org/index.php/Authentication_Cheat_Sheethttps://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheethttp://goodsecurityquestions.com/

Управление сессиейТребовать подтверждение (clickjacking)Генерация токена для защиты от CSRF(криптографически или случайно)Защита

Transaction authenticationUsers should be able to easily distinguish the authentication process

Криптографическое хранение данныхАрхитектура и дизайнCCM, GCM – аутентифицированное шифрование (AES+time+message ID)NIST

Управление ключамиУстаревание ключейБезопасное хранение ключей (доступ)Ключи отдельно от данныхКлючи генерируются независимоДокументировтаь

Транспорт ключаПротокол – Диффи Хеллман+сертификатыТранспорт – TLS (не SSLv3)Разделенное хранение

КриптомодульПроверен сертифицированФункции, доступ к ним и хранилище

Session ManagementID сессии – 128 бит, случайно, криптографическиВстроенное управление вместо своегоSecure

CookiesHttponlyEncryptedУказывать домен и путьУстаревание

Устаревание сессииВ режиме простояОбновление или абсолютное устаревание"Cache-Control: no-cache,no-store« and "Pragma: no-cache«Закрытие

ACImplement role based access control to assign permissions to application users

Best practicesЦентрализованный контрольПроерять авторизацию всех запросовПроверять данные пользователя

Похожие презентации