Using CodeQL to detect client-side vulnerabilities in web applications

GitHub’s CodeQL is a robust query language originally developed by Semmle that allows you to look for vulnerabilities in the source code. CodeQL is known as a tool to inspect open source repositories, however its usage is not limited just to it. In this article I will delve into approaches on how to use CodeQL for web application audits, specifically to discover client-side vulnerabilities.

The idea of CodeQL is to treat source code as a database which can be queried using SQL-like statements. There are lots of languages supported among which is JavaScript. For JavaScript both server-side and client-side flavours are supported. JS CodeQL understands modern editions such as ES6 as well as frameworks like React (with JSX) and Angular.

CodeQL is not just grep as it supports taint tracking which allows you to test if a given user input (a source) can reach a vulnerable function (a sink). This is especially useful when dealing with DOM-based Cross Site Scripting vulnerabilities. By tainting a user-supplied DOM property such as location.hash one can test if this value actually reaches one of the XSS sinks, e.g. document.innerHTML or document.write().

Обзор атак на клиента с помощью CSS

css-resetCSS (Cascading Style Sheets) – язык разметки для оформления внешнего вида веб-страниц, отделяющий визуальное представление от содержания. Первая спецификация формата была опубликована организацией W3C в 1996 году. Тогда CSS позволял делать самые простые вещи: покрасить блок текста цветом, оформить текст курсивом, выравнять абзац, сделать рамку. Сегодня CSS стал настолько сложным, что для него создают фреймворки (bootstrap, jQuery UI) и метаязыки (SASS, SCSS, LESS), которые позволяют упростить написание стилей с помощью увеличения уровня абстракции CSS.

Бурное развитие CSS привлекло внимание исследователей безопасности, что вылилось в ряд техник, позволяющих проводить атаки на клиента с целью украсть его персональные данные: CSRF-токены, историю посещений сайтов, списки email-контактов и т.д. Начнем обзор с классических векторов, которые еще не потеряли свою актуальность.

Универсальный XSS-вектор

Поиск XSS довольно трудоемкое занятие, так как необходимо учитывать множество контекстов, в которых может выполниться js-код, например внутри одинарных или двойных кавычек, внутри различных атрибутов и т.д. Для тех, кому надоело перебирать возможные варианты, пригодится следующий универсальный xss-вектор, который выполнится в любом контексте, т.е. его можно поместить в любой параметр и не беспокоится о том, в какой участок кода он в конечном счете попадет:

javascript:/*--></marquee></script></title></textarea></noscript></style></xmp>">[img=1]<img -/style=-=expression&#40&#47;&#42;’/-/*&#39;,/**/eval(name)//&#41;;width:100%;height:100%;position:absolute;behavior:url(#default#VML);-o-link:javascript:eval(title);-o-link-source:current name=alert(1) onerror=eval(name) src=1 autofocus onfocus=eval(name) onclick=eval(name) onmouseover=eval(name) background=javascript:eval(name)//>"

Размер немного великоват (428 байт), но это в любом случае более продуктивный вариант, чем "><script>alert()</script>.
Для удобного использования в Opera можно добавить данный вектор как заполнитель формы (Меню – Настройки – Общие настройки – Формы), для Firefox с плагином TamperData можно создать новый элемент контекстного меню для перехватываемых пакетов.

Credits: Gareth Heyes @ thespanner.co.uk

Презентация способов обхода XSS фильтров на BlackHat

BlackHatЕжегодно проводимая конференция BlackHat является одним из самых значимых событий в сфере информационной безопасности. В этом году эксперты из множества стран собрались в Лас Вегасе, чтобы показать и обсудить результаты своих исследований. Разумеется, не обошли стороной веб-безопасность – наиболее интересное выступление дали Эдуардо Вела (Eduardo Vela) и Дэвид Линдсэй (David Lindsay) на тему реализации XSS-атак в условиях WAF. Были затронуты практически все самые известные программные продукты, связанные с защитой от XSS как на стороне сервера, так и клиента: PHP-IDS, Mod_Security, XSSFilter в IE8, NoScript. Наиболее слабым оказался Mod_Security, поэтому авторы доклада рекомендуют использовать PHP-IDS вместо него. XSSFilter, изначально неспособный защитить от всех типов XSS (по словам разработчиков из MS в силу производительности браузера), также был повержен несколькими новыми XSS-векторами. На уровне клиента докладчики посоветовали использовать Firefox+NoScript, хотя и для последнего были найдены способы обхода. Ознакомиться с материалами выступления можно на сайте одного из авторов. Презентация получилась немалой – более 100 страниц. Много внимания уделено новым XSS-векторам, некоторые из которых просто поражают воображение. Только взгляните:

