Что стоит знать и заказчику сайта — используем «Руководство по созданию безопасного веб-сайта» IPA как чек-лист

На вопрос «а с безопасностью нашего сайта всё в порядке?» немногие компании могут ответить «да» с реальными основаниями.

Легко считать, что раз этим занимается студия-разработчик — значит, всё хорошо, или что сайт-визитка никого не заинтересует, но одна-единственная форма обратной связи означает, что работает программа обработки введённых данных, а если используется CMS вроде WordPress, атаке подвержены и панель администратора, и каждый плагин. Более того, большинство атак не нацелены на конкретную компанию — злоумышленники механически ищут слабые сайты.

Так по какому критерию проверять, что «всё в порядке»? Публичный документ, который давно играет роль такого критерия, — это «Руководство по созданию безопасного веб-сайта» IPA (Агентства по продвижению информационных технологий).

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

1. Сначала вывод

• «Руководство по созданию безопасного веб-сайта» — документ, построенный на реально поступивших в IPA сведениях об уязвимостях, объединяющий 11 категорий слабых мест сайта и меры противодействия. Он полезен не только разработчикам, но и как критерий при заказе и приёмке
• Меры делятся на «принципиальное решение» (устраняет причину) и «подстраховочную меру» (снижает ущерб). Основа — принципиальное решение, подстраховочные меры добавляются сверху
• Прилагаемый «Чек-лист реализации безопасности» можно использовать напрямую как пункты проверки при заказе у студии-разработчика и при приёмке
• Отдельное приложение «Спецификация диагностики здоровья веб-сайта» служит ориентиром для набора диагностических пунктов при периодической проверке уже работающего сайта
• На практике для корпоративного сайта два основных очага риска — участки, принимающие ввод (например, формы), и эксплуатация CMS (например, WordPress). При заказе стоит заранее договориться о системе эксплуатации, чтобы проект не заканчивался в момент запуска сайта

2. Что такое «Руководство по созданию безопасного веб-сайта»

«Руководство по созданию безопасного веб-сайта» — документ, который IPA составила для разработчиков и операторов веб-сайтов, рассматривая уязвимости, которые часто заявлялись или несут большой ущерб при атаке, вместе с мерами противодействия. Актуальная версия — 7-я пересмотренная редакция, опубликованная в марте 2021 года, объёмом 115 страниц целиком. Помимо PDF, публикуются и отдельные HTML-страницы по каждой уязвимости.

Структура состоит из трёх глав.

Помимо основного тома, отдельно публикуются следующие материалы:

• Чек-лист реализации безопасности (в формате Excel): перечень для проверки, реализованы ли меры из основного тома
• Отдельное приложение «Как безопасно вызывать SQL»: углублённый разбор мер против уязвимостей, связанных с базой данных
• Отдельное приложение «Спецификация диагностики здоровья веб-сайта»: спецификация из 13 диагностических пунктов для проверки работающего сайта

Все материалы можно бесплатно скачать со страницы IPA.

3. Читаем 11 уязвимостей через призму «что произойдёт»

11 категорий уязвимостей из главы 1 изложены терминами, ориентированными на разработчика, но если перевести их в формулировку «что произойдёт на собственном сайте при бездействии», становится ясно, что это касается и заказчика напрямую.

Например, «инъекция заголовков почты» напрямую касается формы обратной связи на обычном сайте-визитке. Слабо защищённая форма используется как источник спама, что вредит даже репутации домена компании (будут ли доходить письма адресату). Как разобрано в статье «Почему не доходят письма из формы обратной связи», форма, письма из которой перестают доходить, напрямую означает упущенные бизнес-возможности.

4. «Принципиальное решение» и «подстраховочная мера» — подход к мерам противодействия

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

• Принципиальное решение: реализация, устраняющая саму причину уязвимости. Например, для SQL-инъекции — построение SQL-запроса через плейсхолдеры, а не через конкатенацию строк
• Подстраховочная мера: мера, снижающая вероятность успеха атаки или ущерб, если уязвимость всё же осталась. Например, не выводить исходный текст ошибки прямо в браузер

Это разделение даёт заказчику ориентир при выслушивании объяснений по безопасности. Объяснение вроде «мы ставим WAF (механизм, обнаруживающий и блокирующий атаки), так что можно быть спокойным» — это разговор о подстраховочной мере, и она не заменяет принципиальное решение в самом приложении. И наоборот, реализовать принципиальное решение и дополнительно поставить WAF — вполне разумная конфигурация. Просто различая, о каком слое идёт речь, вы уже сильно лучше сможете оценить обоснованность предложения.

5. Как использовать при заказе и приёмке

«Руководство по созданию безопасного веб-сайта» написано для разработчиков, но практическая ценность для заказчика в том, что его можно использовать как критерий требований и проверки.

• На этапе оценки стоимости/требований: добавьте в техническое задание или RFP формулировку «реализовать меры против уязвимостей, перечисленных в „Руководстве по созданию безопасного веб-сайта“ IPA». Указание конкретного стандарта делает требование намного конкретнее расплывчатой фразы «уделить внимание безопасности»
• На этапе приёмки: запросите результаты проверки по соответствующим пунктам чек-листа реализации безопасности
• На этапе договора: письменно закрепите, кто после публикации будет обновлять CMS, плагины и сервер, и входит ли реагирование на вновь обнаруженную уязвимость в договор на сопровождение или требует отдельной оценки

Третий пункт особенно важен. Безопасность сайта не завершается в момент его создания — она поддерживается отслеживанием новых уязвимостей, обнаруживаемых после публикации. Вопрос «кто продолжает следить за этим» — та же структура, что и вопрос об объёме сопровождения, разобранный в статье о договорах на заказную разработку и сопровождение.

