Межсайтовый скриптинг

Определение

Наименование script известно веб-пользователям достаточно давно. Впервые о нем услышали еще во время появления известной на тот момент операционной системы Unix, наследным продуктом которой сейчас выступает популярная на хостинг-платформах Linux.

В переводе с английского данный термин означает «сценарий» и подразумевает комплекс разнообразных команд, предназначенных для осуществления определенного действия. Командный набор формируется в виде файла с текстовым содержимым, позволяющим получить допуск к запуску программы. Его активация происходит в автоматическом режиме в установленный период, полностью соответствующий логике и функциональному назначению веб-ресурса. При этом пользователю нет необходимости выполнять какие-либо дополнительные манипуляции.

Проще говоря, script — это четко прописанная последовательность действий. А задают ее с помощью скриптовых веб-языков программирования, создание которых ориентировано на выполнение функциональных задач. Наиболее распространенные из них: JavaScript, Python, Perl, PHP и т. п. Благодаря им можно значительно повысить эффективность работы, к примеру, интернет-сервиса или инструмента на веб-площадке.

Таким образом, скрипт делает сайт динамичным, запускает механизм активности, тем самым позволяя юзерам использовать возможности ресурса по максимуму. Для сравнения, если ликвидировать все созданные на веб-странице сценарии, то на выходе получим просто статичное изображение. Никаких удобных всплывающих блоков меню, кликабельных кнопок и т. п. Взаимодействовать с таким ресурсом станет попросту невозможно. Пользователь не сможет даже оставить комментарий под выкладкой, так как нажатие на клавишу не даст нужного результата.

Чтобы сделать сервис активным (позволить посетителю отправить отзыв), предстоит сформировать соответствующую последовательность действий. Только при таких условиях произойдет действие. Интернет-пользователю удастся ввести текст и увидеть результат произведенных манипуляций.

Параллельно можно составить дополнительный script (или расширить возможности предыдущего), с помощью которого юзер будет получать оповещения об отправке-доставке сообщений. Если сделать все без ошибок, пользователь увидит краткий отчет «комментарий отправлен».

Чем отличаются плагины и скрипты

С определением сценария мы разобрались в предыдущем разделе, теперь необходимо понять, чем он отличается от веб-плагина. Plugin, если обратиться к дословному переводу с английского — подключаемый модуль. Небольшая программная кодировка, предназначенная для дополнения базового функционала. Выражаясь более понятным языком — это необходимые надстройки, исправления и дополнения, посредством которых удается улучшить основную программу и облегчить работу пользователя.

Отличительной особенностью плагинов является то, что они не способны функционировать самостоятельно. Их ведущая роль — дополнять и выполнять внутри основной веб-программы, которая сохраняет свою функциональность и без добавочных расширений.

В качестве примера стоит привести один из наиболее распространенных веб-плагинов — Adobe Flash Player. После его установки интернет-браузеры получают возможность демонстрировать нам видеоролики и другой флеш-контент. Без AFP любой браузер сможет только открыть нужную страницу и взаимодействовать с сервисами в режиме основного предназначения. Но тот же просмотр видео с Ютуба пользователю будет недоступен.

Однако большое количество плагинов в значительной степени перегружают сайт и тормозят его работу. Поэтому, чтобы улучшить ресурс, но не потерять при этом его функциональность, следует воспользоваться скриптами.

Средства защиты

Защита на стороне сервера

• Кодирование управляющих HTML-символов, JavaScript, CSS и URL перед отображением в браузере. Для фильтрации входных параметров можно использовать следующие функции: (для кодирования URL), (для фильтрации HTML).
• Кодирование входных данных. Например с помощью библиотек OWASP Encoding Project, HTML Purifier, htmLawed, Anti-XSS Class.
• Регулярный ручной и автоматизированный анализ безопасности кода и тестирование на проникновение. С использованием таких инструментов, как Nessus, Nikto Web Scanner и OWASP Zed Attack Proxy.
• Указание кодировки на каждой web-странице (например, ISO-8859-1 или UTF-8) до каких-либо пользовательских полей.
• Обеспечение безопасности cookies, которая может быть реализована путём ограничения домена и пути для принимаемых cookies, установки параметра HttpOnly, использованием SSL.
• Использование заголовка Content Security Policy, позволяющего задавать список, в который заносятся желательные источники, с которых можно подгружать различные данные, например, JS, CSS, изображения и пр.

