xss уязвимость
Угрозы xss атак с применением javascript
Прежде чем начать, стоит оговориться, что данный материал несет исключительно информационный характер.
Что такое xss атака?
Это такой тип атак, который внедряет в веб-системы вредоносный код, заставляя её выдавать измененные данные, подменяет ссылки (видимые/скрытые) или выводит собственную рекламу на пораженном ресурсе.
Существует два направления атак:
Пассивные – которые требуют непосредственного вмешательства субъекта атаки. Суть заключается в том, чтобы заставить жертву перейти по вредоносной ссылке для выполнения «вредокода». Такой тип атак более сложный в реализации, ведь необходимо обладать не только техническими, но и психологическими знаниями.
Активные – это вид атак, когда хакер пытается найти уязвимость в фильтре сайта. Как же реализуется такая атака? Все очень просто. Нужно при помощи комбинации тегов и символов создать такой запрос, чтобы сайт его понял и выполнил команду. Как только дыра в безопасности найдена, в наш запрос можно вложить «вредокод», который, к примеру, будет воровать cookie и пересылать в удобное нам место. Приведем пример скрипта, ворующего “печеньки” с сайта:
Обычно приходится серьезно потрудиться, чтобы найти дыру в безопасности сайта, ведь большинство фильтров достаточно устойчивы. Но их пишут люди, а им свойственно ошибаться.
Правила безопасности
Откуда и почему вообще возникают подобные уязвимости, которые приводят к катастрофическим последствиям? Все дело во внимательности и знании людей. Разработчики должны писать правильный код, поэтому в этом разделе мы расскажем про минимальные правила безопасности написания сайтов.
Как применяется атака, мы уже рассказывали, но повторимся еще раз. Вся суть xss атаки — это обнаружение дыры в фильтре с целью его обхода.
1. Одно из самых первых и основных правил для разработчика – это применение любого (хотя-бы самого минимального) фильтра.
В проведенном нами исследовании сайтов почти все они были защищены, но все же находились и те, которые не использовали никакой фильтрации получаемых данных. В основном, это встречается на сайтах, написанных на языке PHP. Но, например, в фраемворках python, таких как: flask или Django уже есть встроенные минимальные фильтры, их остается только усилить.
2. Фильтрация символов и вложенных конструкций.
Минимальный фильтр защитит нас от любительских атак и неграмотных специалистов, но от серьезных хакеров нужно строить более серьезную защиту, с более детальной фильтрацией данных. Разработчики должны учитывать и понимать возможную реализацию xss атаки и строить фильтр таким образом, чтобы он распознавал вложенные конструкции. Например, хакер может создать многоуровневую конструкцию, и в самый нижний из них вложить вредоносный javascript код. Фильтр будет блокировать верхний уровень, но нижний будет выполняться.
3. Фильтр должен учитывать всевозможные комбинации символов.
Одной из наших любимых проверок на xss уязвимость является использование открытых и закрытых скобок.
Например: “/?,#”>>>><
Что такое XSS-уязвимость и как тестировщику не пропустить ее
По моему наблюдению довольно много тестировщиков когда-либо слышали такое понятие, как XSS-уязвимость. Но мало кто может просто и на пальцах рассказать на собеседовании про нее. Или эффективно проверить веб-сайт на наличие этой уязвимости. Давайте вместе разберемся со всем этим подробнее и попробуем сами найти несложную XSS-уязвимость на демо-странице, которую я специально подготовил к этой статье.
Если вы гуру тестирования безопасности и на раз-два участвуете в баунти-программах крупных IT-компаний, а количество найденных вами XSS исчисляется десятками или даже сотнями — можно смело проходить мимо этой статьи. Если же вы новичок в теме и только начинаете интересоваться поиском уязвимостей — добро пожаловать под кат.
Определение
XSS (англ. Cross-Site Scripting — «межсайтовый скриптинг») — довольно распространенная уязвимость, которую можно обнаружить на множестве веб-приложений. Ее суть довольно проста, злоумышленнику удается внедрить на страницу JavaScript-код, который не был предусмотрен разработчиками. Этот код будет выполняться каждый раз, когда жертвы (обычные пользователи) будут заходить на страницу приложения, куда этот код был добавлен. А дальше существует несколько сценариев развития.
Первый: злоумышленнику удастся заполучить авторизационные данные пользователя и войти в его аккаунт.
Второй: злоумышленник может незаметно для жертвы перенаправить его на другую страницу-клон. Эта страница может выглядеть совершенно идентично той, на которой пользователь рассчитывал оказаться. Но вот принадлежать она будет злоумышленнику. Если пользователь не заметит подмены и на этой странице введет какие-то sensitive data, то есть личные данные, они окажутся у злоумышленника.
Третий… да в общем-то много чего еще можно придумать. Почти все, что может JavaScript, становится доступным для злоумышленника. Чуть ниже мы рассмотрим подробнее один из таких примеров. А пока давайте попробуем чуть подробнее обсудить, как именно устроена уязвимость. И почему злоумышленнику удается внедрить свой код в чужое приложение без доступа к его исходникам.
Небольшое предупреждение. Вся информация далее представлена исключительно в информационных целях. Тестировщик должен уметь проверять свое веб-приложение на уязвимости. Однако, использование XSS-уязвимостей на чужих ресурсах является незаконным.
Если говорить про действующее российское законодательство, когда исследователь тестирует чужой продукт на предмет уязвимостей или проникает в чужую сеть без ведома и согласия владельца, его действия могут быть расценены как неправомерные.
Как устроена уязвимость?
Прежде всего, как именно удается внедрить на страницу JavaScript-код, которого там раньше не было? И как получается распространить этот код среди других пользователей?
Например, можно добавить JavaScript-код в поле ввода, текст из которого сохраняется и в дальнейшем отображается на странице для всех пользователей. Это может быть поле для ввода информации о себе на странице профиля социальной сети или комментарии на форуме.
Злоумышленник вводит текст (и за одно вредоносный код), который сохраняется на странице. Когда другие пользователи зайдут на эту же страницу, вместе с текстом они загрузят и JavaScript-код злоумышленника. Именно в момент загрузки этот код отработает. Конечно, уязвимость сработает, только если текст при сохранении не будет обезопасен. О том, как это сделать, и почему разработчики иногда забывают об этом, поговорим чуть позже.
Это лишь самый простой и очевидный пример того, где может быть спрятана уязвимость. Более интересный пример мы с вами чуть ниже рассмотрим на специально подготовленной демо-страничке.
А пока давайте двигаться дальше.
Почему такие ошибки часто встречаются на веб-проектах?
Суть в том, что браузер не может самостоятельно отличить обычный текст от текста, который является CSS, HTML или JavaScript-кодом. Он будет пытаться обрабатывать все, что находится между тегами
В случае, если страница является уязвимой, после ввода этого кода на странице появится вот такое окошко:
Оно и будет означать, что наш JavaScript-код исполнился и мы нашли XSS-уязвимость.
Итак, вводим код и видим следующее предупреждение:
Форма не позволяет нам осуществить поиск по такому значению, так как форма валидируется и хочет работать только с буквами и цифрами. На первый взгляд кажется, что разработчик все учел и защитил страницу от XSS, но это не совсем так.
Помните, чуть выше мы с вами заметили, что текст, который мы вводим в поле поиска, отображается в URL в так называемом GET-параметре? Имя этого параметра “q”, а значение — то, что мы вводим в поле поиска. Это сделано для того, чтобы можно было скопировать URL вместе с этой самой строкой поиска и в следующий раз открыть страницу сразу с нужными авторами.
Например, вот такой URL откроет страницу сразу только с книгами Рея Брэдбери: playground.learnqa.ru/demo/xss?q=Рей+Брэдбери
В отличие от формы, валидацию URL разработчик сделать не мог — любой пользователь в своем браузере может ввести любой URL, какой захочет, в том числе и с любым значением GET-параметра. Задача разработчика в этом случае — не забыть учесть все варианты и написать правильный обработчик значения этого GET-параметра.
Проверим, не забыл ли наш разработчик все учесть тут. Попробуем в GET-параметр “q” подставить тот самый JavaScript-код: https://playground.learnqa.ru/demo/xss?q=
Перейдя по этому URL мы видим, что на странице появилось окошко со значением 123. Но почему?
Все довольно просто. Помните, когда сайт не может найти нужные книги по заданному поисковому запросу, он текст этого поискового запроса выводит в тексте ошибке? Мол, не нашли ничего по запросу “бла-бла”. Вот вместо этого “бла-бла” у нас теперь JavaScript-код с алертом. Разработчик написал валидацию поля ввода и решил, что так он защитил сайт от того, чтобы JavaScript мог оказаться в поисковом запросе. И не стал экранировать текст ошибки. Нам же удалось обойти валидацию через URL, поменяв там значение поискового запроса.
Ради интереса теперь можем вывести значение нашей сессионной cookie, для этого вместо в URL надо подставить другой код:
С этим я уже предоставлю поиграться вам самостоятельно. 🙂
Найдя ошибку, стоит обратиться к разработчикам — они ее исправят.
Способов закрыть ошибку довольно много. Экранировать текст — не единственный из них. Еще можно запретить самому JavaScript видеть некоторые cookie. Для этого у cookie есть специальный параметр “http only”. Если он выставлен в TRUE, JavaScript никак не сможет узнать, что такая cookie вообще выставлена и не сможет ее прочитать и передать злоумышленнику даже в том случае, если ему удастся найти XSS на вашем проекте.
Все это — лишь малый, далеко не полный список манипуляций, предотвращающий XSS-уязвимости. Как писалось выше — при обнаружении XSS в ходе тестирования лучше всего пообщаться с программистами.
Если Вам интересно знать больше про тестирование безопасности, хочется лучше разобраться в устройстве клиент-серверной архитектуры, понять и отточить самые эффективные способы поиска уязвимостей на настоящем веб-приложении, приходите на мой курс “Тестирование безопасности”. Вся необходима информация есть в моем профиле.
Вас ждет только полезная и нужная теория без воды и большое количество практических примеров и заданий. Вы будете исследовать множество веб-страниц, напичканных самыми разными уязвимостями. Итоговой работой станет большое исследование либо вашего рабочего проекта, либо одного из веб-приложений таких гигантов как Google, Facebook, Twitter и так далее.
Опции JVM. Как это работает
-XX:+DoEscapeAnalysis
Начну, пожалуй, с самой интересной опции — DoEscapeAnalysis. Как многие из Вас знают, примитивы и ссылки на объекты создаются не в куче, а выделяются на стеке потока (256КБ по умолчанию для Hotspot). Вполне очевидно, что язык java не позволяет создавать объекты на стеке на прямую. Но это вполне себе может проделывать Ваша JVM 1.6 начиная с 14 апдейта.
Про то, как работает сам алгоритм можно прочитать тут (PDF). Если коротко, то:
Для реализации данного алгоритма строится и используется так называемый — граф связей (connection graph), по которому на этапе анализа (алгоритмов анализа — несколько) осуществляется проход для нахождения пересечений с другими потоками и методами.
Таким образом после прохода графа связей для любого объекта возможно одно из следующих следующих состояний:
После этапа анализа, уже сама JVM проводит возможную оптимизацию: в случае если объект NoEscape, то он может быть создан на стеке; если объект NoEscape или ArgEscape, то операции синхронизации над ним могут быть удалены.
Следует уточнить, что на стеке создается не сам объект а его поля. Так как JVM заменяет цельный объект на совокупность его полей (спасибо Walrus за уточнение).
Вполне очевидно, что благодаря такого рода анализу, производительность отдельных частей программы может возрасти в разы. В синтетических тестах, на подобии этого:
скорость выполнения может увеличится в 8-15 раз. Хотя, на казалось бы, очевидных случаях из практики о которых недавно писалось (тут и тут) EscapeAnalys не работает. Подозреваю, что это связано с размером стека.
Кстати, EscapeAnalysis как раз частично ответственен за известный спор про StringBuilder и StringBuffer. То есть, если Вы вдруг в методе использовали StringBuffer вместо StringBuilder, то EscapeAnalysis (в случае срабатывания) устранит блокировки для StringBuffer’а, после чего StringBuffer вполне превращается в StringBuilder.
-XX:+AggressiveOpts
Опция AggressiveOpts является супер опцией. Не в том плане, что она резко увеличивает производительность Вашего приложения, а в том смысле, что она всего лишь изменяет значения других опций (на самом деле, это не совсем так — в исходном коде JDK довольно не мало мест, где AggressiveOpts изменяет поведение JVM, помимо упомянутых опций, один из примеров тут). Проверять измененные флаги будем с помощью двух команд:
После выполнения разница в результатах выполнения команд выглядела так:
| -AggressiveOpts | +AggressiveOpts | |
|---|---|---|
| AutoBoxCacheMax | 128 | 20000 |
| BiasedLockingStartupDelay | 4000 | 500 |
| EliminateAutoBox | false | true |
| OptimizeFill | false | true |
| OptimizeStringConcat | false | true |
Иными словами, все что делает эта опция — изменяет 5 данных параметров виртуальной машины. Причём, для версий 1.6 update 35 и 1.7 update 7 никаких отличий замечено не было. Данная опция по умолчанию отключена и в клиентском моде ничего не изменяет.
Расcмотрим, что же java подразумевает под агрессивной оптимизацией:
-XX:AutoBoxCacheMax=size
Позволяет расширить диапазон кешируемых значений для целых типов при старте виртуальной машины. Эту опцию я уже упоминал тут (второй абзац).
-XX:BiasedLockingStartupDelay=delay
Как известно, synchronized блок в java может быть представлен одним из 3-х видов блокировок:
Так как большинство объектов (синхронизированных) блокируются максимум 1 одним потоком, то такие объекты могут быть привязаны (biased) к этому потоку и операции синхронизации над этим объектом внутри потока сильно удешевляются. Если к biased объекту пытается получить доступ другой поток, то происходит переключение блокировки для этого объекта на thin блокировку.
Само переключение относительно дорого, поэтому на старте JVM существует задержка, которая по умолчанию создает все блокировки как thin и если никакой конкуренции не обнаружено и код используется одним и тем же потоком, то такие блокировки, после истечения задержки, становятся biased. То есть, JVM пытается на старте определить сценарии использования блокировок и соответственно использует меньше переключений между ними. Соответственно, выставляя BiasedLockingStartupDelay в ноль, мы рассчитаем на то, что основные куски кода синхронизации будут использоваться лишь одни и тем же потоком.
-XX:+OptimizeStringConcat
Тоже довольно интересная опция. Распознает паттерн на подобии
и вместо постоянного выделения памяти под новую операцию конкатенации, идет попытка вычислить общее количество символов каждого объекта конкатенации для выделения памяти только 1 раз.
Иными словами, если мы вызовем 20 раз операцию append() для строки длинной 20 символов. То создание массива char произойдет один раз и длиной 400 символов.
XX:+OptimizeFill
Циклы заполнения/копирования массивов заменяются на прямые машинные инструкции для ускорения работы.
Например, следующий блок (взято из Arrays.fill()):
будет полностью замен на соответствующие процессорные инструкции на подобии сишных memset, memcpy только более низкоуровневых.
XX:+EliminateAutoBox
Исходя из названия, флаг должен как-то уменьшать количество операций автобоксинга. К сожалению, я до конца так и не смог выяснить, что же делает этот флаг. Единственное, что удалось прояснить, что применяется это только к Integer оболочкам.
-XX:+UseCompressedStrings
Довольно спорная опция по моему убеждению… Если в далеких 90-х разработчики java не пожалели 2 байта на символ, то сегодня такая оптимизация смотрится довольно нелепо. Если кто не догадался, то опция заменяет в строках символьные массивы на байтовые, где это возможно (ASCII). По сути:
Таким образом возможна существенная экономия памяти. Но в виду того, что меняется тип, появляются накладные расходы на контроль типов при определенных операциях. То есть, с этой опцией возможна деградация производительности JVM. Собственно поэтому опция по умолчанию и отключена.
-XX:+UseStringCache
Довольно загадочная опция, судя по названию она должна каким-то образом кешировать строки. Как? Не понятно. Информации нету. Да и по коду похоже она ничего не выполняет. Буду рад, если кто-то сможет прояснить.
-XX:+UseCompressedOops
Для начала несколько фактов:
Данная опция позволяет уменьшить размер указателя для 64-х разрядных JVM до 32-х бит, но в этом случае размер кучи ограничен 4 ГБ, поэтому, в дополнение к сокращенному указателю, используется свойство о кратности 8 байтам. В результате получаем возможность использовать адресное пространство размером 2^35 байт (32 ГБ) имея указатели в 32 бита.
Фактически, внутри виртуальной машины, мы имеем указатели на объекты, а не конкретные байты в памяти. Понятное дело, что из-за подобных допущений (о кратности) появляются дополнительные расходы на преобразование указателей. Но по сути это всего лишь одна операция сдвига и суммирования.
Помимо уменьшения размеров самих указателей, эта опция уменьшает также заголовки объектов и разного рода выравнивания и сдвиги внутри созданных объектов, что позволяет в среднем уменьшить потребление памяти на 20-60% в зависимости от модели приложения.
То есть, из недостатков имеем лишь:
Так как для большинства приложений опция несет одни плюсы, то начиная с JDK 6 update 23 она включена по умолчанию, так же как и в JDK 7. Детальней тут и тут.
-XX:+EliminateLocks
Опция, которая устраняет лишние блокировки путем их объединения. Например следующие блоки:
будут преобразованы соответственно в
Таким образом сокращается количество попыток захвата монитора.
Заключение
700 флагов в одну статью довольно трудно. Я специально не затрагивал опции по тюнингу сборщика, так это довольно обширная и сложная тема и она заслуживает нескольких постов. Надеюсь статья была вам полезной.
Java Blog
Основные опции JVM для повышения производительности и отладки
Если вы являетесь Java-разработчиком или администратором Java приложения, вам поможет в работе знание того, что означают опции JVM, а также их важность и как они влияют на ваше приложение.
Обзор параметров JVM
Какие параметры JVM используются вашим приложением?
Если приложение работает в Linux, вы можете использовать
для идентификации процесса Java и просмотра параметров JVM, напечатанных как аргументы процесса. Если в системе выполняется более одного Java-процесса, вам может потребоваться использовать ключевое слово, уникальное для вашего Java-приложения.
Если ваш аргумент слишком длинный, попробуйте использовать
так как эта команда также покажет длинный список аргументов.
Имея список флагов JVM, вы можете получить представление о поведении любого Java-приложения, например Tomcat.
1. Размер кучи (heap) Java
2. Задание процента кучи
3. Включить обмен данными класса
4. PermGen размер
Кстати, стоит понимать, что пространство PermGen занято Metaspace в Java 8, и этот параметр неприменим, если вы работаете с JRE 8 JVM.
5. Распечатать GC (Garbage Collector)
Эти параметры JVM используются для включения ведения журнала сбора мусора, что очень эффективно для чувствительной к задержке операции. Обычно работа идет в системах, где ведется поиск задержек в микросекундах, но большая сборка мусора может длиться несколько миллисекунд.
Эта удобная опция подскажет вам важную статистику GC. Станет известно, будет ли это большая или небольшая сборка мусора, какой тип сборщика мусора применяется, как часто восстанавливается память, сколько времени он занимал и т.д.
6. Обработка ошибки «OutOfMemory»
Эта опция JVM создает дамп стека, когда ваша JVM завершается с ошибкой OutOfMemory. Там нет никаких затрат, если ошибка OutOfMemory действительно не происходит. Этот флаг является обязательным для производственных систем, поскольку обычно это единственный способ глубоко определить проблему.
Дамп кучи будет установлен в «текущем каталоге» JVM по умолчанию. Если вы хотите создать дамп кучи в определенном каталоге, запустите
Файл дампа кучи может быть огромного размера, вплоть до гигабайт, поэтому убедитесь, что целевая файловая система обеспечивает достаточную емкость.
Если мы хотим перезапустить сервер сразу после возникновения нехватки памяти, мы можем установить этот параметр с той же целью:
7. Trace загрузки классов и выгрузки
8. Java classpath (путь к классу)
Помещение class в bootclasspath также снижает стоимость, но его следует использовать только тогда, когда вы знаете, что классы проверялись много раз раньше. В JRuby это сократило время запуска вдвое и более для простого скрипта.
9. Профилирование
10. 64-битная среда
В среде ОС, в которой установлены 32- и 64-разрядные пакеты, JVM автоматически выбирает 32-разрядные пакеты среды по умолчанию.
Java XSS:
Examples and Prevention
StackHawk | April 30, 2021
Let’s see what cross-site scripting (XSS) is, how it works in Java, and understand how we can prevent this type of vulnerability.
Security is one of those areas in software development where it’s really important you get it right. At the same time, it’s often easy to get it wrong, especially in teams that suffer from not-invented-here syndrome and refuse to adopt the best practices and state-of-the-art tools that would prevent many issues from happening. Today we’re here to cover one very specific security problem: Java XSS.
We’ll start by defining XSS, talking very briefly about what it is, its types, and why it can be so dangerous to your applications. After that, we’ll walk you through a list of three XSS examples in Java and show you what you should do to prevent them. Let’s get started.
Java XSS: What’s This? Why Should You Care?
“Java XSS” is simply XSS done to a Java app. So, what’s XSS?
We have another post dedicated solely to answering that question, and we suggest you check it out. Here’s the short version, though.
XSS stands for cross-site scripting. This is a type of attack that explores vulnerabilities in websites and injects malicious client-side scripts that are then executed by users. The malicious inject script can cause many different effects, ranging from mostly harmless to potentially catastrophic. A highly successful XSS attack can give the attacker access to the user’s personal data. It’s even possible to hijack the user’s session by stealing their session cookie, in which case the consequences can be dire.
Java XSS Examples
Web applications might suffer an XSS attack regardless of their back-end language. Java is certainly no exception to that. So, we’ll now walk you through three basic examples of what an attempted XSS attack on a Java app could look like and how to prevent them.
Example #1: XSS Through Parameter Injection
The Code
Here’s what the app’s controller looks like:
Let’s now see our view for this action:
As you can see, what’s happening here is quite simple. The name variable, whose value is what the user has passed as a query parameter, gets concatenated to a message that the view then displays inside a tag. No rocket science going on here.
The Attack
If I run the app and pass my name as a query parameter, that’s what I see:
Pretty unremarkable, right? So, what’s the problem? Well, let’s start by checking whether we can input some HTML:
That’s bad news. We did manage to input HTML code that was parsed and displayed as such. Let’s say we want to run the following line of JavaScript:
Could we do it? Let’s see:
As you can see, the current code is insecure. We’ve managed to sneak in and run a harmless snippet of JavaScript. In the same way, a bad actor could certainly run a harmful script. They could send a URL to unsuspecting users, causing them to click those links, passing the malicious script as a parameter. For instance, the attacker could use a malicious script that steals the user’s cookie, effectively hijacking its session.
How to Prevent This
The example above is what we call a reflected or non-persistent XSS. One action you can take against it is to escape user input. The view in our example has a deliberate error, to allow unescaped content to be displayed as it is. Pay attention to the following line:
In the line above, we’re using the Thymeleaf templating engine to display the greeting in the view. Notice the usage of the utext attribute processor. That stands for unescaped text and is the reason why HTML tags are being displayed. Let’s solve that by changing the attribute to text :
Now, if I try to sneak in a piece of JavaScript, this is what I get:
Mature frameworks such as Spring usually have security features that, when used correctly, should protect your apps against the most common types of attacks. That’s probably one of the best business cases for using third-party tools like frameworks and libraries: the security goodies they often offer by default.
Example #2: Using a Fake Form to Steal User Credentials
The use cases for XSS are virtually infinite. They’re only bound by the attacker’s ingenuity and your app’s vulnerability. Let’s explore yet another scenario, showing how an attacker can create a fake form to steal user credentials by using XSS.
The Code
For this example, we’ll use the same code samples for the previous one, with one change. We’ll change back the th:text Thymeleaf attribute to th:utext so we can get away with providing HTML tags as inputs.
The Attack
For this attack, the attacker wants to inject and display HTML code for a simple form:
Notice that the form’s action attribute points to a URL controlled by the attacker. The idea here is to lure the unsuspecting victim into submitting their credentials using this form. In order to do that, the attacker could simply pass the HTML for the form as a query parameter to the vulnerable site and share that URL with the victim, in what’s called a phishing attack:
This is, of course, a toy example. A real attack would probably make use of styling to make the fake form look as realistic as possible, with the intent of luring more people into the trap.
How to Prevent It
As in the previous example, preventing this attack consists of escaping content so tags aren’t displayed. In the case of Thymeleaf templating language, that means using the safe th:text attribute.
Example #3: XSS Through Forms
For our third and final example, we won’t use a code sample. Instead, we’ll use a demo site that is deliberately insecure against XSS, to allow people to practice. Here’s what the site looks like:
The Attack
To perform the attack, we’ll exploit the comment functionality of the site, which is not protected. Let’s start by clicking on Agenda. Then, I’ll click on any of the talks listed. I’ll see a form that allows me to input a comment:
I’ll enter my name normally. However, my comment will be a JavaScript snippet that displays a message:
After submitting the form, the alert will be displayed:
How to Prevent It
Since this is a demo site and we have no way of knowing which tech stack was used to build it, I’ll offer no prevention sample code in here. Suffice it to say that the same principles apply: Java or otherwise, you must research and adopt mature tools and frameworks that come with built-in features to counter the most common security vulnerabilities.
XSS: More Ways to Prevent It
In this post, we’ve covered some examples of XSS in Java, showing how they can be prevented. We did that after explaining briefly what XSS is about and why it can be such a dangerous threat to the security of your app.
This is the main takeaway from the post: never trust data that comes from outside the application. Always treat any kind of input as suspect until you escape it.
Before escaping, input validation is another valuable strategy when dealing with user input. For some kinds of data, it might make sense to use an “allow-list” approach, where you have a list of the valid data that can be accepted and everything else is denied.
Finally, there are tools at your disposal that can help you not only with XSS but with other types of security threats. You can add those checks to your CI/CD pipeline, allowing you to find threats as early as possible in the software development process.
This post was written by Carlos Schults. Carlos is a consultant and software engineer with experience in desktop, web, and mobile development. Though his primary language is C#, he has experience with a number of languages and platforms. His main interests include automated testing, version control, and code quality.