6. Проводите «диагностику здоровья» для работающего сайта

Для уже опубликованного сайта полезно отдельное приложение «Спецификация диагностики здоровья веб-сайта». Это спецификация диагностических пунктов (всего 13) для проверки безопасности работающего сайта, которая также служит ориентиром объёма при использовании сервиса диагностики уязвимостей.

Для корпоративного сайта малого и среднего бизнеса на практике риск особенно часто концентрируется в двух местах:

• Участки, принимающие ввод: формы обратной связи, поля поиска, вход участников и т. п. Большинство уязвимостей из главы 1 связаны именно с этим
• Эксплуатация CMS: сайт, на котором остановлено обновление ядра, темы или плагинов CMS вроде WordPress, — классический паттерн подделки через эксплуатацию известной слабости. Крайне часто встречается ситуация, когда так и не решено, чья это обязанность — обновления, — и сайт просто оставляют как есть

Если хочется пересмотреть нагрузку по обновлению CMS вместе со всей системой эксплуатации, полезна и статья про миграцию с WordPress. Существует и проектное решение сократить поверхность атаки саму по себе, вообще уменьшив динамическую обработку в пользу статической структуры сайта. Использование нашей компанией статической структуры на основе дизайн-системы Цифрового агентства при создании сайтов — продолжение той же логики.

Отметим, что безопасная эксплуатация веб-сайта также указана как пункт проверки в самопроверке 4-й редакции «Руководства по мерам информационной безопасности для малого и среднего бизнеса» IPA. О месте этого пункта в общей системе мер безопасности компании — в статье о редакции 4.0 руководства.

Итог

Соберём ключевые моменты «Руководства по созданию безопасного веб-сайта» IPA.

• Документ-стандарт (7-я пересмотренная редакция, 115 страниц), охватывающий 11 категорий слабых мест сайта и меры противодействия, построенный на реально поступивших в IPA сведениях об уязвимостях
• Меры делятся на два слоя: принципиальные решения и подстраховочные меры. Подстраховочная мера вроде WAF не заменяет принципиальное решение
• Заказчик может использовать документ, указав его название в требованиях, проверив приёмку по чек-листу и закрепив в договоре систему обновления после публикации
• Работающий сайт стоит периодически проверять по ориентиру «Спецификации диагностики здоровья веб-сайта»
• Реальный риск корпоративного сайта чаще всего концентрируется в обработке ввода вроде форм и в заброшенной CMS

Безопасность легко превращается в выбор между «тратить деньги, как скажет специалист» и «не делать ничего», но знание публичного стандарта уже позволяет формулировать требования и проверять результаты собственными словами.

Тем, кто планирует создание или переработку сайта

При создании или переработке сайта KomuraSoft LLC предлагает решения в духе подхода, разобранного в этой статье: от реализации формы до статической структуры, не слишком зависящей от CMS, вплоть до системы обновления после публикации. Мы рады консультации и на этапе проверки текущего состояния для тех, кто не до конца понимает, в каком состоянии находится их нынешний сайт.

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Что за документ «Руководство по созданию безопасного веб-сайта»?

Это документ по безопасности для разработчиков и операторов веб-сайтов, который публикует IPA (Агентство по продвижению информационных технологий). Среди информации об уязвимостях, поступившей в IPA, документ рассматривает наиболее часто заявляемые или наиболее опасные по последствиям случаи, разбирая угрозы и меры противодействия. Актуальная 7-я пересмотренная редакция опубликована в марте 2021 года, объём — 115 страниц. Помимо основного текста бесплатно публикуются чек-лист реализации безопасности и отдельные приложения «Как безопасно вызывать SQL» и «Спецификация диагностики здоровья веб-сайта».

Нужны ли меры безопасности даже сайту-визитке?

Нужны. Если есть форма обратной связи, значит, работает программа, обрабатывающая введённые данные, а если используется CMS вроде WordPress, атаке подвержены и панель администратора, и плагины. Злоумышленники не обязательно выбирают жертву по размеру компании — они механически находят уязвимые сайты и используют их для подделки, распространения вирусов или как источник спам-рассылки. Опасность веб-сайта в том, что вы одновременно оказываетесь и жертвой, и стороной, причиняющей вред контрагентам и посетителям.

В чём разница между принципиальным решением и подстраховочной мерой?

«Руководство по созданию безопасного веб-сайта» делит меры на два вида. Принципиальное решение — это способ реализации, устраняющий саму причину уязвимости (например, для SQL-инъекции — построение SQL-запросов через плейсхолдеры, а не через конкатенацию строк). Подстраховочная мера снижает вероятность успеха атаки или ущерб, если уязвимость всё же осталась (например, не выводить в браузер исходный текст ошибки как есть). Поскольку одни подстраховочные меры оставляют причину нетронутой, правильный порядок — принципиальное решение как основа, а подстраховочные меры — как надстройка над ним.

Что проверить по безопасности при заказе у студии-разработчика?

Рекомендуем на этапе оценки стоимости проверить как минимум три вещи: 1) реализованы ли меры против уязвимостей, перечисленных в «Руководстве по созданию безопасного веб-сайта», 2) может ли исполнитель показать результаты проверки, например по прилагаемому чек-листу реализации безопасности, 3) кто после публикации сайта будет обновлять CMS и плагины (то есть входит ли это в объём договора на эксплуатацию и сопровождение). Требования по безопасности дорого добавлять постфактум, поэтому важно закрепить их письменно до заключения договора.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.