Защита на стороне клиента

• Регулярное обновление браузера до новой версии.
• Установка расширений для браузера, которые будут проверять поля форм, URL, JavaScript и POST-запросы, и, если встречаются скрипты, применять XSS-фильтры для предотвращения их запуска. Примеры подобных расширений: NoScript для FireFox, NotScripts для Chrome и Opera.

Как эксплуатируется уязвимость

Конечно, когда вы просто пишете какой-то код, трудно представить, что вы напишете в строке </script> и не заметите проблем. Как минимум, подсветка синтаксиса даст вам знать, что тег закрылся раньше времени, как максимум, написанный вами код не запустится и вы будете долго искать, что произошло. Но это не является основной проблемой с этой уязвимостью. Проблема возникает там, где вы вставляете какой-то контент в Javascript, когда генерируете HTML. Вот частый кусок кода приложений на реакте с серверным рендерингом:

В </script> может появиться в любом месте, где данные поступают от пользователя или из других систем. не будет менять такие строки при сериализации, потому что они полностью соответствуют формату JSON и Javascript, поэтому они просто попадут на страницу и позволят злоумышленнику выполнить произвольный Javascript в браузере пользователя.

Другой пример:

Тут в строки с соответствующим экранированием записываются пользователя и , который пришел на сервер. И, если в вряд ли будет что-то кроме цифр, то в злоумышленник может запихнуть что угодно.

Но на закрывающем теге </script> приколы не заканчиваются. Опасность представляет и открывающий тег <script>, если перед ним в любом месте есть символы , которые в обычном HTML обозначают начало многострочного комментария. Причем в этом случае вам уже не поможет подсветка синтаксиса большинства редакторов.

Что видит здоровый человек и большинство подсветок синтаксиса в этом коде? Два тега <script>, между которыми находится параграф.

Что видит больной парсер HTML5? Он видит один (!) незакрытый (!) тег <script>, содержащий весь текст со второй строчки до последней.

Я до конца не понимаю, почему это так работает, мне понятно лишь, что встретив где-либо символы , парсер HTML начинает считать открывающие и закрывающие теги <script> и не считает скрипт законченным, пока не будут закрыты все открытые теги <script>. То есть в большинстве случаев этот скрипт будет идти до конца страницы (если только кто-то не смог внедрить еще один лишний закрывающий тег </script> ниже, хе-хе). Если вы до этого не сталкивались с подобным, то можете подумать, что я сейчас шучу. К сожалению, нет. Вот скриншот DOM-дерева примера выше:

Самое неприятное, что в отличие от закрывающего тега </script>, который в Javascript может встретиться только внутри строковых литералов, последовательности символов и могут встретиться и в самом коде! И будут иметь точно такой же эффект.

Avoiding cross-site scripting vulnerabilities with Veracode.

Veracode provides leading application security solutions that help to protect the software that is critical to business operations. Built on a cloud-based platform, Veracode’s comprehensive testing methodologies allow developers and administrators to test for vulnerabilities throughout the development process, from inception through production. From tools for the developers IDE to static analyses and web vulnerability scanners, Veracode provides on-demand, SaaS-based services that enable organizations to embed security testing into development without sacrificing agility or speed.

Fixing cross-site scripting errors in applications involves three steps:

• Applications must validate data input to the web application from user browsers.
• All output from the web application to user browsers must be encoded.
• Users must have the option to disable client-site scripts.

Veracode’s testing services can quickly scan control and data flow for an application and accurately identify cross-site scripting and other flaws in code that is built in-house or acquired from third-parties. Scan results are returned quickly – usually within four hours – and include a step-by-step remediation plan that helps to accelerate fixes and prioritize efforts.

Background [ edit ]

