Как проверить, защищена ли ваша система WordPress от XSS-атак
Во всем мире почти 48 процентов всех веб-сайтов уязвимы для межсайтового скриптинга (XSS). Во всем мире почти ровно 25 процентов всех веб-сайтов используют платформу WordPress.
Отсюда следует, что на диаграмме Венна сайтов, уязвимых для XSS, и сайтов, работающих на платформе WordPress, перекрытие должно быть довольно большим.
Это не удар по самой платформе. Команда WordPress сделала безопасность неотъемлемой частью своей миссии и агрессивно исправляет уязвимости всякий раз, когда о них становится известно. Тем не менее, это не мешает людям создавать небезопасные темы или устанавливать небезопасные плагины. Эти проблемы являются двумя основными входами для XSS-атак на сайты WordPress, и в этой статье мы обсудим, как их остановить.
Введение в межсайтовый скриптинг
Во-первых, давайте обсудим, как выполняются XSS-атаки. Существует несколько типов XSS-атак, поэтому я начну с упрощенного определения. Как правило, XSS-атаки начинаются с непроверенных входных данных — форм комментариев, полей комментариев, строк поиска и т. д. Эти атаки сильно различаются по сложности. На самом деле, пользователи WordPress каждый день сталкиваются с простейшей формой XSS-атаки: спам-комментарий. Вы знаете, о чем я: «Спасибо за прекрасную статью. Кстати, вот мой сайт, на котором я зарабатываю 5000 долларов в неделю, работая дома: www.only-an-idiot-would-click-this-link.co.uk».
В некотором смысле спам-комментарии — прекрасный пример XSS-атаки. Злоумышленник подрывает инфраструктуру вашего сайта (поле комментариев), чтобы разместить свой контент (вредоносную ссылку) на вашем сайте. Хотя это хороший иллюстративный пример, более реалистичная XSS-атака будет намного тоньше. На создание спам-комментария у кого-то уходит около пяти секунд. Атака XSS — это то, на что настоящий хакер потратит немного больше времени.
Настоящая черная шляпа попытается воспользоваться любыми аспектами вашего сайта, которые отправляют данные на сервер, по сути, используя их как миниатюрный текстовый редактор. Если ваши входные данные не защищены, это означает, что они могут буквально взять свой код и заставить ваше приложение запускать его и отображать в браузере пользователя (включая ваш браузер). В отличие от спам-комментариев, только детальное изучение измененного кода вашего сайта или просмотр взаимодействий с сайтом может выявить брешь. Как можно себе представить, нет конца количеству неприятных вещей, которые могут возникнуть в результате такого взлома.
Простой вандализм является относительно распространенным результатом XSS-атак, в результате чего вашим пользователям вместо вашего контента показываются гротескные изображения или политическая пропаганда. Маркетологи с небольшим количеством долгосрочных планов или этических соображений будут использовать их для рекламы людям против их воли. Более тонкая и изощренная атака может украсть учетные данные ваших пользователей. Если у одного из них есть права администратора, любая личная информация, которую вы храните на своем сайте, может быть захвачена. В качестве альтернативы они могут использовать первоначальную XSS-атаку в качестве рычага, чтобы взломать ваш сайт и установить еще более сложное вредоносное ПО.
Остановка атак
Если вы достаточно хорошо разбираетесь в коде и являетесь единственным владельцем относительно небольшого сайта WordPress, то методы безопасного кодирования, вероятно, будут лучшим способом защитить ваш сайт от атак с использованием межсайтовых сценариев. Я включаю это предостережение, потому что, если вы являетесь частью более крупной организации, работающей с более сложным приложением, вам может быть не под силу найти каждую область, куда злоумышленник может внедрить код. Современные веб-сайты могут быть огромными по размеру, и вам может потребоваться нанять опытного профессионала и потратить свое время на другие занятия, чтобы сделать ваш веб-сайт еще лучше для ваших читателей.
Другое предупреждение заключается в том, что если вы не особенно разбираетесь в коде и кто-то другой создает ваш сайт для вас, то не думайте, что он использовал методы безопасного кодирования. Известно, что даже самые опытные разработчики забывают о безопасности или допускают незначительные ошибки, и никто не проверяет их работу. время для себя (несмотря на отсутствие профессионализма, когда дело доходит до этого). Таким образом, убедитесь, что вы нанимаете признанного профессионала, который не срезает углы, когда дело доходит до разработки и защиты вашего веб-сайта.
Выражая эту озабоченность, одним из первых и самых простых способов предотвращения межсайтовых сценариев является проверка пользовательских данных.
Допустим, у вас есть форма регистрации на вашем сайте, и эта форма просит пользователя ввести свое имя. Вместо этого злоумышленник может ввести что-то вроде:
<script>CoughUpYourPreciousData();</script>Например, это может привести к тому, что следующий человек, посетивший эту страницу, отправит злоумышленнику копию своих файлов cookie.
Вы можете видеть, что в этом примере приведенная выше строка кода совсем не похожа на чье-то имя. Ваш сервер этого не знает, но, используя несколько заданных параметров, вы можете научить его этому. Например, вы можете указать этому полю отклонять специальные символы, такие как <>,() и ; (они особо не нужны в разделе комментариев). Вы можете указать в этом поле, что в имени человека, вероятно, нет цифр. Если вы хотите быть немного драконовским, вы можете указать этому полю отклонять входные данные, длина которых превышает пятнадцать символов (или вы можете изменить значения по своему усмотрению). Выполнение этих шагов резко ограничит количество повреждений, которые злоумышленник может нанести конкретному полю.
Даже с проверкой данных могут быть формы или поля, где вы не можете реально ограничить тип используемых символов, например, в контактной форме или поле комментария. Что вы можете сделать, так это очистить данные. Этот процесс делает невозможным выполнение HTML в заданном поле, преобразовывая все, что может быть распознано как часть исполняемого кода, в некодирующие символы. Например, гиперссылка не появится там, где она могла бы быть.
Наконец, бывают случаи, когда на вашем сайте могут отображаться данные, небезопасные для пользователей. Допустим, кто-то пишет злонамеренный комментарий на одной из ваших страниц, который впоследствии индексируется поисковой системой вашего сайта. Всякий раз, когда один из ваших пользователей выполняет поиск, этот вредоносный код выполняется, когда их браузер загружает результаты поиска. Это предотвращается путем экранирования данных, что гарантирует, что когда ваш сайт доставляет данные пользователю, единственный код, который выполняется, — это код, который вы хотите запустить.
Чтобы узнать больше о проверке данных, очистке данных и их экранировании, в Кодексе WordPress есть отличный ресурс. Он подробно объяснит вышеупомянутые концепции, а также даст больше примеров, которые можно применять повсеместно.
Другие методы
У крупных компаний есть более крупные веб-сайты; это факт. Может быть, тысячи людей используют ваш сайт в день. Может быть, вместо стандартных форм и полей есть еще анимации, различные порталы, части, написанные на Java, и так далее. Даже если вы будете следить за всем этим, возможно, в одном из ваших приложений есть нулевой день, и у вас нет возможности защитить себя.
В подобной ситуации, если у вас есть на это влияние и бюджет, я бы порекомендовал вам инвестировать в брандмауэр веб-приложений (WAF). Хороший WAF будет иметь правила корреляции, которые автоматически идентифицируют и блокируют строки HTML, которые чаще всего связаны с атаками с внедрением кода. Они также могут уведомлять вас, когда приложения начинают извлекать данные, когда они не должны этого делать или делают это в необычном объеме, что помогает защититься от атак нулевого дня и других сложных угроз. WAF — это не серебряная пуля, но бесценный инструмент для специалистов по безопасности и владельцев веб-сайтов, которые надеются защитить сложные приложения.
Существует также ряд плагинов, предназначенных для защиты от XSS-атак. Я на самом деле не рекомендую эти. Вместо того, чтобы снижать риск, многие из этих плагинов представляют собой просто еще одну поверхность атаки, которую может использовать хакер. Даже один из самых известных и широко используемых плагинов безопасности, Akismet, в прошлом году оказался уязвимым для XSS-атак . Когда дело доходит до отражения XSS-атак, не полагайтесь на полумеры. Развивайте необходимые навыки и используйте соответствующий набор инструментов для обеспечения безопасности вашего сайта.
Другие практические приложения
Эта информация может быть немного сложной для непосвященных, но я бы не хотел, чтобы люди были обескуражены потенциальной сложностью этой информации. Если произойдет XSS-атака, вы можете быть уверены, что устранение последствий такого события будет намного сложнее, чем внесение изменений на ваш сайт. Очистка репутационных издержек вашего веб-сайта (постоянные читатели довольно легко покинут ваш веб-сайт) станет дополнительной проблемой, о которой вам не нужно беспокоиться.
Даже если вы нанимаете кого-то другого для разработки и обеспечения безопасности вашего веб-сайта, сделайте все возможное, чтобы, по крайней мере, иметь возможность реагировать на чрезвычайные ситуации и знать, где ваши слабые места. Знание того, как проверить свою систему, станет жизненно важным навыком в долгосрочной перспективе и станет основой для других тем безопасности и проектов по разработке веб-сайтов. Все взаимосвязано в Интернете, и, хотя атаки XSS могут быть делом последних лет (хотя это маловероятно), знание всех тонкостей вашего веб-сайта никогда не устареет.
Последние мысли
Ландшафт безопасности в Интернете постоянно меняется. Вы никогда не можете быть полностью уверены в том, как может выглядеть XSS-атака или как она может быть использована против вас, но вы обязаны сделать все возможное для себя и своих читателей, чтобы сделать все, что в ваших силах, чтобы остановить их. Продолжайте информировать себя об этой угрозе и регулярно проверяйте (я бы рекомендовал не реже одного раза в месяц) любые соответствующие события в мире кибербезопасности.
Это также не означает, что вы можете игнорировать другие угрозы. Доступ к общедоступной сети по-прежнему требует использования VPN для обеспечения безопасности. Вы не можете пренебрегать безопасностью любого компьютера, который вы используете для доступа к вашему веб-сайту. Информацию для входа по-прежнему необходимо часто менять, чтобы защититься от атак грубой силы. XSS-атаки жестоки, но это не единственная угроза, на которую следует обратить внимание.
Вам также может быть полезно поделиться этой информацией (или даже этой статьей) со своими коллегами и заинтересованными сторонами, чтобы повысить устойчивость к этим типам атак. Хотя вы, возможно, не сможете сделать слишком много самостоятельно, если достаточное количество людей должным образом защищают себя, мы можем увидеть общее снижение таких типов атак, поскольку хакеры пытаются найти другой способ нажиться на бедных интернет-пользователях.
Есть ли у вас какие-либо мысли о том, как проверить XSS-атаки, а также защитить себя от них в будущем? Есть ли какие-либо другие стратегии обнаружения и удаления, которые вы используете для борьбы с этой угрозой? Есть ли какие-нибудь инструменты, которые вы бы порекомендовали своим коллегам-читателям? Если это так, пожалуйста, оставьте комментарий ниже и продолжите этот важный разговор с другими читателями.