От переводчика: публикуем для вас статью Джима Медлока, программиста и архитектора ПО. Медлок рассказывает об основных способах защиты своего приложения или веб-сервиса. Стоит отметить, что этот материал, скорее всего, будет полезен начинающим программистам. Хотя если профи оставят свои комментарии — все будут благодарны.
Зачем вообще беспокоиться о том, что кто-то взломает приложение? Да хотя бы потому, что желающих заниматься этим с течением времени становится все больше. Это «обычные» хакеры, для которых преодоление чьей-то защиты представляет спортивный интерес, киберпреступники, которые ломают сервисы и сайты с целью наживы, правительственные организации.
За последние несколько месяцев многие крупные организации попали в новости после гигантских утечек информации. Среди них Facebook и его 50 млн украденных аккаунтов, FIFA с 3,4 ТБ данных и 70 млн документов, Google с 0,5 млн аккаунтов, Marriott Hotels с данными 427 млн клиентов всей сети.
Skillbox рекомендует: Двухлетний практический курс «Я – веб-разработчик PRO».
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Источник
Растет не только количество хакерских атак, но и объем ущерба, который наносят киберпреступники. По мнению специалистов, средний размер прямых и косвенных убытков, причина которых — киберпреступники, составляет $3,86 млн из расчета на один успешный взлом. Конечно, это в среднем по рынку; реальные цифры варьируются, и довольно сильно.
Еще немного статистики. Об ущербе, наносимом киберпреступниками, можно судить и по таким данным:
- $148 — «цена» одной украденной учетной записи;
- $40 млн — для 1 млн учетных записей;
- $350 млн — для 50 млн учетных записей.
Деньги — не единственный аргумент: подумайте и о том, сколько времени понадобится, чтобы привести все в порядок.
Инфраструктурная безопасность vs. безопасность приложения
Большинство мер безопасности направлены на защиту основы IT-инфраструктуры, вроде сервера, хранилища, дата-центра. Это необходимо, но защищать нужно не только их.
Меры безопасности в отношении самого приложения тоже крайне важны. Они предусматривают целый набор методов поиска, исправления и предотвращения злонамеренного использования лазеек в вашем ПО. Стоит выделить эти:
- ревью кода, выполняемое специалистами по информационной безопасности, когда цель — исключительно поиск проблемных с точки зрения кибербезопасности мест;
- аудит в формате Blackbox, основанный на работе с приложением;
- ревью архитектуры приложения перед написанием основной массы кода;
- использование автоматических инструментов, которые помогают оценить защиту;
- запуск баунти-программ, которые позволяют сторонним специалистам найти проблемные места.
Наиболее эффективные меры базируются на концепте послойной безопасности. В этом случае для каждого из защищаемых элементов используется собственный набор инструментов.
Вы ничего не можете поделать с client-side
Проблема в том, что вы вряд ли сможете защитить свой проект на стороне пользователя. Современные браузеры уязвимы, несмотря на все старания их создателей.
В случае веб-сервисов слабым компонентом всей системы является ключ, необходимый для авторизации. Например, приложения, которая используют GitHub API, должны поддерживать работу с токеном для аутентификации. Если преступник сможет заполучить ключ в свои руки, то у него будет и весь доступ к коду и проектам жертвы на GitHub.
Для frontend-разработчика опасность состоит в том, что он бывает уверен в полной безопасности своего сервиса, если предусмотрены такие меры, как частные ключи и токены. Все это хорошо, но всё те же браузеры — слабое звено.
Насколько безопасно отделять защитные данные вроде ключей от всего проекта в целом?
Обычно переменные окружения используются для выделения данных в файл, например .env. Дополнительный шаг — добавление имени таких файлов к .gitignore, что предотвращает выполнение команд git push для загрузки в публичные репозитории, где файл будет открыт всем.
Все это хорошо, но .env-файлы не шифруются. В случае Create React App их можно проверить при помощи опции Developer Tools в браузере, в директории build/static/js. Вот, например, что мы обнаружим при обследовании 0.chunk.js.
Как видите, особых преимуществ такой подход не дает, в некоторых случаях хранить важные элементы безопасности лучше в исходном коде. Есть еще один привлекательный сценарий, когда разделение кода используется для отсрочки загрузки скриптов, содержащих переменные среды, до момента аутентификации пользователя приложением. Но если клиентский компьютер скомпрометирован, ничего не получится — ведь его файловая система доступна злоумышленникам.
Решение
В отличие от клиентской части, серверные приложения могут быть защищены так, чтобы важные данные не попали в руки злоумышленников. Для этого вам пригодится использование Oauth для получения дополнительного уровня аутентификации и контроля доступа, шифрования и протоколов вроде HTTPS и TLS.
Дилемму о защите секретов приложений можно решить благодаря реализации API-интерфейса на стороне сервера. Он одновременно выступает в качестве прокси-сервера для изоляции клиентского приложения от поставщиков услуг, которых он же и использует. Вместо того чтобы использовать закрытые данные на стороне клиента для аутентификации его в службе, API аутентифицируется от серверного приложения, выполняет запросы и лишь затем возвращает результаты клиенту. Последнему закрытые ключи или другие данные не раскрываются ни при каких обстоятельствах.
Комплексный подход
Да, комплексность — это не просто слова. Для того чтобы предоставить пользователям уверенность в надежной защите их данных, нужно тщательное планирование, продуманная стратегия безопасности, которая основана на глубокой защите и внимании к деталям.
Вовсе не достаточно полагаться на «островки технологий». Необходимо связывать все элементы воедино, понимая то, как будет работать вся система.
Только в этом случае приложение или сервис будут в безопасности.
- Онлайн-курс «Профессия frontend-разработчик».
- Практический годовой курс «PHP-разработчик с 0 до PRO».
- Онлайн-курс Профессия «Веб-разработчик».