Security on the web depends on a variety of mechanisms, including an underlying concept of trust known as the same-origin policy. This essentially states that if content from one site (such as https://mybank.example1.com) is granted permission to access resources (like cookies etc.) on a web browser, then content from any URL with the same (1) URI scheme, (2) host name, and (3) port number will share these permissions. Content from URLs where any of these three attributes are different will have to be granted permissions separately.

Cross-site scripting attacks use known vulnerabilities in web-based applications, their servers, or the plug-in systems on which they rely. Exploiting one of these, attackers fold malicious content into the content being delivered from the compromised site. When the resulting combined content arrives at the client-side web browser, it has all been delivered from the trusted source, and thus operates under the permissions granted to that system. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, to session cookies, and to a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are a case of code injection.

Microsoft security-engineers introduced the term «cross-site scripting» in January 2000. The expression «cross-site scripting» originally referred to the act of loading the attacked, third-party web application from an unrelated attack-site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (taking advantage of a reflected or non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors (including ActiveX, Java, VBScript, Flash, or even HTML scripts), causing some confusion to newcomers to the field of information security.

XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter, Facebook, MySpace, YouTube and Orkut. Cross-site scripting flaws have since surpassed buffer overflows to become the most common publicly reported security vulnerability, with some researchers in 2007 estimating as many as 68% of websites are likely open to XSS attacks.

Types [ edit ]

There is no single, standardized classification of cross-site scripting flaws, but most experts distinguish between at least two primary flavors of XSS flaws: non-persistent and persistent. Some sources further divide these two groups into traditional (caused by server-side code flaws) and DOM-based (in client-side code).

Non-persistent (reflected)

The non-persistent (or reflected) cross-site scripting vulnerability is by far the most basic type of web vulnerability. These holes show up when the data prov >

Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-val > A >

Persistent (or stored)

The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data prov >

Suppose that Mallory, an attacker, joins the site and wants to figure out the real names of the people she sees on the site. To do so, she writes a script designed to run from other users’ browsers when they visit her profile. The script then sends a quick message to her own server, which collects this information.

Persistent XSS vulnerabilities can be more significant than other types because an attacker’s malicious script is rendered automatically, without the need to indiv >

Server-side versus DOM-based vulnerabilities

Historically XSS vulnerabilities were first found in applications that performed all data processing on the server side. User input (including an XSS vector) would be sent to the server, and then sent back to the user as a web page. The need for an improved user experience resulted in popularity of applications that had a majority of the presentation logic (maybe written in JavaScript) working on the client-side that pulled data, on-demand, from the server using AJAX.

As the JavaScript code was also processing user input and rendering it in the web page content, a new sub- >

An example of a DOM-based XSS vulnerability is the bug found in 2011 in a number of jQuery plugins. Prevention strategies for DOM-based XSS attacks include very similar measures to traditional XSS prevention strategies but implemented in JavaScript code and contained in web pages (i.e. input val > Some JavaScript frameworks have built-in countermeasures against this and other types of attack — for example Angular.js.

Self-XSS

Self-XSS is a form of XSS vulnerability which relies on Social Engineering in order to trick the victim into executing malicious JavaScript code into their browser. Although it is technically not a true XSS vulnerability due to the fact it relies on socially engineering a user into executing code rather than a flaw in the affected website allowing an attacker to do so, it still poses the same risks as a regular XSS vulnerability if properly executed.

Mutated XSS (mXSS)

Mutated XSS happens when the attacker injects something that is seemingly safe, but rewritten and modified by the browser, while parsing the markup. This makes it extremely hard to detect or sanitize within the websites application logic. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters on parameters to CSS font-family.

Связанные уязвимости

В атаке универсального межсайтового скриптинга ( UXSS или Universal XSS ) используются уязвимости в самом браузере или в плагинах браузера (а не в уязвимостях других веб-сайтов, как в случае с XSS-атаками).

С XSS связаны несколько классов уязвимостей или техник атак: межзональный скриптинг использует концепции «зон» в определенных браузерах и обычно выполняет код с более высокими привилегиями. Внедрение HTTP-заголовка может использоваться для создания условий межсайтового сценария из-за проблем с выходом на уровень протокола HTTP (в дополнение к разрешению атак, таких как разделение HTTP-ответа ).

Подделка межсайтовых запросов (CSRF / XSRF) почти противоположна XSS, поскольку вместо того, чтобы использовать доверие пользователя к сайту, злоумышленник (и его вредоносная страница) эксплуатируют доверие сайта к клиентскому программному обеспечению, отправляя запросы, которые сайт считает, что это сознательные и преднамеренные действия аутентифицированных пользователей. Уязвимости XSS (даже в других приложениях, работающих в том же домене) позволяют злоумышленникам обойти усилия по предотвращению CSRF.

использует преимущества сторонних клиентов, восприимчивых к атакам XSS или Open Redirect. Обычные попытки фишинга легко обнаружить, потому что URL-адрес вредоносной страницы обычно на пару букв отличается от URL-адреса реального сайта. Отличие от скрытого перенаправления заключается в том, что злоумышленник может вместо этого использовать настоящий веб-сайт, повредив его с помощью вредоносного всплывающего диалогового окна входа в систему.

Наконец, SQL-инъекция использует уязвимость на уровне базы данных приложения. Если вводимые пользователем данные неправильно отфильтрованы, приложение может выполнять любые операторы SQL.

Конкретные XSS, которые влияют на данную версию веб-браузера, как правило, уникальны. Следовательно, можно использовать XSS для определения производителя браузера и версии пользователя.

Что такое script: основные разновидности

Все сценарии подразделяются на два типа:

• Клиентские. Страницы интернет-ресурсов имеют описание на основе языка гипертекстовой разметки html, который отвечает исключительно за статичное отображение. Задать с его помощью динамику невозможно. Именно в таких ситуациях применяются особые веб-алгоритмы, умеющие видоизменять html-разметку без обязательной перезагрузки. Чаще всего такие последовательности прописываются непосредственно в кодировку. Реализация html-кода не подразумевает установки добавочного ПО, что существенно облегчает задачу. Единственное, что требуется для осуществления задумки — интернет-браузер, поддерживающий данную категорию сценариев и детальная подгонка имеющихся шаблонов (если речь не идет о самостоятельном написании). Как правило, в этом плане подходят практически все современные версии браузеров.
• Серверные. Выполняются сервером в соответствии с запросом, который формируется клиентским дополнением — веб-браузером. Без такого типа script не смогут функционировать опросники, книги посещений и многие другие объемные составляющие программ, взаимодействующих с информационными базами. Эта разновидность скриптов используется для расширения функциональных возможностей непосредственно во внутренней структуре ресурса.

Различные типы уязвимости Cross-Site Scripting

Существует в основном три различных типа уязвимости Cross-site Scripting; Stored, Reflected и DOM XSS. Ниже мы рассмотрим более подробно каждого из них.

Stored Cross-site Scripting

Уязвимости Stored Cross-site возникают, когда полезная нагрузка (payload) сохраняется, например, в базе данных, а затем выполняется, когда пользователь открывает страницу в веб-приложении. Stored cross-site scripting очень опасно по ряду причин:

• Полезная нагрузка не видна для фильтра XSS браузера
• Пользователи могут случайно активировать полезную нагрузку, если они посещают уязвимую страницу, в то время как для использования Reflected XSS потребуется специально созданный URL-адрес или особые входные данные.

Пример Stored XSS

Stored XSS-уязвимость может возникнуть, если имя пользователя онлайн-доски объявлений не очищено должным образом при выводе на страницу. В этом случае злоумышленник может вставить вредоносный код при регистрации нового пользователя в форме. Когда имя пользователя отражается на странице доски объявлений, оно будет выглядеть так:

Вышеуказанный вредоносный JavaScript запускается каждый раз, когда пользователь посещает этот раздел форума, и он отправляет злоумышленникам файлы cookie доски объявлений, которые хранятся в браузере пользователя, и затем использует их для кражи сеансов пользователя. Stored XSS может быть очень опасной уязвимостью, поскольку может иметь свойство червя — распространяться, особенно при использовании на популярных страницах.

Например, представьте себе доску объявлений или веб-сайт социальной сети, на котором есть общедоступная страница, которая уязвима для уязвимости stored XSS, такой как страница профиля пользователя. Если злоумышленник может разместить вредоносную полезную нагрузку JavaScript, которая добавляет себя на страницу профиля, вектор атаки выполняется каждый раз, когда посетитель открывает страницу, и полезная нагрузка распространяется с экспоненциальным ростом.

Reflected Cross-site Scripting (XSS)

Reflected XSS-уязвимость возникает, когда пользовательский ввод с URL-адреса или данных POST отражается на странице без сохранения, что позволяет злоумышленнику внедрить вредоносный контент. Это означает, что злоумышленник должен отправить созданный вредоносный URL-адрес или почтовую форму жертве, чтобы вставить полезную нагрузку, и жертва должна щелкнуть ссылку. Этот вид полезной нагрузки также обычно определяется встроенными фильтрами XSS в браузерах пользователя, таких как Chrome, Internet Explorer или Edge.

Пример Reflected XSS

В качестве примера XSS-атак мы будем использовать функцию поиска на новостном веб-сайте, которая работает путем добавления пользовательского ввода, полученного из запроса GET HTTP, к параметру q, как показано в следующем примере:

В результатах поиска веб-сайт отражает содержание запроса, который искал пользователь, например:

Если функция поиска уязвима для уязвимости reflected cross-site scripting, злоумышленник может отправить жертве вредоносный URL-адрес, такой как приведенный ниже:

Когда жертва нажимает на вредоносный URL-адрес, выполняется атака XSS, и на веб-сайте отображается следующее:

Исходный код HTML, который отражает вредоносный код злоумышленника, перенаправляет браузер жертвы на веб-сайт, который контролируется злоумышленником, который затем крадет текущие файлы cookie / токены сеанса пользователя из браузера жертвы для сайта example.com в качестве параметра GET,

Список полезных команд

Список встроенных команд интерпретатора: helpПомощь по команде: <команда> —helpМануал по команде: man <команда>Версия команды: <команда> —versionСписок доступных оболочек: cat /etc/shellsСписок пользователей и их оболочек: cat /etc/passwdТекущая директория: pwdСписок файлов текущей директории: ls -laТекущий пользователь: idПеременные среды: setВерсия ОС: cat /etc/os-releaseВерсия ядра: uname -aПолучить привилегии суперпользователя: sudo su -Установка программы в Debian: apt install mcПосмотреть утилизацию(загрузку): topСвободное место: df -hСколько занимает директория: du -ks /var/logКонфигурация сетевых интерфейсов: ifconfig -aОбъем оперативной памяти: free -mИнформация о блочных устройствах(дисках): lsblkИнформация о процессорах: cat /proc/cpuinfoСписок установленных пакетов: apt list —installedСписок и статус сервисов: service —status-allПерезапуск сервиса: service apache2 restartСкачать файл: wget https://www.gnu.org/graphics/gplv3-with-text-136×68.pngПолучить веб-страницу по URL: curl https://www.google.comПоказать задания планировщика: crontab -lРедактировать задания планировщика: crontab -eВывести новые сообщения в системном логе: tail -f /var/log/syslogПодсчитать количество строк в выводе команды: <команда> | wc -lИзменить права доступа к файлу (разрешить выполнение всем): chmod a+x <файл>Список процессов: ps -efПроверить, запущен ли процесс: ps -ef | grep <процесс>Перейти в предыдущий каталог: cd -Завершить процесс (сигнал kill): kill -9Удаление файла: rm <имя файла>Удаление директории: rm -rf <имя директории>Редактировать файл: nano <имя_файла>Топ 10 процессов по использованию памяти: ps aux | awk ‘{print $6/1024 » MB\t\t» $11}’ | sort -nr | head

Планировщик заданий cron

В случае, когда есть необходимость периодического запуска скриптов, полезно использовать планировщик cron, он позволяет задать расписание запуска скрипта и не требует присутствия администратора.

Просмотр заданий пользователя выполняется командой . Для редактирования и создания новых задания используется команда . Строки для запуска команд планировщика в файле конфигурации cron имеют следующий формат:

Где m – минута, h – час, dom – день месяца, mon – месяц, dow – день недели, command – команда, parameters – список параметров. Наглядно этот формат можно представить так:

Например, для того, чтобы в 10 и 30 минут каждого часа каждый день месяца весь год по будням запускать команду, нужно указать следующее:

Более простой пример, каждые 15 минут выполнять команду:

Создадим скрипт для резервного копирования домашней директории пользователя, который будет создавать новый файл бэкапа при каждом запуске:

Поставим скрипт на выполнение каждый день в 22:00, выполнив команду и добавив с помощью открывшегося редактора строку:

Проверить, что задача добавлена в планировщик, можно командой :

В результате каждый день в 22:00 будет создаваться резервная копия домашней директории пользователя (в приведенном примере для демонстрации запуск скрипта выполняется каждую минуту):

Нужно отметить, что директория /tmp в примере использована исключительно для тестов, т.к. она предназначена для хранения временных файлов, и использовать её для хранения резервных копий нельзя. Правильное место размещения бэкапов может подсказать системный администратор.

Скрипты

Для выполнения нескольких команд одним вызовом удобно использовать скрипты. Скрипт – это текстовый файл, содержащий команды для shell. Это могут быть как внутренние команды shell, так и вызовы внешних исполняемых файлов.

Как правило, имя файла скрипта имеет окончание .sh, но это не является обязательным требованием и используется лишь для того, чтобы пользователю было удобнее ориентироваться по имени файла. Для интерпретатора более важным является содержимое файла, а также права доступа к нему.

Перейдем в домашнюю директорию командой и создадим в ней с помощью редактора nano ()файл, содержащий 2 строки:

Чтобы выйти из редактора nano после набора текста скрипта, нужно нажать Ctrl+X, далее на вопрос «Save modified buffer?» нажать Y, далее на запрос «File Name to Write:» нажать Enter. При желании можно использовать любой другой текстовый редактор.

Скрипт запускается командой , т.е. перед именем файла указывает на то, что нужно выполнить скрипт или исполняемый файл, находящийся в текущей директории. Если выполнить команду , то будет выдана ошибка, т.к. оболочка будет искать файл в директориях, указанных в переменной среды PATH, а также среди встроенных команд (таких, как, например, pwd):

Ошибки не будет, если выполнять скрипт с указанием абсолютного пути, но данный подход является менее универсальным: . Однако на данном этапе при попытке выполнить созданный файл будет выдана ошибка:

Проверим права доступа к файлу:

Из вывода команды видно, что отсутствуют права на выполнение. Рассмотрим подробнее на картинке:

Права доступа задаются тремя наборами: для пользователя, которому принадлежит файл; для группы, в которую входит пользователь; и для всех остальных. Здесь r, w и x означают соответственно доступ на чтение, запись и выполнение.

В нашем примере пользователь (test) имеет доступ на чтение и запись, группа также имеет доступ на чтение и запись, все остальные – только на чтение. Эти права выданы в соответствии с правами, заданными по умолчанию, которые можно проверить командой . Изменить права по умолчанию можно, добавив вызов команды umask с нужными параметрами в файл профиля пользователя (файл ~/.profile), либо для всех пользователей в общесистемный профиль (файл /etc/profile).

Для того, чтобы установить права, используется команда . Например, чтобы выдать права на выполнение файла всем пользователям, нужно выполнить команду:

Чтобы выдать права на чтение и выполнение пользователю и группе:

Чтобы запретить доступ на запись (изменение содержимого) файла всем:

Также для указания прав можно использовать маску. Например, чтобы разрешить права на чтение, запись, выполнение пользователю, чтение и выполнение группе, и чтение – для остальных, нужно выполнить:

Будут выданы права :

Указывая 3 цифры, мы задаем соответствующие маски для каждой из трех групп. Переведя цифру в двоичную систему, можно понять, каким правам она соответствует. Иллюстрация для нашего примера:

Символ перед наборами прав доступа указывает на тип файла ( означает обычный файл, – директория, – ссылка, – символьное устройство, – блочное устройство, и т. д.). Соответствие числа, его двоичного представления и прав доступ можно представить в виде таблицы:

Число	Двоичный вид	Права доступа
000	Нет прав
1	001	Только выполнение (x)
2	010	Только запись (w)
3	011	Запись и выполнение (wx)
4	100	Только чтение (r)
5	101	Чтение и выполнение (rx)
6	110	Чтение и запись (rw)
7	111	Чтение, запись и выполнение (rwx)

Выдав права на выполнение, можно выполнить скрипт:

Первая строка в скрипте содержит текст . Пара символов называется Шеба́нг (англ. shebang) и используется для указания интерпретатору, с помощью какой оболочки выполнять указанный скрипт. Это гарантирует корректность исполнения скрипта в нужной оболочке в случае, если у пользователя будет указана другая.

Также в скриптах можно встретить строку . Но, как правило, /bin/sh является ссылкой на конкретный shell, и в нашем случае /bin/sh ссылается на /bin/dash, поэтому лучше явно указывать необходимый интерпретатор. Вторая строка содержит команду , результат работы которой мы видим в приведенном выводе.

Принцип работы межсайтового скриптинга

Ключевая цель XSS — украсть куки пользователя с помощью встроенного на сервер скрипта. После получения этих данных злоумышленник проводит их выборку, сортировку, а затем использует для дальнейших атак и взломов с применением уже другого программного обеспечения и подходов. При этом, атака выполняется не напрямую, а через «дыры» (уязвимости) сайта, на который заходят пользователи-жертвы. При этом, атакованный сайт становится по сути невольным соучастником преступления.

XSS-атаки безопасны для сервера, где располагается сайт, но несут угрозу непосредственно посетителям этого сайта. Но случается и такое, что злоумышленнику удается украсть данные администратора зараженного ресурса и, как следствие, он получает полный доступ к админке и содержимому сайта. Кроме того, если поисковые системы обнаружат на сайте вредоносный код, этому проекту 100% грозит пессимизация. 

Типы XSS-уязвимостей

Не все уязвимости XSS одинаковы, их существует множество типов. Здесь перечислены типы и способы их взаимодействия:

Рисунок 3. Типы XSS-уязвимостей

Уязвимости, вызванные кодом на стороне сервера (Java, PHP, .NET и т. д.):

Традиционные XSS-атаки:

1. Отраженные (непостоянные). Отраженная XSS-атака срабатывает, когда пользователь переходит по специально подготовленной ссылке. Эти уязвимости появляются, когда данные, предоставленные веб-клиентом, чаще всего в параметрах HTTP-запроса или в форме HTML, исполняются непосредственно серверными скриптами для синтаксического анализа и отображения страницы результатов для этого клиента, без надлежащей обработки.
2. Хранимые (постоянные). Хранимые XSS возможны, когда злоумышленнику удается внедрить на сервер вредоносный код, выполняющийся в браузере каждый раз при обращении к оригинальной странице. Классическим примером этой уязвимости являются форумы, на которых разрешено оставлять комментарии в HTML-формате.

Уязвимости, вызванные кодом на стороне клиента (JavaScript, Visual Basic, Flash и т. д.):

Также известные как DOM-модели:

1. Отраженные (непостоянные). То же самое, что и в случае с серверной стороной, только в этом случае атака возможна благодаря тому, что код обрабатывается браузером.
2. Хранимые (постоянные). Аналогичны хранимым XSS на стороне сервера, только в этом случае вредоносная составляющая сохраняется на клиентской стороне, используя хранилище браузера.

Уязвимости, вызванные инфраструктурой (браузер, плагины, сервера и т. д.):

Встречаются очень редко, но являются более опасными:

1. Инфраструктура на стороне клиента. Происходит, когда вредоносная составляющая производит какие-либо манипуляции с функционалом браузера, например с его XSS-фильтром и т.п.
2. Инфраструктура на стороне сервера. Возникает, когда веб-сервер некорректно обрабатывает запросы, позволяя модифицировать их.
3. Сеть. Происходит, когда возможно внедриться в связь между клиентом и сервером.

Уязвимости, вызванные пользователем:

1. Само-XSS. Часто происходит в результате социальной инженерии, когда пользователь случайно запускает вредоносный код в своем браузере.

How to prevent XSS attacks

Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity of the application and the ways it handles user-controllable data.

In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:

• Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
• Encode data on output. At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
• Use appropriate response headers. To prevent XSS in HTTP responses that aren’t intended to contain any HTML or JavaScript, you can use the and headers to ensure that browsers interpret the responses in the way you intend.
• Content Security Policy. As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.