Каждый год в мире происходит все больше хакерских атак: от краж кредитных карт до взломов сайтов онлайн-магазинов. Уверены, что ваши скрипты по настоящему защищены? В преддверии старта курса «Backend-разработчик на PHP» наш коллега подготовил интересную публикацию на тему безопасности в PHP...
Введение
Скандал с Facebook и Cambridge Analytica, утечка переписки Демократической партии США в 2016 году, нарушение безопасности данных Google в 2018 году, взлом Yahoo Voice в 2012 году — вот лишь несколько примеров крупных утечек, зафиксированных за последние несколько лет.
Информация в глобальном масштабе сегодня доступна для нас, как никогда ранее. Если не проявлять должную осторожность, информация о нас самих (в том числе сведения конфиденциального характера) тоже могут попасть в открытый доступ.
Неважно, разработкой какого именно проекта вы занимаетесь: детской игрой с открытым кодом или выполняете заказ крупного предприятия. Ваша обязанность как веб-разработчика состоит в том, чтобы обеспечить безопасность всем своим платформам. Безопасность — это очень непростой аспект.
Язык РНР предоставляет несколько инструментов и функций, которые можно задействовать для обеспечения безопасности приложения.
3 правила безопасности паролей
Пароли пользователей должны оставаться неизвестными для вас.
Я до сих пор вспоминаю свои первые шаги в роли РНР-разработчика. Первым созданным мной приложением стала игра, где я вместе с друзьями играл роль строителя небоскрёбов. Каждый из нас мог залогиниться в свой аккаунт, купить строителей и каждую неделю отправлять свою бригаду на новую стройку. Я создал базовые аккаунты: добавил для каждого пользователя логин и пароль и отправил их им по е-мейлу. И только через пару месяцев я понял, насколько это было глупо.
Общее правило таково: вы не только не должны знать пароли своих пользователей — у вас не должно быть возможности узнать их. Это очень серьезный аспект, который может повлечь даже юридическую ответственность.
Методом проб и ошибок вы все равно придете к выводу, что пароли не надо хранить в формате обычного текста или в таком виде, чтобы они легко поддались расшифровке.
Не вводите ограничения на пароли
Давайте сыграем в одну игру. Попробуйте угадать пароль:
**********
Сложно, правда? Давайте попробуем так:
P*r***e***
Теперь вы знаете, что здесь есть заглавная буква и несколько прописных. А если вот так:
P*r***e911
Теперь вам будет намного легче угадать пароль — ведь вы знаете, что он включает в себя заглавную букву, прописные буквы и число.
То же самое происходит в тех случаях, когда вы навязываете пользователям ограничения и маски для их паролей. Если в вашем приложении заложено требование следовать определенному шаблону, вы даете злоумышленникам намеки, которые они могут использовать против вас.
Требовать некую минимальную длину пароля — это нормально, так как длина пароля влияет на то время, которое требуется, чтобы подобрать его. Однако вместо этого будет намного полезнее узнать, как работают алгоритмы и хеширование.
Кстати, правильный ответ к приведенной выше загадке — «Porsche911» :)
Никогда не отправляйте пароли по е-мейлу в чистом виде
Одной из моих первых ошибок в роли веб-разработчика стало то, что я заблаговременно не научился управлять паролями.
Представьте, что вы клиент и вы нанимаете разработчика, чтобы он создал для вашего бизнеса симпатичный сайт электронной коммерции. Этот разработчик прислал вам е-мейл, который содержит пароль для вашего сайта. Теперь вам известно три вещи о вашем сотруднике:
- Он знает ваш пароль.
- Он хранит ваш пароль в чистом виде, не используя никакого шифрования.
- Он не испытывает ни малейшего беспокойства при пересылке паролей через интернет.
В ответ ничего не остаётся, как уволить такого сотрудника.
А вот как должен поступить веб-разработчик:
- Создайте в вашем веб-приложении страницу, куда пользователь сможет ввести свой е-мейл в случае, если он забыл пароль, и таким образом запросить новый пароль.
- Ваше приложение сгенерирует уникальные права доступа и привяжет его к пользователю, сделавшему запрос (лично я пользуюсь универсальным индивидуальным идентификатором).
- Приложение отправит пользователю е-мейл со ссылкой, ведущей к праву доступа.
Как только пользователь перейдет по ссылке, приложение подтвердит правильность доступа и даст пользователю возможность поменять пароль.
Видите, насколько возросла безопасность приложения благодаря этим простым шагам? При желании, мы можем повысить уровень безопасности еще больше, добавив лимит времени между запросом и установлением нового пароля.
Как хешировать пароли пользователей
Пароли в веб-приложении нужно хешировать, а не зашифровывать. Шифрование — это двухсторонний алгоритм. Шифровке подвергается последовательность, которую вы затем можете расшифровать и использовать повторно. Этот метод часто используется в разведке для получения информации от союзников.
Хеширование предполагает, что последовательность нельзя вернуть в формат незашифрованного текста. Именно это конечная цель всего процесса.
Для достижения разных целей разработано множество алгоритмов: одни отличаются высокой скоростью, другие высокой надежностью. Эта технология постоянно эволюционирует, и за последние несколько лет претерпела немало изменений. Сейчас мы рассмотрим три наиболее популярные ее разновидности в хронологическом порядке.
SHA-1
Это была исторически первая функция хеширования. Аббревиатура SHA-1 расшифровывается как «безопасный алгоритм хеширования», разработало его Агентство национальной безопасности США.
SHA-1 был хорошо известен и широко востребован в сфере РНР для создания 20-байтовой шестнадцатеричной строки длиной в 40 символов.
SSL-индустрия в течение нескольких лет пользовалась SHA-1 для цифровых подписей. Затем, после выявления некоторых слабых мест, в Google решили, что пора переходить на SHA-2.
Первая версия алгоритма была признана устаревшей в 2005 году. Впоследствии были разработаны и приняты к использованию новые версии: SHA-2, SHA-2 и SHA-256.
Bcrypt
Bcrypt, не являясь результатом естественного развития SHA, сумел привлечь к себе широкую аудиторию благодаря своему уровню безопасности.
Этот крайне медленный алгоритм был создан с целью создания максимально безопасных хешированных последовательностей. В процессе хеширования данных он проходит несколько циклов, что в вычислительной технике описывается показателем трудозатрат. Чем выше показатель трудозатрат, тем дороже будет для хакера заполучить пароль.
Есть и хорошая новость: в будущем мы сможем использовать более мощные машины, способные на более скоростное прохождение большего количества циклов.
Argon2
Это новый модный алгоритм в сфере хеширования, разработанный Алексом Бирюковым, Даниэлем Дину и Дмитрием Ховратовичем из Люксембургского университета. В 2015 году он стал победителем Конкурса хеширования паролей.
Argon2 представлен в 3 версиях:
- Argon2d обращается к массиву памяти, что сокращает издержки памяти и времени. Однако у него существует риск атаки по сторонним каналам.
- Argon2i является противоположностью Argon 2d. Он оптимизирован относительно атак по сторонним каналам и получает доступ к памяти в порядке, не зависящем от пароля.
- Argon2id представляет собой промежуточный вариант между двумя предыдущими версиями.
Эта функция насчитывает 6 параметров: последовательность пароля, salt, memory cost, time cost, фактор параллелизма (максимальное разрешенное число параллельных потоков), длина хеша.
Во второй части статьи я расскажу, как использовать это хеширование в РНР, задействуя встроенные функции, а сейчас хочу пригласить всех на бесплатный онлайн вебинар «ServerLess PHP», в рамках которого мы познакомимся с концепцией Serverless, поговорим о её реализации в AWS, применимости, ценах. Разберём принципы сборки и запуска, а также построим простой TG-бот на базе AWS Lambda.
Автор: MaxRokatansky
