Чек-лист требований

Данный чек-лист можно использовать при работе над всеми проектами по разработке веб-приложений. Все перечисленные требования применимы к любому веб-приложению, и я предлагаю рассматривать их в качестве необходимого минимума, а также добавить те, которые соответствуют уникальным потребностям вашей организации.

Следует:

• шифровать все данные в состоянии покоя (пока они находятся в базе данных);

• шифровать все данные при передаче (на пути к пользователю, базе данных, API и т. д.);

• никому не доверять: проверять (при особых обстоятельствах санитизировать) все данные, даже из собственной базы данных;

• шифровать (и, если нужно, экранировать) все выходные значения;

• перед и регулярно после использования проверять все библиотеки и сторонние компоненты на наличие известных уязвимостей (так как постоянно появляются новые уязвимости и версии);

• использовать все подходящие заголовки безопасности;

• использовать необходимые безопасные параметры cookie;

• классифицировать и маркировать все хранимые, собираемые и создаваемые приложением данные;

• хешировать и солить все пароли пользователей. Соль должна состоять не менее чем из 28 символов;

• хранить все секреты приложения в тайнике;

• обеспечить повсеместное использование сервисных учетных записей (не личных аккаунтов) при работе внутри приложения;

• обеспечить использование менеджеров паролей всеми членами команды и запретить повторное использование паролей;

• избегать изменений паролей по расписанию или через определенный промежуток времени, кроме случаев взлома или подозрительной активности;

• разрешать доступ к интернет-сайтам общего пользования только через HTTPS. Перенаправлять с HTTP на HTTPS. Желательно применять это требование как к внутренним, так и к внешним приложениям;

• обеспечить использование последней версии TLS для шифрования (в настоящее время 1.3);

• никогда не использовать жесткое кодирование. Никогда;

• никогда не размещать конфиденциальную информацию (в том числе строки соединения и пароли) в комментариях, ее необходимо хранить в тайнике;

• использовать функции безопасности, встроенные в платформу. Например, криптографию и шифрование, функции управления сессиями или функции санитизации ввода. Не следует писать собственные функции, если платформа предоставляет свои;

• использовать только последнюю (или предыдущую) версию платформы и поддерживать ее в актуальном состоянии. Технический долг = долг безопасности;

• при загрузке файлов следовать рекомендациям OWASP: сканировать все загружаемые файлы с помощью бесплатного инструмента AssemblyLine, предоставляемого Канадским центром безопасности коммуникаций (Communications Security Establishment, CSE);

• обеспечить регистрацию всех ошибок (исключая конфиденциальную информацию) и включить оповещение о возникновении ошибок, связанных с обеспечением безопасности;

• обеспечить выполнение всех проверок ввода (и его санитизацию) на стороне сервера с использованием «белого списка» (не «черного списка»);

• обеспечить тестирование безопасности приложения перед релизом (подробнее об этом в следующих главах);

• перед релизом приложения выполнить моделирование угроз, речь о котором будет идти в главе 3 в разделе «Моделирование угроз»;

• выполнить проверку кода (в частности, функций безопасности) приложения перед релизом;

• убедиться в том, что приложение отлавливает все ошибки и производит аварийное завершение работы правильно (никогда не переходит в неизвестное состояние);

• обеспечить, чтобы все ошибки предоставляли пользователю только общую информацию, а не информацию из трассировки стека, ошибки запроса или другую технически специфическую информацию;

• определить специфику доступа на основе ролей в требованиях к проекту;

• определить конкретные методы аутентификации и системы идентификации в требованиях к проекту;

• использовать только параметризованные запросы и никогда – встраиваемые SQL/NоSQL;

• избегать передачи имеющих какое-либо значение переменных в параметрах URL;

• обеспечить соблюдение принципа наименьших привилегий в приложении, особенно в отношении доступа к базе данных и API;

• минимизировать поверхность атаки, когда это возможно;

• разрешить функции вырезать-вставить в поле пароля, что позволит пользователям применять менеджеры паролей. Отключить функции автозаполнения полей, чтобы пользователи не сохраняли свои пароли в браузере;

• отключить кэширование на страницах, содержащих конфиденциальную информацию. Заголовок Cache HTTP технически не является заголовком безопасности, однако он подходит для выполнения этого требования;

• убедиться, что пароли пользователей приложения длинные, но не обязательно сложные. Чем длиннее пароль, тем лучше. Следует также поощрять использование кодовых фраз;

• с помощью специальных сервисов проверять, не были ли новые пароли пользователей ранее взломаны.

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

Если разработчики с самого начала знают, что им необходимо придерживаться определенных требований, уровень безопасности создаваемого программного обеспечения вырастает.

Упражнения

• Назовите два дополнительных возможных требования безопасности для веб-приложения (не упомянутых в списке).

• Назовите два дополнительных возможных требования безопасности для операционной системы автомобиля.

• Назовите два дополнительных возможных требования безопасности для «умного тостера».

• Назовите два дополнительных возможных требования безопасности для приложения, работающего с кредитными картами.

• Какое требование безопасности является наиболее важным для вас или вашей организации? Почему?

• Если бы вам нужно было убрать одно из упомянутых в этой главе требований из проекта веб-приложения, какое бы это было требование? Почему?

ПРИМЕЧАНИЕ. Напоминаем, что раздел «Ответы» в конце книги не предоставляет полную информацию. Более подробные ответы на вопросы можно получить во время их обсуждения с коллегой или другом. Присоединяйтесь к моему сообществу, чтобы принять участие в онлайн-дискуссии, или посмотрите видео с обсуждениями на youtube.com/shehackspurple.