Пастор секты свидетелей Xiaomi, любитель металла, футбола, рыбалки, истории. Почти инженер и историк по образованию, шут по призванию, чудак по жизни

Общие проблемы безопасности в веб-приложениях

Привет, друзья. Сегодня я хочу поговорить о некоторых общих проблемах безопасности в современных веб-приложениях и о лучших методах их устранения. Я надеюсь, что эта статья поможет разработчикам понять простые проблемы, которые появляются в 80-85% приложений.

Давайте обсудим некоторые уязвимости…

Хэширование паролей

Многие люди используют MD5, SHA512 для хэширования паролей. Больше не делайте этого! Они считаются устаревшими уже в течение длительного времени. Вы можете подумать, что они не лучший выбор из-за их криптографической слабости, но это не так. Основная причина в том, что это быстро, так как при брутфорс-атаке миллионы паролей могут быть опробованы на одном графическом процессоре.

Я взломал пару веб-сайтов, которые использовали эти алгоритмы. С машинным обучением и статистикой я составил список наиболее возможных паролей для пользователя, и потребовалось несколько минут, чтобы взломать некоторые учетные записи пользователей. У большинства из них были очень простые пароли, обычно люди не удосужились придумать хороший пароль для простых веб-сайтов, таких как форумы или блоги. PS: Не повторяйте это дома!

Правильное решение (оно не единственное) – использовать BCrypt для хранения паролей пользователей, которые являются адаптивной хэш-функцией на основе криптографического алгоритма симметричного блочного шифрования Blowfish. BCrypt также вводит коэффициент работы, значение которого определяет, насколько медленной будет хеш-функция. Более высокие значения для коэффициента работы будут занимать больше времени и будут генерировать разные значения хэша, что делает его чрезвычайно устойчивым к брутфорс-атакам.

Вы хотите использовать хэш-пароли, потому что, когда кто-то получает доступ к базе данных приложений, они не смогут восстановить исходные версии паролей (если они хэшируются должным образом). Но почему вы всегда должны хэшировать пароли в фоновом режиме (back-end), а не в интерфейсе (front-end)? В любом случае хэшированные пароли хранятся в базе данных, не так ли?!

Нет! Хэшируйте пароли только в фоновом режиме, и этому есть разумное объяснение. Если вы используете хеширование паролей в фоновом режиме, злоумышленники должны сначала взломать (вернуть в исходную версию) их, чтобы использовать на вашем веб-сайте. Но если вы их используете в интерфейсе, злоумышленникам не нужно делать это. Они могут просто передать хэш, поскольку он хранится в базе данных.

XSS

Люди, которые используют jQuery или Vanilla JavaScript, наверняка столкнутся с этой проблемой, поскольку не существует реализованных механизмов предотвращения XSS. Даже если есть, это не то, что нам действительно нужно. В этом примере,

вставка данных с помощью innerHTML может вызвать серьезные проблемы, поскольку responseText из back-end может быть чем-то вроде этого.

В итоге чей-то JavaScript-код начнет работать в вашем браузере.

Такая же история с функциями jQuery html () и append (). Они санируют теги сценариев, но все же, куча других тегов может справиться с этой задачей.

Но если вы используете Angular, React и т. д., вы можете быть уверены, что защищены от атак XSS, если не отключите функции безопасности, что настоятельно НЕ рекомендуется.

;

Вот как вам следует избегать обхода React для предотвращения атак XSS. Согласитесь, не выглядит надежным.

Обработка сеансов

В большинстве случаев после начала сеанса вы создаете идентификатор сеанса (это может быть сделано с помощью lib) и храните его в cookie браузера для обработки аутентифицированных пользователей для каждого вызова ajax. Всегда будьте осторожны с этими моментами:

  • Cookie должен иметь установленный флаг «httponly», так что JavaScript злоумышленника не может иметь доступ к идентификатору сеанса.
  • Идентификатор сеанса не должен быть именем пользователя, идентификатором пользователя или чем-то вроде этого. Это должна быть случайная и уникальная строка, которую практически невозможно угадать. Не используйте Math.random () или что-то в этом роде, так как это криптографически небезопасно. И, честно говоря, это даже не слишком случайно. Вы можете использовать «uuid/v5». Кажется, это работает очень хорошо.
  • Сеанс не должен иметь большую продолжительность. Не нужно, чтобы идентификатор сеанса оставался в кэше веб-клиента в течение длительного периода времени. Ведь оттуда злоумышленник может его получить.
  • Сессии должны быть уничтожены после некоторого времени бездействия пользователя.

Перевод материала с https://codeburst.io