└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # Чек-лист по безопасности для веб-разработчика 2 | 3 | (Основано на https://www.powerdown.io/blog/posts/stories/web-developer-security-checklist.html) 4 | 5 | Разрабатывать безопасные, надёжные облачные веб-приложения сложно, очень сложно. Если вам кажется это лёгким делом, вы либо высшая форма материи, либо вас ждёт болезненное осознание в будущем. 6 | 7 | Если вы выпили быстрорастворимый MVP и считаете, что можете создать ценный и безопасный продукт за один месяц, подумайте дважды, прежде чем запускать этот «прото-продукт». 8 | 9 | После того, как вы посмотрите этот чеклист, примите во внимание, что вы игнорируете многие критические вопросы безопасности. По крайней мере, будьте честными с потенциальными пользователями и сообщите им, что у вас ещё нет полноценного продукта, и что прототип не безопасен на 100%. 10 | 11 | Список простой, и его нельзя считать завершённым. Я разрабатываю безопасные веб-приложения уже более 14 лет, и включил в список некоторые из наиболее важных задач, которые я мучительно опробовал на себе за этот период. Надеюсь, при создании веб-приложения вы серьёзно задумаетесь над этими вопросами. 12 | 13 | ## База данных 14 | 15 | [ ] Используйте шифрование конфиденциальных данных и данных, идентифицирующих пользователей, например токенов доступа, адресов электронной почты или деталей счетов. 16 | 17 | [ ] Если ваша база данных поддерживает экономичное шифрование в неактивном режиме (вроде AWS Aurora), включите его для защиты данных на диске. Убедитесь, что все резервные копии хранятся в зашифрованном виде. 18 | 19 | [ ] Используйте минимальные привилегии для использования аккаунта пользователя базой данных. Не используйте корневую учётную запись базы данных. 20 | 21 | [ ] Храните и группируйте секретные данные, используя хранилище ключей, например Vault или AWS Secret Manager. Не используйте жёстко закодированные секретные данные в своих приложениях и НИКОГДА не загружайте такие данные в репозиторий! 22 | 23 | [ ] Полностью избавьтесь от SQL-атак, используя только подготовленные SQL-инструкции. Например, если вы работаете с NPM, пользуйтесь не npm-mysql, а npm-mysql2, который поддерживает подготовленные инструкции. 24 | 25 | ## Разработка 26 | 27 | [ ] Проверьте, что все компоненты вашего софта протестированы на наличие уязвимостей для каждой версии, отправленной в продакшен. Сюда входят продукты с открытым исходным кодом, библиотеки и пакеты. Желательно автоматизировать это через CI-CD процесс. 28 | 29 | [ ] Относитесь к безопасности систем разработки приложений так же бдительно, как к безопасности систем в продакшене. Создавайте софт из защищённых, изолированных систем. 30 | 31 | [ ] Убедитесь, что в продакшене не попадают служебные/отладочные файлы и скрипты. 32 | 33 | ## Аутентификация 34 | 35 | [ ] Убедитесь, что все пароли хешируются с использованием соответствующего алгоритма, вроде bcrypt. Никогда не реализуйте собственное шифрование и корректно инициализируйте шифрование из случайных данных. 36 | 37 | [ ] Реализуйте простые, но адекватные правила создания паролей, которые побуждают пользователей придумывать длинные случайные пароли. 38 | 39 | [ ] Используйте многофакторную аутентификацию для всех своих провайдеров. 40 | 41 | ## Защита от DOS-атак (Denial of Service) 42 | 43 | [ ] Проверяйте, что DOS-атаки на API не вредят вашему сайту. Как минимум используйте ограничители скорости на более медленных методах API в таких типичных функциях, как вход и генерация токена. 44 | 45 | [ ] Создайте лимиты для размеров и структуры запросов для данных, предоставляемых пользователями. 46 | 47 | [ ] Снизьте риск хакерской атаки, минимизировав последствия DDoS-атаки (Distributed Denial of Service), используйте для этого глобальный кеширующий прокси-сервер вроде CloudFlare. Его можно включить при активной DDoS-атаке, а в остальных случаях использовать лишь для DNS. 48 | 49 | ## Веб-трафик 50 | 51 | [ ] Используйте TLS для всего сайта, а не только для формы входа и ответов сервера. Никогда не используйте TLS только для формы входа. 52 | 53 | [ ] Файлы cookie должны быть с флагом httpOnly, защищены и находиться в области видимости пути и домена. 54 | 55 | [ ] Используйте [CSP](https://en.wikipedia.org/wiki/Content_Security_Policy), не допуская небезопасные бэкдоры. Настраивается это через боль, но оно того стоит. 56 | 57 | [ ] Используйте заголовки X-Frame-Option и X-XSS-Protection в ответах клиентам. 58 | 59 | [ ] Используйте HSTS-ответы, чтобы форсировать доступ только через TLS. Для подстраховки перенаправляйте на сервере все HTTP-запросы на HTTPS. 60 | 61 | [ ] Используйте CSRF-токены во всех формах и используйте новый заголовок ответа [SameSite Cookie](https://scotthelme.co.uk/csrf-is-dead/), который раз и навсегда исправляет CSRF для всех новых браузеров. 62 | 63 | ## API 64 | 65 | [ ] Проверьте, что в открытых API нет ресурсов с последовательными численными идентификаторами. 66 | 67 | [ ] Проверьте, что пользователи полноценно аутентифицированы и авторизованы, когда используют ваши API. 68 | 69 | [ ] Используйте канареечные проверки в API, чтобы обнаруживать незаконные или аномальные запросы, которые указывают на атаку. 70 | 71 | ## Валидация 72 | 73 | [ ] Валидируйте информацию на клиенте, чтобы пользователь получал быструю обратную связь, но всегда делайте повторную валидацию на бэкенде. 74 | 75 | [ ] Валидируйте любую (без исключения) информацию на сервере, вводимую пользователем, используя белые списки. Никогда напрямую не вставляйте данные, полученные от пользователя в ответы. Никогда не используйте вводимую пользователем информацию в SQL-инструкциях. 76 | 77 | ## Облачная конфигурация 78 | 79 | [ ] Проверьте, что у всех служб открыто минимальное количество портов. Хоть безопасность через неясность — это не защита, использование нестандартных портов усложнит задачу взломщикам. 80 | 81 | [ ] Храните бэкенд-базу данных и сервисы в приватных VPC (виртуальном частном облаке), которые не видны ни в какой открытой сети. Будьте очень осторожными, когда настраиваете группы безопасности AWS (Амазон) и пирингуете VPC, что может случайно превратить сервисы в открытые. 82 | 83 | [ ] Изолируйте логические службы в отдельные VPC и одноранговые VPC для межсервисной связи. 84 | 85 | [ ] Проверьте, что все службы принимают данные с минимального набора IP-адресов. 86 | 87 | [ ] Ограничьте исходящий IP-трафик и трафик портов для минимизации APT (Advanced Persistent Threat) и бот-атак. 88 | 89 | [ ] Всегда используйте AWS IAM (Identity and Access Management) пользователей и роли, а не учётные данные корневого каталога. Изучите, как эффективней пользоваться IAM. 90 | 91 | [ ] Используйте минимальную привилегию доступа для всех сотрудников и разработчиков. Давайте IAM пользователям и ролям минимальные возможности, необходимые для выполнения задачи. 92 | 93 | [ ] Регулярно чередуйте пароли и ключи доступа, используйте расписание. 94 | 95 | ## Инфраструктура 96 | 97 | [ ] Удостоверьтесь, что можете делать обновления без простоя. Убедитесь, что можете быстро обновлять приложения целиком автоматически. 98 | 99 | [ ] Стройте всю инфраструктуру с помощью инструмента, подобного Terraform, а не через облачную консоль. Инфраструктура должна определяться как «код» и воссоздаваться одним нажатием кнопки. Возьмите за правило никогда не создавать ничего в облаке вручную — Terraform может проверить вашу конфигурацию. 100 | 101 | [ ] Используйте централизованную систему логирования для всех сервисов. Вам никогда не должен понадобиться SSH для доступа к логам. 102 | 103 | [ ] Не подключайтесь по SSH к сервисам, кроме случаев, когда необходима единоразовая диагностика. Регулярное использование SSH чаще всего означает, что вы не автоматизировали важную задачу. 104 | 105 | [ ] Не оставляйте порт 22 постоянно открытым в любых группах служб AWS. 106 | 107 | [ ] Создавайте [неизменяемые хосты](http://chadfowler.com/2013/06/23/immutable-deployments.html), вместо серверов с длительным сроком службы, которые нужно модифицировать и обновлять. (см. [Immutable Infrastructure Can Be More Secure](https://www.powerdown.io/blog/posts/immutable-infrastructure-can-be-dramatically-more-secure.html)). 108 | 109 | [ ] Используйте систему обнаружения вторжений (Intrusion Detection System) для минимизации APT. 110 | 111 | ## Функционирование 112 | 113 | [ ] Выключайте неиспользуемые сервисы и серверы. Самый безопасный сервер — отключенный сервер. С помощью инструментов вроде PowerDown такому процессу можно задать расписание. 114 | 115 | ## Тестирование 116 | 117 | [ ] Регулярно проверяйте свой дизайн и реализацию. 118 | 119 | [ ] Проведите испытание на взлом (penetration testing) — хакните себя, и попросите кого-нибудь хакнуть вас. 120 | 121 | ## И, наконец, планирование 122 | 123 | [ ] У вас должна быть модель угрозы, описывающая от чего вы защищаетесь. В ней список и приоритеты возможных угроз и злоумышленников. 124 | 125 | [ ] Держите опробованный на деле план на случай нарушения безопасности. Однажды он вам понадобится. 126 | --------------------------------------------------------------------------------