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

Является ли приложение уязвимым?

Приложение можно считать уязвимым, если: Разрешен перебор (нет блокировки новой попытки авторизации после нескольких неудачных); Разрешены слабые пароли (Password1, admin/admin); Используются слабые процессы восстановления учетных записей (ответы на основе знаний); Используются текстовые, зашифрованные или слабо хешированные пароли (см. А3); Отсутствует или неэффективная многофакторная аутентификация; Система подставляет идентификаторы сеанса в URL; * Нет срока жизни идентификатора сессии.

Как предотвратить

• Там, где возможно, реализуйте проверку подлинности, чтобы предотвратить атаки с использованием автоматических учетных данных, перебора или повторного использования украденных учетных данных.
• Не разворачивайте систему с какими-либо учетными данными по умолчанию (особенно для администраторов)
• Реализуйте проверку слабых паролей, например, проверяя новые или измененные пароли по списку 10000 худших паролей (https://github.com/danielmiessler/SecLists/tree/master/Passwords).
• Согласуйте политики длины, сложности и ротации паролей с рекомендациями (https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret), или с любыми другими.
• Ограничьте попытку входа после нескольких неудачных попыток. Регистрируйте все сбои и предупреждайте администраотров при обнаружении взлома учетных данных, переборе или других атаках.
• Используйте защищенный встроенный менеджер сеансов на стороне сервера, который генерирует новый случайный идентификатор сеанса с высокой энтропией после входа в систему. Идентификаторы сеанса не должны быть частью URL, должны быть надежно сохранены и аннулированы после выхода из системы, простоя или по тайм-ауту.

Примеры сценариев атаки:

• Ввод учетных данных, использование списков известных паролей. Если в приложении не реализована автоматическая защита от угроз или заполнения учетных данных, приложение можно использовать в качестве проверки пароля, чтобы определить, действительны ли учетные данные (вместе с уязвимостью А10 это дает широкий простор злоумышленникам, среднее время вщлома системы в 2016 было 191 день).
• Большинство атак аутентификации происходит из-за постоянного использования паролей (однофакторная аутентификация). Организациям рекомендуется прекратить эту практику согласно NIST 800-63 (https://www.nist.gov/itl/tig/projects/special-publication-800-63) и использовать многофакторную аутентификацию.
• Тайм-ауты сеанса приложения установлены неправильно. Пользователь использует общедоступный компьютер для доступа к приложению. Вместо того, чтобы выбирать «выход», пользователь просто закрывает вкладку браузера и уходит. Злоумышленник использует тот же браузер через час, где пользователь все еще авторизован.

Рекомендации OWASP по аутентификации

• Убедитесь, что имена пользователей / идентификторы не чувствительны к регистру. Пользователь smith, Smith должны быть одним пользователем. Имена пользователей должны быть уникальными. Для приложений с высоким уровнем безопасности имена пользователей могут быть назначены и быть секретными вместо пользовательских общедоступных данных.
• Внедрить надлежащие срадства управления надежностью пароля. Ключевой проблемой является надежность пароля. Политика надежных паролей затрудняет или даже делает невозможным угадывание пароля с помощью ручнцх или автоматических средств. #### Какой пароль считать надежным
  • Длина пароля
    • Минимальная длина пароля соблюдается приложением. Пароли длиной менее 10 символов считаются слабыми (http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf).
    • Не ограничивать максимальную длину. Обычно она составляет 128 символов.
    Сложность пароля. Приложения должны обеспечивать соблюдение правил сложности паролей, чтобы не допускать легко угадываемых паролей. Механизмы паролей должны позволять вводить практически любой символ, включая в символ пробела. Пароли должны быть чувствительны к регистру, чтобы увеличить их сложность. Механизм смены пароля должен требовать минимального уровня сложности, который имеет смысл для приложения и пользователей. Например:
    • Пароль должен соответствовать (как минимум) 3 из 4 правилам сложности
      • Минимум один заглавный символ (A-Z);
      • Минимум один строчный символ (a-z);
      • Минимум одна цифра (0-9);
      • Минимум один спецсимвол (не пунктуация);
      Не менее 10 символов
    • Максимум 128 символов
    • Не более 2 одинаковых символов подряд
    Топологии паролей
    • Запретить часто используемые топологии паролей
    • Заставить нескольких пользователей использовать разные топологии паролей
    • Требовать минимального изменения топологии между старыми и новыми паролями
• Внедрить механизм безопасного восстановления паролей. Обычно в приложении имеется механизм, который предоставляет пользователю возможность получить досту к своей учетной записи в случае, если он забудет свой пароль. OWASP рекомендует ознакомиться с подробностями по ссылке: https://www.owasp.org/index.php/ForgotPasswordCheat_Sheet
• Храните пароли в безопасном месте. Для приложения важно хранить пароль с использованием криптографической техники. OWASP рекомендует ознакомиться со статьей: https://www.owasp.org/index.php/PasswordStorageCheat_Sheet.
• Передача паролей только через TLS или другой надежный канал. Страница входа и все последующие аутентификационные страницы должны быть доступны исключительно через TLS или другой надежный канал. Начальная страница входа в систему должна обслуживаться через TLS или другой надежный канал.
• Требовать повторной аутентификации для важных функций. Чтобы снизить риск CSRF и перехват сеансов, важно требовать ввод учетных данных перед обновлением конфиденциальной информации учетной записи (пароль, электронная почта, важные операции).
• Строгая аутентификация транзакций. Приложение должно ответить общим сообщением об ошибке независимо от того, был ли неверный идентификатор пользователя или пароль. Он также не должен указывать на статус существующей учетной записи (Нельзя вывести сообщение «Введен неправильный пароль» или «Пароль не соответствует учетной записи»). OWASP рекомендует ознакомиться со следующей ссылкой: https://www.owasp.org/index.php/TransactionAuthorizationCheatSheet. 
• Предотвращение брутфорса. Если злоумышленник может угадать пароли без блокировки учетной записи после неудачных попыток аутентификации, у злоумышленника есть возможность продолжить атаку методом перебора до тех пор, пока учетная запись не будет взломана. Автоматизация атак методом веб-приложений методом подбора паролей и подбора паролей — тривиальная задача. Следует использовать механизмы блокировки, которые блокируют учетную запись, если предпринято больше заданного количества неудачных попыток входа в систему. Механизмы блокировки имеют недостаток. Злоумышленник, осуществляющий большое количество попыток авторизации для известных имен учетных записей, может получить результат, который блокирует целые блоки учетных записей пользователей. Учитывая, что целью системы блокировки паролей является защита от атак методом перебора, разумной стратегией является блокировка учетных записей на период времени (например, 20 минут). Кроме того, многофакторная аутентификация является мощным сдерживающим фактором при попытке предотвратить атаки методом перебора, поскольку подобранные учетные данные не гарантируют вход в систему. Когда многофакторный режим реализован и активен, блокировка учетной записи может больше не потребоваться. 
• Мониторинг аутентификации. Необходимо включить ведение журнала и мониторинг функций аутентификации для обнаружения атак/сбоев в режиме реального времени (см. А10). Убедитесь, что все сбои зарегистрированы и проверены Убедитесь, что все ошибки ввода пароля зарегистрарованы и проверены Убедитесь, что все блокировки учетной записи зарегистрарованы и проверены
•  Использование протоколов аутентификации, не требующих ввода пароля. Несмотря на то, что аутентификация с использованием комбинации логина и пароля в целом считается безопасной, существуют ситуации, где их использование не считается уместным. Примером может служить стороннее приложение, которое должно подключиться к веб-приложению с мобильного устройства, другого сайта, компьютера. Когда такое происходит, не считается безопасным разрешать стороннему приложению хранить комбинацию пользователь/пароль, т.к. это расширяет фронт для атаки.

распрастраненными считаются следующие протоколы аутентификации:

Управление сессией. Управление сеансом напрямую связано с аутентификацией. OWASP рекомендует ознакомиться со следующей ссылкой: https://www.owasp.org/index.php/SessionManagementCheatSheet

Полезные ссылки

• https://www.owasp.org/index.php/Top10-2017A2-Broken_Authentication
• https://www.owasp.org/index.php/OWASPProactiveControls#5:ImplementIdentityandAuthentication_Controls
• https://www.owasp.org/index.php/Category:OWASPApplicationSecurityVerificationStandard_Project#tab.3DHome
• https://www.owasp.org/index.php/Category:OWASPApplicationSecurityVerificationStandard_Project#tab.3DHome
• https://www.owasp.org/index.php/TestingIdentityManagement
• https://www.owasp.org/index.php/Testingforauthentication
• https://www.owasp.org/index.php/AuthenticationCheatSheet
• https://www.owasp.org/index.php/CredentialStuffingPreventionCheatSheet
• https://www.owasp.org/index.php/ForgotPasswordCheat_Sheet
• https://www.owasp.org/index.php/SessionManagementCheat_Sheet
• https://www.owasp.org/index.php/OWASPAutomatedThreatstoWeb_Applications

---

Способы защиты:

• Использование проверенных механизмов Аутентификации (MembershipProviders).
• Передавать идентификатор сессии через Cookei. По умолчанию в ASP.NET всегда используются cookie. (Вообще не передавать ни какую важную информацию в строке URL.)

Пример настройки SessionState в ASP.NETПример отключения Cookie

<sessionState cookieless="true" />

• Настройка времени жизни сессии. Нахождение оптимального компромисса в зависимости от типа приложения и бизнес требований. (Чем меньше время жизни сессии тем безопаснее)
• Время жизни сессии в ASP.NET необходимо установить вручную
• Существует два варианта тайм-аута сессии Slide|Fixed. По возможности стоит отказаться от Sliding варианта расчета времени окончания сессии.