(É=[Å=[],µ=!Å+Å][µ[È=-~-~++Å]+({}+Å) [Ç=!!Å+µ,ª=Ç[Å]+Ç[+!Å],Å]+ª])() [µ[Å]+µ[Å+Å]+Ç[È]+ª](Å)

($=[$=[]][(__=!$+$)[_=-~-~-~$]+({}+$)[_/_]+($$=($_=!''
+$)[_/_]+$_[+$])])()[__[_/_]+__[_+~$]+$_[_]+$$](_/_)

За этим, казалось бы, беспорядочным набором символов кроется всем известный javascript:alert(1);. Кроме того, показаны примеры XSS, которые могут возникнуть в будущем с внедрением HTML5, а также уязвимость в PHP-функции utf8_decode(), позволяющая эксплуатировать неправильную обработку UTF-8. В целом, доклад, если не инновационный с точки зрения способов обхода, то уж точно приносящий много пищи для размышления, как разработчикам, так и взломщикам.

XSS Rays – браузер как сканер XSS

Небезызвестный Gareth Heyes сегодня опубликовал свою новую утилиту для сканирования сайтов на наличие XSS. Особенность его разработки заключается в том, что процесс сканирования производится браузером атакующего при помощи javascript. Алгоритм довольно прост: javascript-код рекурсивно собирает все ссылки и формы со страниц сайта и проводит различные тесты, используя встроенную базу векторов. XSS Rays способен совершать кроссдоменные вызовы благодаря использованию тэгов iframe вместо AJAX. Для логирования результатов сканеру требуется локальный веб-сервер с PHP. Реализация сканера в контексте браузера, по словам разработчика, способствует повышению точности и качества конечного результата, хотя ложные срабатывания не исключены. Для использования XSS Rays необходимо лишь открыть страницу http://localhost/XSS_Rays/helpers/bookmarklet.html и сохранить ссылку в закладки. Сканирование сайта производится по клику на букмарклет и нажатию на CTRL+SHIFT+X.
XSS Rays

Активная XSS на FeedBurner

Feedburner.com – один из самых популярных среди блогеров сервисов для управления RSS-фидами. Доверие к feedburner вызывает тот факт, что этот сервис был приобретен Google и в настоящее время находится во владении интернет-гиганта. Тем не менее, у сервиса есть проблемы с безопасностью, в чем я недавно убедился. Просматривая статистику своего блога на feedburner.com, неожиданно получил javascript алерт с содержимым своих Cookie. Сначала я подумал, что это какие-то неаккуратные тесты разработчиков, однако, просмотрев исходный код страницы, обнаружил алерт в том месте, где выводилась информация о Referer пользователей, посетивших сайт. Видимо кто-то специально обратился к моему блогу с <script>alert(document.cookie)</script> в Referer, но не подозревая, что в статистике Feedburner этот HTTP-заголовок не фильтруется.
feedburnerxss
Уязвимость имеет место в статистике посещений сайта, однако для ведения этой статистики администратору необходимо установить специальный JS-код в исходник своего блога. Таким образом, XSS подвержены только те пользователи сервиса, у которых данная опция включена.
feedburner
Пока уязвимость не устранили, рекомендую блогерам снять на время галку с этого пункта. Учитывая, что это возможно неединственная уязвимость на фидбернере, также советую воспользоваться плагином NoScript для Firefox.

CSRF у вас дома

Умные дома с интеллектуальными системами управления могут иметь веб-интерфейс. Более того, веб-контроль некоторых умных домов может быть уязвим к тем же атакам, которые проводят на обычные веб-приложения. В этом я сегодня убедился, прочитав любопытный пост вот на этом блоге. Автор рассказывает как его друг, который живет во Франции, однажды показал ему веб-интерфейс управления своим домом. Выяснилось, что веб-приложение, отвечающее за контроль освещения рождественской елки уязвимо к CSRF, с помощью которой атакующий мог включать/выключать елку =) Кроме того, веб-приложение также содержало активную XSS, что давало возможность управления всем домом.

Как ни странно, в выдаче гугла нашелся еще один умный дом с таким же веб-интерфейсом. Автор предположил, что каждый раз, когда гуглбот проходил по ссылке, в доме включался или выключался свет =)

Надеюсь, разработчики подобных решений задумаются о безопасности своих веб-приложений, иначе клиенты этих компаний будут в панике продавать свои умные дома, рассказывая о поселившихся в них приведениях =)

С наступающим!

Методы обхода httpOnly

httpOnly – это дополнительный флаг для HTTP-заголовка Set-Cookie, который указывает на запрет чтения/записи данных Cookie посредством JavaScript, отсюда и название: Cookie доступны только через протокол HTTP. Использование httpOnly позволяет веб-разработчикам установить собственную политику безопасности в отношении доступа к Cookie из среды браузера, что по замыслу разработчиков из Microsoft должно помочь в борьбе против XSS-уязвимостей. Однако обойти ограничения httpOnly довольно просто…