Одним из наиболее интересных аспектов современной веб-разработки является потенциал, который приходит с созданием приложений специально для веб-браузеров (или для запуска «в облаке»).
Изначально Java задумывался как решение для однократной записи и запуска в любом месте, но кажется, что сеть стала идеальным средством для этого. Кто бы мог подумать, верно?
Но наряду с различными браузерами, которые у нас есть, технологиями, которые мы можем использовать, и, проще говоря, изящными вещами, которые мы можем сделать, в разработке веб-приложений все еще есть темный живот — межсайтовый скриптинг.
И, учитывая, что WordPress — это веб-приложение, на котором многие из нас строят ради удовольствия, для получения прибыли или для заработка, это тема, которую нам не следует избегать, особенно если мы хотим иметь максимально надежные продукты.
В этой серии из двух частей мы рассмотрим, что на самом деле представляет собой межсайтовый скриптинг, его опасности, как это влияет на разработку WordPress, а затем практические шаги, которые мы можем предпринять для тестирования наших тем и плагинов.
Что такое межсайтовый скриптинг?
Межсайтовый скриптинг, обычно сокращенно обозначаемый как XSS, определяется в Википедии следующим образом:
XSS позволяет злоумышленникам внедрить клиентский сценарий в веб-страницы, просматриваемые другими пользователями. Уязвимость межсайтового скриптинга может использоваться злоумышленниками для обхода средств контроля доступа, таких как одна и та же политика происхождения.
Я думаю, что это определение хорошо работает, если вы знакомы с уязвимостями, той же политикой происхождения и тем, что именно представляет собой внедрение клиентского сценария, но для многих этого просто недостаточно.
Концептуальное представление о том, как данные передаются от клиента к серверу. Итак, давайте посмотрим на межсайтовый скриптинг с нуля, прежде чем идти дальше.
Понимание клиентских сценариев
Клиентские сценарии — это в основном любой код, который выполняется на стороне клиента веб-сайта или веб-приложения. Возможно, самые популярные скрипты на стороне клиента — это функции JavaScript. Напротив, PHP будет рассматриваться как серверный скрипт.
Другой способ взглянуть на это так: клиентские скрипты отправляются с сервера на компьютер посетителя при загрузке веб-страницы. Затем скрипт выполняется. Иногда это делает что-то простое, например, анимацию меню
В других случаях он может сделать что-то более продвинутое, например, выполнить асинхронный вызов на сервер, извлечь некоторые данные в зависимости от местоположения пользователей и настроить информацию, которую они видят.
Хотя это может быть использование информации о местоположении, предоставленной браузером, это все еще безопасно, поскольку браузер поддерживает данные, а информация извлекается на основе общедоступной информации.
Так что же такое инъекция скрипта?
Возможно, лучшее название для «Внедрения скрипта» — «Внедрение кода».
Здесь злоумышленник буквально ищет какой-либо элемент ввода на вашем сайте — это может быть поле поиска, поле контакта, поле имени или любой другой тип элемента, который передает данные на сервер. Обычно это делается с помощью сценария — иногда это вредоносный JavaScript, но злоумышленники также могут успешно вставлять команды PHP или MySQL.
Наконец, это называется инъекцией, потому что если злоумышленник успешен, то он буквально внедряет свой код в ваше приложение.
И что это за «политика одного и того же происхождения»?
Концепция политики одного и того же происхождения проста: это политика, которую браузеры применяют, которая в основном позволяет клиентским сценариям — таким как JavaScript — отправлять запросы на другие страницы и серверные сценарии на том же сервере (или в том же источнике). ), но не для других доменов или сайтов.
Например, вы можете настроить функцию JavaScript для вызова с tutsplus.com на wordpress.com, получения данных и отображения их на tutsplus.com. Это нарушило бы политику того же происхождения.
Теперь, чтобы уточнить, это не означает, что это не может быть сделано. Благодаря сочетанию креативных функций на стороне клиента и вызовов на стороне сервера можно добиться определенных результатов, но браузеры делают все возможное, чтобы на самом деле это не выполнялось сценариями на стороне клиента.
Почему это опасно?
На данный момент последствия должны быть довольно ясны. Уязвимости межсайтового скриптинга могут дать злонамеренным посетителям контроль над нашими сайтами и веб-приложениями способами, которые мы, в конечном счете, не сможем контролировать.
Например, они могут варьироваться от относительно незначительных до гораздо более важных:
- Злоумышленники могут получить доступ к базе данных и вставить данные, которые затем будут видны будущим посетителям.
- Злоумышленники могут получить доступ к информации о сеансе, взломать ее и выдать себя за пользователя
- Злоумышленники могут получить конфиденциальную финансовую информацию
- Злоумышленники могут выполнить все вышеперечисленное и / или затем закрыть весь сайт.
- … и многое другое
Все это зависит от того, какие функции предлагает сайт, и насколько он действительно безопасен.
Как бы то ни было, безопасность веб-приложений — это то, что нужно сохранить. Конечно, я считаю, что все мы должны специализироваться в соответствующих областях, и что специалисты по безопасности — это люди, с которыми мы должны проконсультироваться до запуска веб-приложения, которое может содержать конфиденциальную информацию, но это не значит, что мы не можем ознакомиться с несколькими базовыми стратегиями для нашего собственного тестирования.
Как это влияет на разработку WordPress
Прежде чем мы действительно рассмотрим практичность внедрения безопасных XSS-технологий в наших усилиях по разработке, нам важно отметить, почему — как разработчики WordPress — мы должны даже заботиться об этом.
Учтите это: WordPress — это полноценное веб-приложение. Он состоит из базы данных, прикладного уровня и уровня представления, которые могут быть расширены другими разработчиками.
Стек WordPress Это означает, что сам WordPress подвержен многим из тех же угроз безопасности, что и любое другое веб-приложение, но и те, кто создает для WordPress.
Даже если WordPress был очень устойчив к любым атакам XSS, это не значит, что сторонние инструменты, такие как плагины или темы, автоматически получают эти преимущества.
В конце концов, они созданы сторонними разработчиками, которые могут не следовать рекомендациям при написании защитного кода.
Все функции WordPress в стороне и на самом базовом уровне: если ваша работа каким-либо образом принимает какие-либо данные от пользователя, то вы потенциально открываете дверь для эксплойта XSS.
Я бы даже сказал, что если вы хотите использовать некоторые основные API-интерфейсы WordPress для приема ввода и хранения данных, то вы не совсем в безопасности.
В конце концов, WordPress может иметь эксплойты, которые еще предстоит обнаружить.
Что мы можем с этим сделать
Таким образом, возникает вопрос: если мы действительно заботимся о работе, которую мы делаем, и хотим создать что-то значительно более безопасное, то есть ряд вещей, которые мы можем сделать.
Во-первых, нам нужно убедиться, что мы используем правильные функции API для обработки полей ввода, атрибутов, проверки и очистки. Некоторые из этих функций предоставляют функции специально для:
На самом деле, статья Кодекса предлагает подробные функции по:
- URL — адрес
- Ввод и вывод базы данных
- Проверка файлов
- Поля ввода
- …и многое другое.
Я настоятельно рекомендую прочитать статью целиком.
Во-вторых, мы можем запустить нашу тему или плагин через ряд тестов XSS, которые используются для выявления любых эксплойтов, которые нам не удалось поймать. Но мы рассмотрим это в следующей статье.
Вывод
Подводя итог, можно сказать, что межсайтовый скриптинг — это возможность злоумышленников вставлять свой вредоносный код в наш веб-сайт, веб-приложение, тему или плагин, пытаясь получить контроль над некоторыми аспектами — или всеми аспектами — сайта.
Потенциал эксплойтов варьируется от приложения к приложению, но, учитывая, что наша область специализации связана с WordPress, мы сосредоточимся на стратегиях для эксплойта, подтверждающих нашу работу, в следующей статье.