В четверг в сети появилась информация о том, что на сайте Госуслуг найден потенциально опасный код, и сегодня мы хотим поделиться с вами результатами собственного расследования и в очередной раз напомнить о важности применения Content Security Policy.
В первых сообщениях об угрозе говорилось о внедрении на страницы сайта фрагментов с iframe, подгружающих данные с не менее 15 сомнительных доменов. Наши аналитики достаточно быстро приступили к изучению кода страниц сайта, чтобы защитить пользователей при помощи существующего у нас механизма предотвращающего подобные угрозы. О самом механизме расскажем чуть ниже, но главное здесь в другом – найденные фрагменты кода были нам хорошо знакомы.
Если вы хорошо знакомы с разработкой расширений для популярных браузеров, то знаете, что у авторов существует не так много способов для заработка на собственных творениях. Платные расширения почти не встречаются, и в результате большинство попыток заработать строится вокруг того, что они просто внедряют рекламу в код посещаемых пользователями страниц. Для этого существуют целые партнерские программы, которые предлагают авторам расширений встроить код, который их расширения должны внедрять во все посещаемые пользователем страницы. Обычно встроенный фрагмент занимается тем, что показывает дополнительную, часто не очень качественную рекламу, но, вообще говоря, технологически позволяет осуществить и что-то более опасное. На gosuslugi.ru присутствовали фрагменты кода, которые в подобных расширениях могут использоваться для сбора статистики или показа рекламы.
Такие фрагменты попадают в код страницы на стороне клиента, если у него установлено расширение. И здесь напрашивается вопрос: «как же тогда этот код оказался на стороне сервера?» И у нас есть гипотеза.
Мы считаем, что появление данного кода на страницах gosuslugi.ru не связано со взломом, целенаправленной атакой. Более вероятно, что у администратора, который редактировал содержимое этих страниц, было установлено подобное расширение. Оно внедрило посторонний код в документ, когда он загружался на сторону клиента, а на сервере он появился уже после того, как сотрудник сохранил свои изменения. В пользу этой версии говорит еще один факт. Мы внимательно мониторили все найденные фрагменты, и ни один из них так и не начал подгружать какой-либо контент – авторы кода вряд ли предполагали, что получат доступ к пользователям портала государственных услуг. Но это не означает, что угрозы не было — они могли начать делать это в любой момент, как только поняли, на страницах какого сайта оказался их код.
А теперь про механизм защиты. У порядка процента пользователей Яндекса возникает аналогичная проблема с посторонним контентом в посещаемых страницах. И это очень много. Поэтому мы давно и активно боремся с подобной угрозой. Прежде всего, мы защищаем пользователей Яндекс.Браузера с помощью механизма, который препятствует подгрузке данных с выявленных сомнительных адресов. Информация о новых угрозах оперативно попадает в базу SafeBrowsing, которая доступна Браузеру, Поиску и другим нашим сервисам при помощи специального API. Это позволяет нам быстро пресекать распространение эпидемий без необходимости выпускать обновление для самого приложения.
К счастью, в случае с Госуслугами пользователи Яндекса по большей части уже были защищены: 15 найденных фрагментов из 16 уже были внесены в базу SafeBrowsing еще до ситуации с сайтом в рамках обычного процесса поиска угроз.
И еще кое-что. Иметь щит на стороне клиента хорошо, но и о защите на стороне сервиса тоже не стоит забывать. Мы рекомендуем всем крупным сервисам, работающим с приватными данными пользователей, внедрять поддержку Content Security Policy. Это позволит заблокировать подгрузку стороннего контента и защитить ваших пользователей. Сервисы Яндекса уже давно используют CSP для предотвращения загрузки постороннего кода.
Автор: Яндекс
