Йо Йо, ребята.
Сегодня я хочу поговорить о некоторых распространенных проблемах безопасности в современных веб-приложениях и о лучших методах их устранения. Я надеюсь, что эта статья поможет разработчикам понять некоторые проблемы, которые встречаются в 80–85% приложений.
Давайте обсудим некоторые возможные уязвимости ...
Хеширование паролей
Многие люди используют MD5, SHA512 для хеширования паролей. Не делай этого больше никогда! Они долгое время считались устаревшими. Что ж, вы можете подумать, что они не лучший выбор из-за их криптографической слабости, но это не так. Основная причина в том, что это быстро, что означает, что во время атак грубой силы миллионы паролей могут быть перепробованы на одном графическом процессоре.
Я взломал несколько сайтов, на которых использовались такие алгоритмы. С помощью машинного обучения и статистики я составил список наиболее возможных паролей для пользователя, и взломать учетные записи некоторых пользователей потребовалось несколько минут. У большинства из них были очень простые пароли, обычно люди не думают о хорошем пароле для простых сайтов, таких как форумы или блоги.
P.S. Не пытайтесь делать это дома !! :)
Правильным решением (и не единственным) является использование BCrypt для хранения паролей пользователей, который представляет собой адаптивную хеш-функцию, основанную на криптографическом алгоритме симметричного блочного шифра Blowfish. BCrypt также вводит коэффициент работы, значение которого определяет, насколько медленной будет хеш-функция. Более высокие значения коэффициента работы потребуют больше времени и будут генерировать другие хеш-значения, что делает его чрезвычайно устойчивым к атакам грубой силы.
Вы хотите хешировать пароли, потому что, когда кто-то получит доступ к базе данных приложения, он не сможет восстановить исходные версии паролей (если они хешированы правильно).
Но почему вы всегда должны хешировать пароли в серверной части, а не во внешней? В любом случае в базе данных хранятся HASHED пароли, не так ли?!?!
НЕТ! Хешируйте пароли только в серверной части, и этому есть разумное объяснение. Если вы хешируете пароли в серверной части, злоумышленник должен сначала взломать (вернуть исходную версию) их, чтобы использовать на вашем веб-сайте, но если вы хешируете их во внешнем интерфейсе, злоумышленнику не нужно сделать это, они могут просто передать хеш, хранящийся в базе данных.
XSS
Люди, использующие jQuery или ванильный JavaScript, наверняка столкнутся с этой проблемой, поскольку отсутствуют реализованные механизмы предотвращения XSS. Даже если они есть, это не то, что нам нужно. В этом примере
вставка данных с помощью innerHTML может вызвать серьезные проблемы, поскольку responseText из серверной части может быть примерно таким.
<img onerror=”alert(‘Yo Yo, I am about to do something bad’)” src=”NotAProperUrlhere”>
И чей-то код JavaScript начнет работать в вашем браузере.
Та же история с функциями jQuery html () и append (). Эти теги дезинфицируют теги сценария, но, тем не менее, множество других тегов могут сделать эту работу.
Но если вы используете Angular, React и т. Д., Вы можете быть уверены, что защищены от XSS-атак, если не отключите функции безопасности, что настоятельно НЕ рекомендуется.
<div dangerouslySetInnerHTML={createMarkup()} />;
Вот как вы должны обойти правила React для предотвращения XSS-атак. Выглядит ненадежно, а?)
Обработка сеанса
В большинстве случаев после запуска сеанса вы генерируете идентификатор сеанса (это можно сделать с помощью библиотеки) и сохраняете его в cookie браузера для обработки аутентифицированных пользователей для каждого вызова ajax. Всегда будьте осторожны с этими моментами:
- Для файла cookie ДОЛЖЕН быть установлен флаг «httpONLY», чтобы JavaScript злоумышленника не мог получить доступ к идентификатору сеанса.
- Идентификатор сеанса не должен быть именем пользователя, идентификатором пользователя или чем-то в этом роде. Это должна быть случайная и уникальная строка, которую практически невозможно угадать. Не используйте Math.random () или что-то подобное, так как это не криптографически безопасно. И, честно говоря, это даже не случайно :) Вы можете использовать uuid / v5. Кажется, это действительно хорошо работает.
- У сеанса не должно быть длительного времени жизни, чтобы идентификатор сеанса не оставался в кеше веб-клиента в течение длительного периода времени, откуда злоумышленник может его получить.
- Сессии должны быть уничтожены после некоторого времени бездействия пользователя.
Спасибо за прочтение. Продолжение следует…