Гарет Хейз

Книга продаётся по адресу leanpub.com.

Эта версия опубликована 25 января 2024 года.

© 2024 Gareth Heyes

Пожалуйста, помогите Гарету Хейзу рассказать об этой книге в Twitter!

Предлагаемый текст твита:

Предлагаемый хештег книги: #javascriptforhackers.

Узнайте, что говорят о книге другие люди, щёлкнув следующую ссылку для поиска этого хештега в Twitter:

#javascriptforhackers

Моей семье, без которой я ничто. Я не смог бы сделать это без любви и поддержки своей семьи.

Исследователь PortSwigger Гарет Хейз, вероятно, больше всего известен своей работой по выходу из изолированных сред JavaScript и созданию чрезвычайно изящных XSS-векторов. Когда он не пишет книги в соавторстве (например, недавно вышедшую Web Application Obfuscation^[1]), Гарет воспитывает двух замечательных дочерей, является мужем удивительной женщины и страстным болельщиком футбольного клуба Liverpool.

Работая в PortSwigger, Гарет часто создаёт новые XSS-векторы, исследует новые методы атак на веб-приложения и готовится выступать на конференциях по всему миру, таких как OWASP Allstars Amsterdam 2019, где он представил доклад «XSS Magic Tricks»^[2]. Он также является автором справочника PortSwigger по XSS^[3]. В свободное время он любит писать новые расширения BApp: именно он создал Hackvertor^[4] и Taborator^[5]. Когда Гарет не занимается хакингом, его можно застать за экспериментами с трёхмерным CSS, созданием игр и комнат на чистом CSS и HTML, без JavaScript. Если вам это интересно, загляните на его сайт: garethheyes.co.uk.

JavaScript всегда был моей страстью. Меня завораживают способы, которые помогают глубже понимать JS. Нередко можно увидеть мои твиты о том, как вызывать функции без круглых скобок, о безумных XSS-векторах и вообще о способах глубже разобраться в той или иной возможности языка. Меня часто спрашивают, как приём из твита применить для обхода WAF или эксплуатации браузера. Для меня это не главное. Конечно, способы вызова функций JavaScript без круглых скобок можно использовать для обхода WAF, но смысл моих твитов зачастую в том, чтобы быстро получить знания, которые могут пригодиться позднее.

Один из примеров - [].sort. Метод sort принимает функцию, и я обнаружил, что этим можно злоупотребить для косвенного вызова функции alert; об этом я расскажу позднее. Я пытаюсь, так сказать, взломать собственный мозг, чтобы эти векторы стали для меня достаточно важными и запомнились. Вы увидите, что я публикую варианты одного и того же приёма, и мне, безусловно, помогает то, что сам поиск таких приёмов доставляет мне удовольствие. Как часто бывало, что вы читали книгу или статью, но прочитанное не укладывалось в голове? Ища способы взломать JavaScript, вы изучаете его возможность, а затем применяете полученные знания ради достижения цели. Неважно, какова эта цель: наличие ориентира помогает запомнить материал.

Такие методы на самом деле применимы практически к чему угодно, и это, по сути, здравый смысл. Возьмём спорт: нельзя стать лучше, просто читая о нём. Нужно применять знания, тренироваться и заниматься самим спортом.

С хакингом JS дело обстоит очень похоже. В повседневной работе вам никак не удастся пользоваться всеми возможностями JS, но, пытаясь его взломать, вы можете выбирать, какую возможность изучать. В этом и состоит моя философия, и именно об этом данная книга. Я постараюсь научить вас следовать этому подходу, быстро учиться и при этом получать удовольствие от своих занятий.

Чтобы следовать этому процессу, нужна быстрая среда для проведения экспериментов. Иными словами, вам требуется нечто, где можно выполнить код и мгновенно получить результат. Вариантов множество: консоль браузера, локальный веб-сервер или веб-приложение вроде JSFiddle. Лично я решил написать собственное веб-приложение Hackvertor, наделив его возможностью вычислять код, исследовать объекты и выводить HTML, однако другие варианты тоже вполне подходят. Мне просто хотелось большей мощности и уверенности в том, что введённые мной данные нигде не записываются. Как минимум ваша среда должна уметь вычислять JavaScript и возвращать результаты.

Настроив выбранную среду, следует поставить цель. Без цели можно так и просидеть перед пустой страницей, никуда не продвинувшись. Цель заставляет вас постоянно что-то пробовать, причём она может меняться. Например, одной из моих целей было «выполнить JavaScript без круглых скобок». Хорошая цель почти наверняка никогда не исчерпывается и к тому же превращается в другую. Так, упомянутая цель превратилась в «вызывать функции JavaScript без круглых скобок и передавать аргументы». Теперь видно, чем полезны обе цели: у вас есть ясное представление о том, что нужно сделать, и для достижения цели можно использовать возможности JavaScript не по назначению. В данном примере вторая цель сложнее первой, но знания, полученные при достижении первой, позволяют взяться за более трудную вторую.

Фаззинг - один из важнейших инструментов в арсенале хакера JavaScript. Он позволяет очень быстро получать ответы на вопросы и открывать новое, поручая компьютеру сообщать результаты. Фаззинг - это просто написание кода, который перебирает символы, фрагменты кода или данные в поисках интересного поведения. При эксплуатации двоичных программ фаззер применяют для поиска отказа в обслуживании или сбоя, пригодного для эксплуатации, но при хакинге JavaScript задача состоит в достижении цели путём получения ответов на вопросы. Например, я поставил себе цель понять, какие символы разрешены в качестве пробельных. Вы можете спросить: почему просто не посмотреть в спецификации? При изучении поведения браузера спецификация не должна быть единственным источником сведений, поскольку браузеры порой ей не следуют. Иногда это происходит из-за ошибки, а иногда разработчики сознательно отступают от неё по различным причинам, например ради обратной совместимости.

Фаззинг служит важным инструментом поиска таких интересных пограничных случаев. Возможно, вы спросите, чем они важны. В приведённом примере с пробельными символами я писал синтаксический анализатор и изолированную среду JavaScript. Оказалось, что при разборе JavaScript пробельные символы имеют большое значение и могут позволить выйти из изолированной среды. Обрабатывая их именно так, как это делает браузер, я мог повысить безопасность своей среды. В дальнейшем я покажу, как с помощью фаззинга отвечать на вопросы и обнаруживать интересное поведение.

Хакинг JavaScript очень похож на исследования безопасности веб-приложений: для обнаружения интересного поведения требуется большая настойчивость и немалая удача. Разумеется, знания важны, но настойчивость позволяет расширять их и даёт шанс на удачу. Если вы только начинаете изучать JavaScript и пока знаете немного, принципы этой книги помогут быстро приобрести знания при условии, что вы проявите достаточную настойчивость. Если вы смотрите на пустой экран и совершенно не представляете, что делать, выберите новую цель или упростите нынешнюю, чтобы продолжать двигаться. Не бойтесь пробовать то, что, по вашему мнению, может не сработать. При должной настойчивости время не будет потрачено зря, поскольку по пути к интересным открытиям вы узнаёте множество мелочей. Помните: настойчивость не означает, что нужно всё время упорно заниматься одним и тем же. Можно вернуться к задаче через несколько месяцев и испытать другие методы.

Когда я занимаюсь хакингом JS, я много пользуюсь Twitter. Он полезен тем, что позволяет мгновенно получить как положительные, так и отрицательные отзывы о найденном приёме. По мере роста числа подписчиков вы встретите людей с теми же интересами; они укажут на вариант приёма или на то, что вы упустили. Это замечательно, поскольку учитесь не только вы, но и все, кто видит разговор. Представьте, если бы такой подход применяли все: каждый учился бы очень быстро, и мы обнаружили бы весьма интересные особенности поведения JavaScript. Опубликованное в твите также закрепляется у меня в памяти, а если я что-нибудь забуду, то всегда могу найти конкретный приём поиском в Twitter или в выгруженном архиве своих твитов. Однако важно помнить, что Twitter плохо подходит для долговременного хранения данных. Если вы нашли нечто, чем особенно гордитесь, лучше написать статью в блоге, а затем опубликовать ссылку на неё.

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

Сноски

[1] [назад] amazon.co.uk

[2] [назад] ams.globalappsec.org

[3] [назад] portswigger.net

[4] [назад] portswigger.net

[5] [назад] portswigger.net

Название этой главы обозначает одну из моих любимых целей, потому что в ней скрыта огромная глубина. Её можно разбить на множество подцелей, которые помогут быстро понять возможности JavaScript. Кажется, моя первая попытка выполнить JS без круглых скобок состояла в экспериментах с методом valueOf. Он применяется, когда от определённого объекта требуется получить примитивное значение, например число. Обычно его используют в литерале объекта, чтобы объект мог взаимодействовать с другими примитивами, например участвовать в сложении или вычитании.

Рисунок 18. Использование valueOf()

Это интересно, поскольку valueOf позволяет определить функцию, которая будет вызвана, когда объект используется как примитив. Значит, вместо собственной функции можно просто указать alert, и тогда вызовется она, верно? Не всё так просто. Попробуем и посмотрим, что произойдёт.

Рисунок 19. Использование valueOf для вызова alert() приводит к исключению

В качестве функции, вызываемой методом valueOf, мы задаём alert. Объект участвует в операции сложения, которая вызывает valueOf. Метод valueOf ссылается на функцию alert, но при попытке её вызвать движок JavaScript выдаёт ошибку illegal invocation. Причина в том, что функции alert требуется объект window в качестве this. В нашем случае при вызове alert значением this становится собственный объект obj, поэтому и возникает исключение. Большинство объектов JavaScript наследует от прототипа Object, а valueOf как раз определён в Object.prototype. Следовательно, собственный объект нам не нужен: можно взять существующий, ведь практически у каждого объекта есть valueOf. Догадываетесь, к чему я веду? У самого объекта window есть метод valueOf, и мы можем его переопределить.

Рисунок 20. Использование valueOf для вызова alert()

На этот раз alert вызывается успешно. Мы изменили метод valueOf объекта window, поэтому при вызове valueOf объектом this является window, а ошибка illegal invocation не возникает. Возможно, вы заметили, что запись можно сократить: указывать window. необязательно, поскольку использование объекта window подразумевается. Можно удалить window., и valueOf всё равно будет работать с объектом window. Выше я написал его для ясности, однако на момент подготовки книги работает и следующий вариант.

Рисунок 21. Вызов alert() через valueOf() без window.valueOf

Таким же образом вместо valueOf можно использовать toString.

Рисунок 22. Вызов alert() через toString без window.toString

Это отличное направление для исследований, поскольку могут существовать и другие способы вызова функций.

Теперь немного расширим цель. Вместо простого вызова функции попробуем вызвать её и передать аргументы, совершенно не используя круглых скобок. Однажды во время хакинга JS меня осенило: я вспомнил об обработчике исключений и о том, что ему можно назначить собственную функцию. Если вы не знаете, у объекта window есть глобальный обработчик onerror. Когда вы задаёте его, ваша функция получает все исключения со страницы. Обработчик вызывается с сообщением в первом аргументе, URL во втором, номером строки в третьем, номером столбца в четвёртом и, наконец, объектом ошибки в последнем аргументе. Нас интересует аргумент с сообщением: если мы сможем на него повлиять, обработчик будет вызван со строкой в первом аргументе. Как же вызвать обработчик с выбранным нами аргументом? Разумеется, можно назначить обработчик, а затем вызвать исключение JavaScript. Для этого можно сгенерировать недопустимый код или воспользоваться инструкцией throw.

Инструкция throw позволяет создать новое исключение и задать собственное сообщение об ошибке. Сообщением может служить выражение JavaScript, что позднее окажется важным. Если вы разрабатываете на JavaScript, то, вероятно, знакомы с этой инструкцией и часто видели примерно такой код.

Рисунок 23. Генерация собственного исключения

Как уже сказано, throw принимает выражение, которое не обязано быть объектом. Можно выбросить строку, и она будет передана обработчику ошибок. Таким образом, для вызова функции с аргументами нужно назначить обработчик и выбросить строку, как показано ниже.

Рисунок 24. Злоупотребление throw и onerror для вызова функций с аргументами

По крайней мере в Chrome результатом будет окно alert с текстом Uncaught foo. Возможно, вы спросите, как выполнить произвольный код. Если заменить alert на eval, выброшенное исключение будет вычислено как код. Но тогда остаётся досадное слово Uncaught с пробелом. Чтобы обойти проблему, достаточно внедрить знак равенства: Uncaught превратится в имя переменной при присваивании, и получится допустимый JavaScript.

Рисунок 25. Использование onerror с eval() и throw

Следует учесть, что throw является инструкцией, а потому не может использоваться как выражение. Например, её нельзя поместить в вызов функции.

Рисунок 26. Недопустимое использование throw

Поэтому необходимо следить, где вы её применяете. Если требуется обойти WAF (Web Application Firewall, межсетевой экран веб-приложений), нужно знать, какие символы доступны. Поставим небольшую подцель: как с помощью throw вызвать произвольный JavaScript без точек с запятой? В JavaScript существуют блочные инструкции. Раньше их применяли нечасто, потому что var не имел блочной области видимости, но с появлением let стала доступна блочная область видимости, так что, возможно, блоки станут популярнее. После блочной инструкции точку с запятой ставить не требуется, и это позволяет легко обойти соответствующее ограничение.

Рисунок 27. Недопустимое использование throw

Другой способ обойти ограничение на символы - воспользоваться ASI (automatic semicolon insertion, автоматической вставкой точек с запятой) в JavaScript. Вместо точек с запятой можно поставить переводы строк, и JavaScript вставит разделители автоматически.

Рисунок 28. Переводы строк с throw и обработчиком onerror

В качестве перевода строки JavaScript также поддерживает разделители абзаца и строки. Они чрезвычайно полезны при обходе WAF: последовательность onerror= наверняка будет заблокирована, но регулярные выражения нередко упускают альтернативные символы. Я покажу их через eval, поскольку сами символы отображаются не слишком хорошо.

Рисунок 29. Разделители строки и абзаца с onerror и throw

Управляющая последовательность Unicode \u2029 обозначает разделитель абзаца, а \u2028 - разделитель строки. Оба действуют как новая строка, и везде, где можно поставить перевод строки, можно использовать эти символы.

У инструкции throw есть интересная особенность: ей можно передать выражение, правая часть которого поступит обработчику исключений. Если смысл пока неясен, рассмотрим оператор запятая. Он вычисляет выражения слева направо и возвращает последний операнд. Например, присвоим значение переменной foo и применим оператор запятая.

Рисунок 30. Оператор запятая

Какое значение получит foo? Догадались? baz, поскольку оператор запятая возвращает последнюю часть выражения. Инструкция throw принимает выражение JavaScript, поэтому оператор запятая прекрасно работает и здесь. Этой возможностью можно злоупотребить, чтобы уменьшить число используемых символов и получить неожиданный JavaScript.

Рисунок 31. Оператор запятая и throw

Этот код применяет throw и назначает обработчик onerror, затем использует оператор запятая. Результат выражения 1337 передаётся обработчику исключений, вследствие чего alert вызывается с текстом Uncaught 1337. Можно использовать любое число операндов, пока они входят в одно выражение; обработчику исключений всегда будет передан последний.

Рисунок 32. Оператор запятая и throw с последним выражением

Ещё одна возможность JavaScript - необязательная переменная исключения в предложении catch. Благодаря ей блоки try и catch можно применять без круглых скобок, а затем просто снова выбросить исключение, чтобы вызвать обработчик.

Рисунок 33. try, catch и throw

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

Рисунок 34. try, catch и throw

Приведённый код вызывает alert со значением 1337. Шаблонные строки также поддерживают подстановки, в которые можно встраивать выражения JavaScript. Подстановки обозначаются ${} и могут содержать даже вложенные шаблонные строки.

Рисунок 35. Подстановки в шаблонных строках

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

Рисунок 36. Разделение строк подстановками

Этой возможностью можно воспользоваться для вычисления кода, однако при использовании eval код выполнен не будет.

Рисунок 37. Теговые шаблоны не вычисляются как строка

Догадаетесь, почему? Функция eval просто вернёт массив, не преобразовав переданный ей аргумент в строку. Если взять другую функцию, например setTimeout, которая преобразует аргумент в строку, всё прекрасно сработает.

Рисунок 38. Теговые шаблоны не вычисляются как строка

Но это ещё не всё. Если подстановка вычисляется в строку, строка не добавляется в массив строк первого аргумента, а фактически становится вторым аргументом, следующая - третьим и так далее.

Рисунок 39. Строки из подстановок тегового шаблона

Этой особенностью можно злоупотребить, чтобы вызвать конструктор Function с произвольным JavaScript. Сначала нужно учесть пару обстоятельств. Конструктор Function принимает несколько аргументов. Если передать один, он станет телом функции; если аргументов несколько, телом будет последний. Следовательно, в первом аргументе можно использовать массив строк, который преобразуется в строку и задаёт аргумент создаваемой функции, а в последнем аргументе - результат выражения-подстановки.

Рисунок 40. Строки из подстановок тегового шаблона с конструктором Function

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

Рисунок 41. Строки из подстановок тегового шаблона с конструктором Function и двойным вызовом

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

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

Рисунок 42. Теговый шаблон с setTimeout, который не работает

Причина неудачи в том, что первым аргументом передаётся пустой массив строк, а не функция alert. Придётся искать иной способ выполнить произвольный JavaScript. В первой главе мы изучили apply и call. Здесь с помощью call можно было бы назначить массив строк значением this для функции; тогда первая подстановка стала бы первым аргументом setTimeout. Попробуем и посмотрим, что получится.

Рисунок 43. Теговый шаблон с call

Код не работает, поскольку значением this перестал быть объект window, а в таком случае setTimeout выдаёт ошибку illegal invocation. Если вместо подстановки использовать строку, всё будет в порядке: функции setTimeout передаётся только строка в первом аргументе, второй и третий аргументы отсутствуют, а значением this остаётся объект window.

Рисунок 44. Теговый шаблон с setTimeout без call

Наша подцель - вызвать через подстановки любую функцию, поэтому нужно как-то обойти ограничение, связанное с ошибкой illegal invocation. Для этого рассмотрим способы вызова alert. Мы уже видели, что можно назначить onerror=alert, но какие существуют другие варианты? Если подумать, нужен API JavaScript, который позволяет вызвать функцию, передав ссылку на неё. Тогда функции можно будет вызывать из подстановок. Сначала следует изучить доступные методы. Для этого подойдут консоль, веб-приложение или собственный инспектор. Я выбрал последний вариант и воспользовался написанным мною инструментом Hackability Inspector. Перебирая с его помощью строковые методы, я вспомнил, что функция replace позволяет указать функцию, которая будет вызвана при обнаружении заменяемого совпадения. Если передать ссылку на alert, возможно, replace сможет её вызвать.

Рисунок 45. Функция replace с alert в качестве функции обратного вызова

Выглядит многообещающе. Мы берём строку a, регулярное выражение для её поиска и функцию alert, которая вызывается при обнаружении совпадения. Но есть пара проблем: регулярное выражение должно найти совпадение, а аргументом функции становится само совпадение. К счастью, replace разрешает указывать не только регулярное выражение, но и строку. Следовательно, можно использовать массив совпадений тегового шаблона, который будет преобразован из массива в строку.

Рисунок 46. Функция replace как теговый шаблон

Получилось несколько странно. Из-за преобразования массива в строку приходится передавать ещё и запятую. Как это обойти? Один из способов - через call изменить значение this, что позволит управлять аргументом с совпадением, а для поиска любого символа взять регулярное выражение.

Рисунок 47. Функция replace с call в роли тегового шаблона

Что здесь происходит? Функция replace вызывается через call, вследствие чего значением this становятся строки тегового шаблона, соответствующие 1,. Поскольку применяется call, регулярное выражение передаётся первым аргументом replace; оно совпадает с любым одиночным символом, кроме перевода строки. Затем передаётся ссылка на alert, и в результате alert вызывается со значением 1. Уф. Довольно безумно, правда? Кто бы мог подумать, что шаблонные строки можно использовать таким образом? Попробуйте решить задачу: вызвать alert со значением 1337, а не 1.

С помощью этого приёма и объекта Reflect можно вызвать практически любую функцию с любыми аргументами. Что же такое Reflect? Он позволяет выполнять над любым объектом такие операции, как вызов функции, чтение и запись свойств. Например, его можно применять вместо call и apply, поскольку в нём есть собственный метод apply, позволяющий вызывать функции для любого объекта. Ему просто передаются функция, объект и аргументы, с которыми нужно вызвать функцию. Как уже сказано, Reflect поддерживает и другие операции, но пока сосредоточимся на методе apply.

Рисунок 48. Reflect.apply с call в роли тегового шаблона

Разберём происходящее. Мы передаём вызываемую функцию, в данном случае alert, затем значение this для неё, то есть window, что предотвращает ошибку illegal invocation, и, наконец, массив аргументов, которые хотим передать функции. Как говорилось выше, call нужен, чтобы первым аргументом не оказался пустой массив строк. Метод Reflect.apply не требует определённого значения this и охотно выполняется с любым объектом, назначенным в качестве this.

Аналогично можно выполнять и другие операции, например запись. Метод set объекта Reflect позволяет произвести операцию записи над любым объектом. Продемонстрируем это присваиванием объекту location.

Рисунок 49. Reflect.set с call в роли тегового шаблона

Методу set требуется допустимый объект в первом аргументе, здесь это location, имя свойства во втором и присваиваемое значение в третьем.

Последний приём, который я хочу обсудить, использует символ hasInstance. Символы позволяют создавать уникальные ключи свойств и гарантируют уникальность ключа. Существуют встроенные символы для различных операций. JavaScript применяет их, чтобы не вводить специальные свойства, способные конфликтовать с уже существующим кодом в интернете. Символ hasInstance позволяет настроить поведение оператора instanceof. Если определить этот символ, левый операнд будет передан функции, указанной в символе. Так появляется изящный способ выполнять JavaScript без круглых скобок.

Рисунок 50. Изменение результата оператора instanceof с помощью символа hasInstance

В примере полезная нагрузка задаётся строкой перед оператором instanceof. Затем создаётся литерал объекта с символом hasInstance, которому назначена функция eval. Когда оператор instanceof выполняется со строкой и объектом, строка передаётся eval, после чего вызывается alert. Символ можно использовать таким образом и без квадратных скобок внутри имени свойства.

Рисунок 51. Изменение результата оператора instanceof с помощью символа hasInstance

Эта глава показала, как определить цель и подцели внутри неё. Благодаря этому вы быстро изучали различные возможности JavaScript и не сидели перед пустым экраном. Ясные цели помогают сосредоточиться на интересных возможностях и постоянно учиться. В этой главе мы познакомились с обработчиком onerror и способами злоупотребления им для выполнения JavaScript без круглых скобок, затем перешли к теговым шаблонным строкам и обнаружили удивительное поведение подстановок, которые передают функциям аргументы вместе с их типами, а в завершение рассмотрели символ hasInstance и его применение в хакинге JavaScript.

Когда речь заходит о фаззинге, часто предполагают, что он нужен для обнаружения уязвимостей, пригодных для эксплуатации, или сбоев. Разумеется, фаззинг можно использовать и так, и прежде мне доводилось находить с его помощью уязвимости. Однако фаззинг также позволяет исследовать поведение браузеров, и именно этому посвящена данная глава. Он сэкономит вам немало времени и поможет очень быстро расширить знания JavaScript. Нередко возникает соблазн считать спецификацию источником истины о конкретном поведении JavaScript. Это неверный образ мыслей: у разных браузеров могут быть собственные особенности, не соответствующие спецификации, либо реализация может оказаться ошибочной. Я не призываю отказаться от спецификации. Я лишь советую не принимать её на веру и выяснять истину с помощью фаззинга.

Моим первым опытом фаззинга поведения стал поиск символов, разрешённых в URL с протоколом JavaScript. Сначала я создавал такой URL в атрибуте href ссылки, вручную внедрял HTML-сущности и наводил указатель на ссылку, проверяя, сохранился ли протокол JavaScript. Затем я подумал, что должен существовать способ получше. В то время мне казалось, что лучше всего написать инструмент на серверном языке вроде PHP. Я создал фаззер, который порциями перебирал символы и сообщал результаты. Это происходило в 2008 году, и инструмент нашёл множество интересного.

Рисунок 52. URL JavaScript с сущностями внутри

Это прекрасный пример того, зачем нужен фаззинг: для обнаружения ошибки вручную пришлось бы отредактировать более 56 000 сущностей. И это при условии, что вы хотите проверять только сущности, а не исходные символы. Фаззинг существенно упрощает жизнь. В 2008 году компьютеры были гораздо медленнее нынешних, к тому же у меня был никудышный медленный ноутбук, поэтому приходилось обрабатывать данные порциями. Сегодня компьютеры и браузеры намного быстрее: буквально за несколько секунд можно проверить миллионы символов.

С появлением современных браузеров мой подход к фаззингу изменился: теперь я использую innerHTML и свойства DOM. Необходимы оба варианта, поскольку они идут по разным путям исполнения и дают разные результаты. Предположим, мы хотим фаззить URL JavaScript в современном браузере. Первый способ использует DOM.

Рисунок 53. Фаззинг URL JavaScript

Разберём этот довольно простой код. Сначала создаются массив и ссылка, затем перебираются все возможные кодовые позиции Unicode, которых более миллиона. После этого мы присваиваем href, вставляя символ или символы после строки javascript с помощью функции String.fromCodePoint. Свойство protocol проверяет, действительно ли созданная ссылка использует протокол JavaScript. Поразительно, но браузер завершает операцию за несколько секунд. Если вы, как и я, достаточно стары и помните времена, когда подобное просто вызывало отказ браузера в обслуживании, это особенно впечатляет. Для фаззинга другой части href достаточно переместить подстановку. Проверим начало строки JavaScript, изменив её так:

Рисунок 54. Изменение положения фаззинговой строки

При повторном запуске получаются другие результаты.

Символов гораздо больше. Обратите внимание на NULL в начале: код символа 0 обозначает NULL, если представить его символом. Это особенность пути через DOM, которая не работает в обычном HTML. Именно поэтому необходимо фаззить как DOM, так и innerHTML. Получив интересные результаты фаззинга, прежде всего нужно их подтвердить. Сделать это легко: вручную заново создайте DOM, который проверял фаззер. Выберем случайную кодовую позицию, сгенерируем для неё DOM-код и щёлкнем ссылку, чтобы убедиться в его работоспособности.

Рисунок 55. Символ перевода страницы перед протоколом

Я выбрал кодовую позицию 12, то есть перевод страницы, создал URL JavaScript, вызывающий alert, добавил к ссылке текст и, наконец, поместил её в элемент body. При щелчке ссылка должна вызвать alert; тем самым вы подтверждаете, что фаззинговый код действительно работает. Поэкспериментируйте с разными кодовыми позициями и убедитесь, что всё действует как задумано. Стоит задать себе два вопроса: «Можно ли использовать несколько символов?» и «Можно ли использовать несколько символов в разных позициях?». Ответить на них я оставляю вам в качестве упражнения.

При работе с DOM следует помнить, что HTML-сущности не декодируются при непосредственном изменении свойств, за исключением свойств, относящихся к HTML. Поэтому нет смысла пытаться фаззить HTML-сущности через свойство атрибута href. Для этого потребуется innerHTML. Проверим тот же символ в HTML.

Рисунок 56. Символ перевода страницы перед протоколом

Код работает, поэтому обычно результаты, полученные через DOM, можно применить в HTML с помощью сущностей. Но, как уже отмечалось, есть исключение. Помните NULL в начале? Он работает в DOM, но не в HTML.

Рисунок 57. Нулевая сущность не работает в HTML

Этот код не работает, что ещё раз показывает важность подтверждения результатов и проверки как в DOM, так и в innerHTML либо HTML. Здесь имеется немало возможностей для автоматизации. Чтобы не проверять результаты вручную каждый раз, разумно воспользоваться Puppeteer или другой платформой.

Фаззить можно и URL HTTP, но вместо протокола для проверки успеха следует использовать имя хоста. Как и прежде, цикл for перебирает кодовые позиции Unicode, внедряет символ в href, а затем проверяет совпадение имени хоста с ожидаемым значением.

Рисунок 58. Фаззинг URL HTTP

Код показывает, что URL HTTP поддерживают в начале ровно те же символы, что и URL JavaScript. Снова обратите внимание: символ NULL разрешён в DOM, но не в контексте HTML. Для поиска открытых перенаправлений на стороне клиента, которые могут пригодиться в цепочках ошибок, можно фаззить URL без явного указания протокола. Если вы не знакомы с ними, такие URL позволяют ссылаться на внешний адрес с помощью двух прямых косых черт. Они наследуют протокол текущей страницы: например, если сайт использует https://, URL без явного протокола тоже будет применять его. Проверим, какие символы можно поместить между косыми чертами.

Рисунок 59. Фаззинг URL HTTP

Как видно, между косыми чертами можно помещать пробельные символы, а обратная косая черта действует так же, как прямая.

Мы увидели, как фаззить URL JavaScript, но тот же подход применим и к HTML. API innerHTML позволяет чрезвычайно быстро находить особенности синтаксического анализатора, подобно тому как мы делали это со свойствами DOM. Прежде чем начинать, полезно сформулировать вопрос, который станет целью фаззинга.

Например, я спросил себя: «Какие символы разрешены при закрытии комментариев HTML?». Подумаем, как получить ответ. Если комментарий HTML закрыт, следующий за ним тег должен отображаться. Значит, достаточно проверить через API querySelector, был ли отображён элемент HTML.

Рисунок 60. Фаззинг комментариев HTML

Код очень похож на фаззинг свойств DOM, хотя может выполняться немного дольше, поскольку браузеру приходится делать больше работы. Мы создаём элемент div, снова перебираем все кодовые позиции Unicode, но теперь с помощью innerHTML создаём комментарий HTML. Непосредственно перед закрывающим знаком «больше» внедряется символ Unicode. В исходном объяснении сказано, что, если комментарий закрыт, следующий span не будет отображён, а querySelector вернёт null. Затем автор поясняет, что при обнаружении span результат записывается, чтобы определить успешное закрытие комментария. Я проверил это в Chrome: после двух дефисов комментарий закрывает любой из следующих символов: !-->.

Попробуйте другие браузеры и поэкспериментируйте с перемещением подстановки в разные части закрывающего тега комментария. Несколько лет назад я запускал очень похожий код в Firefox и обнаружил, что перед знаком «больше» можно использовать переводы строк. querySelector можно применять и противоположным образом: проверить, сработал ли открывающий тег комментария, удостоверившись, что следующий span не отображён. Именно этим методом я нашёл другую ошибку разбора Firefox, позволявшую вставлять NULL между дефисами открывающего тега комментария.

Рисунок 61. Фаззинг комментариев HTML после дефиса

Код совпадает с предыдущим, за исключением того, что подстановка находится внутри открывающего тега комментария, а querySelector проверяет отсутствие span. Результат должен быть один: 45, код дефиса.

Если результатов больше, вы нашли ошибку браузера. При таком фаззинге важно удостовериться, что сгенерированная разметка не даёт ложных срабатываний. Обратите внимание на намеренно поставленный знак «больше» после пробела и дефиса. Он не позволяет различным фаззинговым символам поглотить span как часть другого тега. Подобное защитное программирование экономит время.

Если вы не знаете, с чего начать поиск нового поведения браузера, всегда можно фаззить уже известное и искать отклонения. Хорошая отправная точка - пробельные символы. Нужно построить строку, которая будет работать только в том случае, если проверяемый символ является пробельным. Лучший найденный мною способ использует вызов функции. Между идентификатором функции и круглыми скобками разрешены пробелы, поэтому можно определить функцию в блоке try/catch, а затем через eval попытаться вызвать её, поместив добавленный символ между идентификатором и скобками.

Рисунок 62. Фаззинг символов между идентификатором и круглыми скобками

Символов неожиданно много. Правда, опыт доказывает лишь то, что пробельные символы допустимы между идентификатором и круглыми скобками. Для всестороннего фаззинга пришлось бы проверять символ в различных позициях и контекстах. Предлагаю вам сделать это самостоятельно и испытать разные браузеры. Обнаружив неожиданное поведение, вы можете сообщить о нём разработчикам. Для чего годятся такие отклонения? Раньше я использовал их для выхода из изолированных сред JavaScript. Если синтаксический анализатор можно заставить ошибочно лексически разобрать пробельный символ как непробельный, один и тот же JavaScript будет по-разному разобран изолированной средой и браузером либо Node.js.

Можно также фаззить строки парами символов. Перебор пар одинаковых символов обычно выполняется примерно с той же скоростью; замедление начинается при вложенном фаззинге. Возможно, придётся подождать несколько лет, пока оно станет практичным. Фаззить строки довольно легко: используйте пару символов и проверьте, наблюдается ли поведение, подобное строковому. Один из способов - внутри блока try/catch вызвать eval и посмотреть, не перестаёт ли набор случайных символов вызывать исключение, когда окружён проверяемой парой. Это укажет на строкоподобное поведение.

Рисунок 63. Фаззинг строкоподобного поведения

Вы ожидали три символа? Можете назвать ещё один, вызывающий строкоподобное поведение? Конечно, это регулярные выражения. Пара прямых косых черт окружает символы, и исключения не возникает, потому что они воспринимаются как регулярное выражение. Chrome выполняет эту операцию довольно быстро, а Firefox на момент проверки был ужасно медленным.

Тот же принцип позволяет фаззить однострочные комментарии. Подстановки нужно разместить не по краям случайной строки, а перед ней. Найдём однострочные комментарии.

Рисунок 64. Фаззинг однострочных комментариев

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

В завершение раздела мы применим вложенный фаззинг и найдём любопытное поведение комментариев JavaScript, о котором вы, возможно, не знаете. Вложенный фаззинг сложен, поскольку включает гораздо больше символов, а современные браузеры пока недостаточно мощны, чтобы выполнять несколько циклов for по кодовым позициям свыше 0xff. Но если сократить число проверяемых позиций, всё равно можно найти кое-что интересное.

Рисунок 65. Фаззинг однострочных комментариев

На этот раз использованы два вложенных цикла for; ради производительности пришлось, как уже говорилось, ограничить число символов. Затем с помощью fromCodePoint добавляются два символа, по одному из диапазона каждого цикла, а после них помещается мусор, доказывающий, что действует комментарий. В журнал добавляется массив из обоих символов, поскольку для создания комментария необходимы оба. Ожидаемо получились две прямые косые черты, но что это за коды 35 и 33? Это #!. Они образуют однострочный комментарий при условии, что находятся в самом начале выполняемого JavaScript. Результат можно подтвердить, попытавшись выполнить alert при наличии такого комментария.

Рисунок 66. Поведение shebang в JavaScript

Если добавить перед знаком решётки любой символ, код перестанет работать.

Рисунок 67. Shebang работает только в начале

В примере комментарий не работает, если перед знаком решётки имеются какие-либо символы. Вероятно, shebang был добавлен как последовательность комментария потому, что JavaScript применяют в сценариях оболочки с Node.js, где эту строку обычно требуется игнорировать.

Пытаясь взламывать изолированные среды JavaScript, я занялся фаззингом различных управляющих последовательностей, в том числе последовательностей Unicode, рассмотренных во вводной главе. Это привело к обнаружению интересного поведения разных браузеров. Я выяснил, что Safari не выдавал исключение при незавершённых последовательностях Unicode в строках.

Старый Opera, существовавший до перехода на Chromium, также неправильно разбирал последовательности Unicode, переданные eval. При удачном стечении обстоятельств такое поведение позволяет выйти из изолированной среды. Но как его найти? Конечно, фаззингом. Нужно только учитывать контекст проверки и возможную необходимость двойного кодирования. Проведём простой фаззинг последовательности Unicode.

Рисунок 68. Фаззинг управляющих последовательностей Unicode

Код, как и ранее в этой главе, перебирает все символы Unicode. На этот раз определена переменная a, позволяющая выяснить, выдаёт ли eval исключение. Попытка обратиться к неопределённой переменной приводит в eval к исключению, а нам требуется узнать, удалось ли обратиться к a. Мы применяем форму \u{} и экранируем обратную косую черту, поскольку хотим, чтобы последовательность Unicode интерпретировалась функцией eval. В подстановку добавляется фаззинговый символ. Проверка всех символов даёт единственный результат 48, то есть код цифры ноль. Таким образом, исключительно с помощью фаззинга установлено, что данная форма последовательности Unicode допускает ведущие нули.

Фаззить можно не только символы, но и шестнадцатеричные значения, изменив подстановку. У каждого числового литерала есть метод toString, которому можно передать основание системы счисления от 2 до 36. Для шестнадцатеричной записи используется основание 16, поэтому именно его нужно передать, чтобы преобразовать целое число в шестнадцатеричную форму.

Рисунок 69. Фаззинг управляющих последовательностей Unicode

Код перебирает все кодовые позиции и преобразует значение в шестнадцатеричную форму, проверяя, даст ли последовательность Unicode ссылку на переменную. Получаются два результата: коды 97 и 105, соответствующие объявленным нами переменным a и i. Можно сочетать фаззинговые строки с символами и шестнадцатеричными значениями, выясняя, разрешает ли движок определённые символы до, внутри или после шестнадцатеричного значения.

Проверим, разрешает ли движок JavaScript какой-либо символ внутри шестнадцатеричного значения.

Рисунок 70. Фаззинг управляющих последовательностей Unicode в стиле ES6

В коде подстановка добавляет символ перед шестнадцатеричным значением последовательности Unicode. В Chrome получается единственный ожидаемый результат: код 48, то есть цифра ноль. Однако стоит проверить и другие браузеры, чтобы узнать, совпадут ли результаты.

Надеюсь, эта глава научила вас новому умению - создавать фаззинговые векторы. Мы говорили о том, что не следует слепо доверять спецификациям и нужно самостоятельно выяснять, как работает JavaScript. Я показал, как с помощью свойств DOM фаззить URL JavaScript и HTTP. Мы рассмотрели применение innerHTML для исследования разбора HTML. Наконец, мы фаззили известное поведение в поисках отклонений и обнаружили сравнительно малоизвестный вид однострочного комментария JavaScript. После этого мы научились фаззить последовательности Unicode: использовать шестнадцатеричные значения и вставлять символы внутрь сгенерированной записи, чтобы установить, разрешает ли движок JavaScript пробельные или иные символы в управляющей последовательности Unicode.

В этой главе мы будем взламывать DOM, чтобы лучше его понять и, надеюсь, освоить новые, пока неизвестные вам приёмы. Первая цель - получить объект window через DOM. Зачем нам окно? Объект window в браузере и глобальный объект в Node чрезвычайно важны для выхода из изолированных сред: через них можно добраться до глобально определённых функций вроде eval, выполнить произвольный JavaScript и тем самым обойти изоляцию. У объекта window много псевдонимов: frames, globalThis, parent, self, top. Если сайт не открыт во фрейме, parent и top указывают на window. Если открыт, top указывает на самое верхнее окно независимо от того, относится ли оно к другому источнику. Свойство parent, как и следует ожидать, указывает на родительское окно текущей страницы во фрейме. Получить window можно и из узла DOM: document.defaultView хранит ссылку на объект текущего окна. Попробуйте это в консоли браузера.

Рисунок 71. Вызов alert через defaultView

Код получает ссылку на window через свойство defaultView объекта document, а затем вызывает alert. Свойство defaultView имеется только у document, однако существует хитрый способ получить document из узла DOM, а затем обратиться к defaultView. Для этого служит свойство ownerDocument, которое, как подсказывает название, возвращает объект документа, которому принадлежит узел DOM.

Рисунок 72. Доступ к defaultView через ownerDocument

Эти знания позволили взломать немало изолированных сред. Обычно доступ к window блокируется, а обходные пути позволяют получить его снова.

Ещё один способ получить объект окна связан с событиями. При использовании события на узле DOM обработчик определяется с аргументом события. Это сделано из-за того, что во времена широкой популярности Internet Explorer применял глобальную переменную event. Современные браузеры передают событие аргументом обработчика, поэтому при обращении к нему используется локальная переменная. Любопытно, что глобальный объект event существует и сегодня, хотя объявлен устаревшим. В Chrome у каждого объекта события ошибки имелось свойство path: массив объектов, приведших к созданию события. Последним элементом массива был window, и для его получения достаточно было прочитать этот элемент. Здесь удобно применить функцию pop().

Рисунок 73. Получение window через event.path

Впоследствии Chrome удалил свойство path из объекта события. К счастью, вместо него можно использовать стандартизированный метод composedPath(), показанный ниже.

В других браузерах стандартизированный composedPath() возвращает массив, эквивалентный прежнему свойству path в Chrome. Значит, во всех браузерах можно вызвать composedPath, взять последний элемент массива и получить объект window.

Рисунок 74. Получение window через composedPath()

Помните, я говорил, что в каждый обработчик добавляется аргумент с объектом события? Для элементов SVG существует особый случай. Браузер добавляет не event, а evt, поэтому через этот аргумент можно получить объект окна точно так же, как через path или composedPath().

Рисунок 75. Доступ к объекту события в SVG через evt

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

Рисунок 76. Получение исходного кода обработчика onerror

Получится следующий код.

Рисунок 77. Исходный код обработчика onerror

Итак, evt указывает на событие. Похоже, это верно для элементов SVG, но существуют ли другие случаи? Стоит потратить время и поискать их, поскольку такие варианты полезны, когда изолированная среда JavaScript запрещает доступ к объекту события.

Завершая раздел, рассмотрим объект Error и получение объекта window в Chrome через prepareStackTrace. Функция обратного вызова prepareStackTrace позволяет настраивать трассировки стека, что очень удобно для разработчиков. Ей предоставляется функция с двумя аргументами: сообщением об ошибке и массивом объектов CallSite. Объект CallSite содержит свойства и методы, относящиеся к трассировке. Например, флаг isEval показывает, вызван ли текущий CallSite внутри функции eval. Но нас прежде всего интересует получение объекта окна. К счастью, Chrome предоставляет полезный метод getThis() объекта CallSite. Если выполняемый код не определил this, метод вернёт window. Посмотрим на него в действии.

Рисунок 78. Получение объекта window из объекта CallSite

Мы определяем функцию обратного вызова. Она берёт первый объект CallSite из массива, вызывает getThis(), получает объект window, а затем обращается к функции alert() и вызывает её. Функция обратного вызова prepareStackTrace выполняется только при обращении к свойству stack объекта Error.

Когда событие JavaScript выполняется на элементе HTML, браузер помещает выполняемую функцию в области видимости элемента и объекта document. Поэтому можно пользоваться сокращениями и указывать только свойства текущего объекта или document, не записывая полный путь. По сути, браузер делает следующее.

Рисунок 79. Область видимости события

Помните свойство defaultView документа? Внутри события его можно указывать само по себе. Таким образом, для доступа к window достаточно одного этого свойства.

Рисунок 80. Использование defaultView в области видимости события

Это работает благодаря показанным инструкциям with. Выполняя событие, браузер ищет defaultView у элемента изображения. Не найдя его там, он проверяет объект document, где свойство существует, и возвращает document.defaultView. Перебрав свойства document, можно увидеть, что именно доступно. Для этого подойдёт собственный переборщик или простой вызов console.dir(document) в консоли браузера.

Благодаря области видимости события доступны и другие функции DOM. Ниже мы создаём сценарий, добавляем к нему код и помещаем его в документ, ни разу не указывая полный путь через document.

Рисунок 81. Функции DOM в области видимости события

Обратите внимание: здесь используется appendChild(), поскольку по крайней мере в Chrome функция append выдаст исключение, если не указать полный путь. append() принимает строку или узел. В действительности appendChild() выполнится для объекта изображения. Метод имеется и у document, но изображение имеет приоритет, поэтому сценарий будет добавлен к объекту изображения, а не к документу.

В этой главе мы рассмотрели множество интересных вещей. Сначала нашли разные способы получить объект window из узла DOM. Затем изучили области видимости событий DOM и узнали, что каждому событию доступны не только свойства элемента, но и область видимости документа. В завершение мы подробно разобрали перезапись DOM и различные варианты атак, а также убедились, насколько трудно написать фильтр, безопасно обходящий DOM.

Книга о хакинге JavaScript не может обойтись без главы об эксплойтах браузеров, верно? Здесь я расскажу о различных эксплойтах, найденных мною за многие годы. Я занимаюсь хакингом браузеров, главным образом в свободное время, уже более пятнадцати лет. За это время мне удалось обнаружить обход SOP (same-origin policy, политики одинакового источника) или утечку информации в каждом крупном браузерном движке.

Хакинг браузеров - очень узкая область исследований, но он чрезвычайно увлекателен и даёт огромный объём знаний, применимых в других областях. Ошибки рассматриваются не в порядке их обнаружения: мы начнём с простых и постепенно дойдём до более сложных способов обхода SOP.

Эта ошибка была чрезвычайно простой, и меня удивило, что автоматические тесты Mozilla её не обнаружили. Я нашёл её, проверяя окна из других источников: создавал новые окна и исследовал междоменные объекты в консоли браузера или инспекторе Hackvertor. Идея состояла в том, чтобы после вызова window.open получить ссылку на новое окно, изучить объект и проверить, не раскрываются ли данные, которые должны быть недоступны.

Возвращаемое значение window.open - объект нового окна, отличающийся от привычного объекта window. Многие свойства недоступны и при чтении вызывают исключение. Причина очевидна: если открыть окно другого источника и получить доступ ко всем его свойствам, можно украсть данные любого сайта и скомпрометировать все ваши учётные записи.

Эксплойт был до смешного прост: открыть новое окно, подождать пять секунд и попытаться прочитать объект location. Обычно это вызывает исключение, но Firefox разрешал чтение. Поначалу я решил, что проблема связана с одним из методов RegExp, однако оказалось, что достаточно прочитать результат toString() объекта location.

Рисунок 98. Эксплойт Firefox, читающий междоменный объект location

Доказательство концепции открывало новое окно по адресу twitter.com/lists, что приводило к перенаправлению на персонализированный URL. Затем код ждал пять секунд, читал location и извлекал имя пользователя Twitter регулярным выражением. После этого он показывал окно alert, идентифицируя пользователя.

Первоначальное описание ошибки

В прежние времена взламывать браузеры было гораздо легче. Эта ошибка Safari хорошо это показывает. Она связана с изменением имени хоста междоменного объекта location. Проблема в том, что Safari сохранял строку запроса и фрагмент, а они могли содержать конфиденциальные данные. Если бы ошибку нашли сегодня, наиболее вероятной целью стали бы токены OAuth. Для эксплуатации требовалось открыть новое окно или фрейм, дождаться загрузки, изменить имя хоста, а затем прочитать параметры запроса или фрагмент с домена злоумышленника.

Рисунок 99. Safari позволял менять имя хоста междоменного объекта location

Код загружает фрейм, который выполняет некоторую аутентификацию и сохраняет конфиденциальные данные в строке запроса. После перенаправления и загрузки страницы целевого сайта вызывается poc(), получающая ссылку на фрейм, а через неё - объект его междоменного окна.

Через пять секунд злоумышленник меняет имя хоста фрейма на собственный домен, после чего считывает там location.search и крадёт секреты.

Рисунок 100. Чтение свойства location.search

В современных браузерах это уже невозможно: они разумно запрещают чтение и запись свойств host и hostname другого источника.

Я нашёл эту ошибку, когда по контракту с Microsoft проверял различные возможности IE. Мне нравится эта ошибка: она очень проста, но имеет огромные последствия. С её помощью можно было выполнить произвольный JavaScript на любом домене. И снова задействованы окна и фреймы. Ужас какой. Вы уже замечаете закономерность?

IE раскрывал конструктор из другого источника. Иными словами, конструктор Function разрешалось вызывать из другого домена.

Возникает хороший вопрос: как это определить? Убедиться, что внедрение происходит в другом контексте, очень трудно, поскольку браузер не предоставляет соответствующего API. Остаётся попытаться прочитать свойство, которое покажет выполнение кода из другого домена. Одно из таких свойств - document.domain.

Рисунок 101. Доступ к конструктору Function через constructor

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

1. Откройте Hackability.

2. Обратите внимание на доступные для перечисления свойства.

3. Щёлкайте каждое свойство, переходя вглубь объекта.

4. Попытайтесь получить и вызвать конструктор каждого свойства описанным выше способом.

Так я выяснил, что IE раскрывал междоменный конструктор через свойство closed. Поскольку его значение логическое, constructor пришлось использовать дважды: сначала для получения конструктора логического типа, затем - конструктора Function, выполняющего произвольный код. Выполненный код имел полный доступ к междоменному объекту окна, включая файлы cookie и любые свойства DOM. Полный эксплойт выглядел так.

Рисунок 102. Доступ к конструктору Function через constructor

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

Эту ошибку я нашёл сравнительно недавно. К тому времени мне уже удалось взломать каждый крупный браузерный движок, поэтому было приятно найти работающий вариант для Chrome. Ошибка оставалась незамеченной около пяти лет. Она связана с обработкой document.baseURI во вложенных фреймах из разных поддоменов. При обращении к этому свойству из вложенного фрейма Chrome сообщал baseURI родителя. Обычно это несущественно, поскольку объект document междоменного окна недоступен, из-за чего ошибка так долго оставалась скрытой. Однако получить свойство всё же было возможно, и тогда раскрывался полный URL межсайтового фрейма.

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

Я открыл Hackability Inspector, добавил в DOM фрейм и направил его на другой поддомен, где также загрузился инспектор. Теперь обе консоли позволяли проверять правильность защиты междоменных окон. Внутрь междоменного фрейма я добавил ещё один, а затем попытался читать и изменять свойство name этих фреймов. Браузер выдавал исключения, что, конечно, нам не подходило. Тогда я вспомнил, что междоменному фрейму можно назначить другой URL: владельцем фрейма становится источник, выполнивший присваивание.

Я изменил URL вложенного фрейма на about:blank и, к своему удивлению, смог читать и записывать имя окна. Само по себе это ещё не уязвимость, но полезный компонент потенциально более серьёзной ошибки. На такие компоненты стоит обращать внимание.

Затем я стал перебирать свойства междоменного объекта окна вложенного фрейма. Ничего полезного в нём не нашлось, однако я вспомнил, что сведения об URL имеются в document, и начал исследовать его. К моему удивлению, document.baseURI показывало неверный URL.

Вместо about:blank возвращался адрес родителя. Это утечка SOP: одному источнику нельзя читать подобные свойства другого. Сначала я подумал, что ошибка позволяет читать любой домен, но оказалось, что доступны лишь разные поддомены. Уязвимость всё равно серьёзна: например, у почтового клиента может существовать поддомен вложений, которому нельзя разрешать читать другой поддомен.

Свойство baseURI возвращает полный URL, включая строку запроса и фрагмент другого поддомена. Исходная страница содержала следующий код.

Рисунок 103. Утечка родительского URL через baseURI

Ниже показана страница во фрейме. Обратите внимание, что фрагмент изменён и это изменение мог прочитать верхний фрейм другого источника.

Рисунок 104. Изменение URL, демонстрирующее утечку

Первоначальное описание ошибки

В этом случае я сообщил Apple об ошибке, которую компания отвергла как незначительную и непригодную для эксплуатации. Я дождался следующей версии Safari, а затем не спал 23 часа, пытаясь построить эксплойт. Не советую повторять: это вредно для здоровья. Но тогда мне хотелось доказать Apple её неправоту, и я это сделал, что принесло огромное удовлетворение.

Здесь снова используются фреймы, вы ведь уже заметили закономерность, с URL about:blank. После загрузки фрейма я получаю ссылку на его document, а затем записываю в документ ещё один фрейм. Новый фрейм направляется на другой домен; для демонстрации я выбрал Amazon.

Стоит помнить, что это было до появления кликджекинга и тогда во фрейме можно было буквально открыть любой сайт. После загрузки самого внутреннего фрейма я получал ссылку на него из внешнего фрейма. Затем удавалось прочитать cookie Amazon и HTML, полностью обойдя SOP. Вот полный эксплойт.

Рисунок 105. Обход SOP с помощью вложенных фреймов

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

Первоначальное описание ошибки

Это моя любимая из всех найденных мною ошибок браузеров. Она показывает, как обойти SOP совершенно неожиданным способом. Помните, ранее я говорил, что document.domain помогает установить наличие междоменного окна? При обнаружении этой ошибки проверка не сработала: браузер выдал исключение, запрещавшее доступ к объекту. Но на этом всё не закончилось. Я всё равно нашёл способ выполнить произвольный JavaScript в другом домене.

Я начал проверять Opera. Это была версия на Presto, до ответвления Blink. Я пользовался собственным переборщиком Astalanumerator, созданным ещё до Hackability Inspector. Для ваших исследований рекомендую Hackability Inspector. Я создал фрейм с внешним адресом и перебрал все свойства. В contentWindow ничего интересного не нашлось, поэтому я перешёл к междоменному объекту location. Он сразу привлёк внимание: Opera, похоже, раскрывала гораздо больше свойств, чем другие браузеры. Если встретите подобное, это хороший признак возможных ошибок.

Я применил обычный приём constructor.constructor('alert(document.domain)')(), но, к моему удивлению, получил исключение JavaScript. Это необычно: как правило, при наличии конструктора код всё равно выполняется, пусть и в контексте текущего источника. Исключение стало весомым признаком того, что Opera разрешает доступ к междоменному конструктору.

Поразмыслив над исключением, я решил попробовать выражение с числовыми литералами. Если оно не выдаст исключения, значит предыдущий код блокируется из-за вызова alert или доступа к document. И действительно, constructor.constructor('return 1+1')() вернуло 2. Я пришёл в восторг: ошибка уже была найдена, но как выполнить произвольный код в другом домене? Я снова задумался. Если литералы разрешены, возможно, запрещён только доступ к глобальным объектам? Тогда я переопределил метод прототипа Array. Важно, что я лишь определил функцию и не пытался её вызвать. Из консоли браузера я вызвал [].join в другом домене, и тут произошло чудо: появилось прекрасное окно alert с содержимым внешнего домена. Полагаю, именно так чувствуешь себя, забив гол на чемпионате мира. Я был счастлив: SOP Opera оказалась полностью обойдена. Окончательное доказательство концепции выглядело так.

Рисунок 106. Обход SOP с помощью вложенных фреймов

Opera раскрывала конструктор в нескольких местах. Этот эксплойт берёт из междоменного location свойство __defineGetter__. Поскольку оно уже является функцией, несколько обращений к constructor не требуются. Вектор наверняка можно было сократить, например использовать __proto__ вместо constructor.prototype, но я остановился на первой успешной попытке.

Первоначальное описание ошибки

Видео с демонстрацией ошибки

Надеюсь, глава вам понравилась: мне очень понравилось её писать. Я люблю искать изъяны SOP, потому что это серьёзная техническая задача, а успешное открытие вызывает настоящий восторг. Надеюсь, глава вдохновит вас искать собственные ошибки современных браузеров. Мы рассмотрели ошибочную обработку междоменного location в Firefox, которую было элементарно эксплуатировать. Затем поговорили о Safari и о том, почему разрешать присваивание свойствам host или hostname междоменного location - плохая идея. Следующим был IE с изящным полным обходом SOP, позволявшим выполнить произвольный JavaScript на любом домене. После него мы разобрали утечку Chrome и чтение URL разных поддоменов через вложенные фреймы. Затем эксплойт Safari показал, как читать cookie и HTML любого домена. Наконец, я завершил рассказ любимой ошибкой, где методы прототипов позволяли выполнить произвольный JavaScript, когда сайт использовал один из встроенных прототипов.

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

Сноски

[1] [назад] arxiv.org

[2] [назад] portswigger.net

Всё началось с того, что участники форума Slackers заметили удивительную новую публикацию выдающегося японского исследователя безопасности Ёсукэ Хасэгавы. Он подробно объяснил, как выполнять JavaScript без алфавитно-цифровых символов. Для всех нас это стало откровением, и мы принялись разбирать механизм. Основная идея состояла в том, чтобы квадратными скобками и выражениями JavaScript создавать строки, а затем с помощью числовых индексов, тоже построенных из выражений, извлекать и соединять символы. Так получались допустимые имена свойств, а в конечном счёте - произвольный JavaScript без единого алфавитно-цифрового символа. Этот приём также известен как JSF*ck; я скрыл букву u, чтобы в книге не отображалось ругательство. Далее я буду использовать семейное название: «неалфавитно-цифровой JavaScript», или сокращённо неалфавитный JS.

Чтобы построить такой код, прежде всего нужен способ получить число. Благодаря слабой типизации JavaScript это можно сделать префиксным оператором +: он пытается преобразовать следующее за ним выражение в число либо возвращает NaN (Not a Number), если преобразование невозможно. Начнём с нуля.

Рисунок 118. Преобразование пустого массива в ноль

Отлично, ноль получен, но он позволяет взять лишь первый символ строки.

Рисунок 119. Доступ к первому символу строки

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

Рисунок 120. Получение других чисел приёмом с инкрементом

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

Рисунок 121. Получение числа два

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

Теперь можно получить c из нашей строки.

Рисунок 122. Получение символа c

Основы генерации чисел без алфавитно-цифровых символов у нас есть. Как получить строки? Снова воспользуемся слабой типизацией JavaScript и преобразуем в строки значения других типов. Например, из логического false можно извлечь символы f, a, l, s, e. Процесс похож на получение чисел, но применяется оператор логического отрицания. Он возвращает false, если операнд преобразуется в истину, и наоборот. Значит, пустой массив можно преобразовать в логическое значение.

Рисунок 123. Получение false

Теперь логическое значение нужно превратить в строку, чтобы извлекать символы. Просто соединим его с другим массивом: логическое значение станет строкой, а пустой массив - пустой строкой.

Рисунок 124. Создание строки false

Строка получена. Как извлечь символы? Поместим выражение в массив, возьмём первый элемент, то есть строку, а затем по индексу получим отдельный символ.

Рисунок 125. Получение f из false

Остальные символы получаются тем же способом с увеличением индексов. Проще всего подписывать выражения комментариями, как делаю я, а затем объединять их. Следующий символ находится в позиции один. Возьмём фрагмент для единицы.

Рисунок 126. Получение числа один

И строку false из другого примера.

Рисунок 127. Получение строки false

Объединим их: сначала строка false, затем средство доступа с числом.

Рисунок 128. Получение символа a

Пробелы добавлены для ясности. Собирая символы, разумно сохранять их в текстовом файле с комментариями: так из них проще строить строки. Надеюсь, теперь вы уверенно создаёте символы. Получим оставшиеся буквы false.

Рисунок 129. Получение символа l

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

Рисунок 130. Получение символов s и e

При сравнении выражений для s и e видно, что изменение совсем невелико. Весь процесс можно повторно использовать для получения противоположного false значения true. Всё-таки это книга о хакинге JavaScript, и мы обязаны искать сокращения. Оператор ! превращает [] в false; повторное отрицание превращает его в true.

Рисунок 131. Получение true

В ранее построенных примерах достаточно заменить один восклицательный знак двумя. Например:

превращается в:

И так далее:

Символ e уже есть, повторно создавать его не нужно. Теперь вы видите, насколько просто генерировать буквы. Но как получить произвольный JavaScript? Сначала необходим доступ к какой-либо функции. Для этого нужно создать символы, которые в средстве доступа дадут функцию. Затем через свойство constructor этой функции можно получить конструктор Function. Догадываетесь, к чему мы идём? Имея Function, можно создать произвольный JavaScript, но об этом позднее.

Сначала получим функцию. К счастью, из уже созданных символов складывается короткое имя at. Функция at возвращает отдельный символ строки или элемент массива, в зависимости от объекта. Мы выбрали её именно из-за короткого имени. Начнём с пустого массива:

Добавим средство доступа:

Внутрь поместим строку a, соединённую с t:

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

Из ещё не созданных символов слова constructor остаются o, c и n. Символ n можно извлечь из undefined. Сначала создадим пустой массив и обратимся к его первому элементу:

Затем преобразуем результат в строку и возьмём второй символ, расположенный в позиции один:

Остальные буквы для свойства constructor получим через функцию at: преобразуем её в строку, создадим нужные позиции и извлечём символы. Сначала создадим пустой массив и обратимся к первому элементу:

Теперь поместим функцию в массив и соединим с пустым массивом, получая строку:

Эту строку можно использовать для получения c:

Первая строка создаёт строковое представление функции at, вторая обращается к третьей позиции, где находится c. Для o повторим процесс, взяв шестую позицию.

Как детали головоломки, соединим все символы и получим свойство constructor:

Я разделил буквы и поместил между ними оператор соединения строк, чтобы было видно устройство. Вместе они образуют строку constructor. Для получения самого конструктора нужно применить функцию at(), к которой мы получили доступ ранее, не преобразуя её в строку.

Мы объединили функцию at() с последующим средством доступа [], внутри которого находится строка constructor, и получили конструктор Function.

Теперь произвольный JavaScript можно выполнить, передав строку конструктору Function и вызвав результат дважды.

Остаётся создать передаваемую строку. По традиции XSS-нагрузок вызовем alert(1). Буквы и число один у нас уже есть:

Нужно получить открывающую и закрывающую круглые скобки. Возьмём код, где функция at() преобразуется в строку, а затем выбирается шестая позиция:

Увеличим шесть и получим позицию 11:

Увеличим результат ещё на единицу:

Теперь нужно расположить части в правильном порядке, передать их построенному конструктору Function и не забыть оператор + между строками.

Надеюсь, вы следовали за ходом рассуждений и теперь умеете создавать неалфавитный JS. Код можно оптимизировать: например, [![]+[]][+[]] сокращается до (![]+[]). Подобных мест много. В качестве упражнения попробуйте свести выражение к минимальному размеру. Вы ещё лучше изучите JavaScript и вскоре будете писать неалфавитный код как обычный.

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

Как вы уже знаете, шаблонные строки выполняют JavaScript через подстановки и передают аргументы функциям. Этим и воспользуемся, чтобы вызвать конструктор Function со строкой alert.

Код из предыдущего раздела уже даёт доступ к Function, поэтому его можно использовать повторно.

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

Функция вызывается с двумя следующими друг за другом $, а третий аргумент образует код. Первый аргумент преобразуется из массива в строку, поэтому знаки доллара приходится ставить до и после подстановки. Без них конструктор выдаст исключение из-за недопустимого JavaScript. Очень кстати, что $ является допустимым идентификатором JavaScript и может служить именем параметра. Повторно используем прежний код: сначала конструктор Function, затем $, подстановка со строкой alert и ещё один $. Завершающая обратная кавычка вызывает созданную функцию.

После множества экспериментов на форуме Slackers мы пришли к выводу, что для выполнения произвольного JavaScript необходимо как минимум шесть разных символов. Это стало известно как великая стена символов. Ограничение возникает потому, что без ! нельзя создавать логические значения, а без + - преобразовывать значения в целые числа и соединять строки, не добавляя других символов. Самый вероятный путь разрушить стену - взять набор +^[1] и найти способ получить логическое значение. Они важны потому, что false содержит s, а true - r. Без этих букв невозможно построить свойство constructor, а следовательно, получить необходимую строку для доступа к нему.

Чтобы попытаться разрушить стену, потребуется больше символов, иначе доступны только NaN и undefined. Однако даже из одних +[] можно получить Infinity.

Посмотрим как. Сначала, как прежде, создадим единицу, затем строку undefined и возьмём из неё e. После этого присоединим ещё несколько единиц и получим строку 1e1111, которая превращается в Infinity.

Исходник сначала повторяет фрагмент получения шестой позиции строкового представления at:

Сначала получим единицу:

Затем строку undefined:

Извлечём из undefined символ e:

Объединим части в 1e1111:

Наконец, преобразуем массив или строку в число префиксным +, заключим в массив и обратимся к строковому представлению:

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

В этой главе мы научились создавать числа средствами неалфавитно-цифрового JavaScript, получать с их помощью строки, извлекать из строк дополнительные символы через свойства и преобразование результата в строку. Затем я показал, как собрать эти части и выполнить произвольный JavaScript. После этого мы создали неалфавитный код без круглых скобок. Наконец, вы познакомились с великой стеной символов и способом получить Infinity, используя только +[].

Сноски

[1] [назад] В исходнике после символа + стоит маркер сноски 1, но текст сноски на странице отсутствует.

Эта глава целиком посвящена межсайтовому выполнению сценариев, ласково называемому XSS, хотя само название не слишком осмысленно. XSS может быть хранимым и выполняться на том же сайте, а сценарий между разными источниками может не быть межсайтовым. Но название прижилось, и теперь, к лучшему или худшему, все понимают, о чём речь. Я рассмотрю несколько, возможно, неизвестных вам приёмов XSS и объединю методы из предыдущих глав, чтобы получить интересные полезные нагрузки. Приступим.

Первый приём помещает закрывающий элемент script внутрь строки JavaScript. В сообществе XSS он хорошо известен, но разработчик мог с ним не сталкиваться. Представьте отражение данных внутри строки JavaScript, где внедрённая кавычка правильно экранируется, а знаки «меньше» и «больше» - нет. Для эксплуатации внедрите в строку закрывающий тег script. Он закроет блок сценария и из-за незавершённой строки вызовет исключение JavaScript, после чего можно внедрить собственный HTML и получить XSS в целевом приложении.

Уязвимость можно закрыть, экранировав прямую косую черту обратной. Это помешает закрытию script, однако далее мы увидим, что исправление не лучшее. Надёжнее кодировать знаки «меньше» и «больше» управляющими последовательностями Unicode, чтобы HTML внутри строки не отображался. Разумеется, обратные косые черты и кавычки тоже необходимо экранировать или кодировать.

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

В действительности браузер отображает следующее:

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

Можно подумать, что правильное экранирование предотвращает XSS внутри блоков сценария. Но с SVG всё иначе. Поскольку SVG является форматом XML, сущности внутри него декодируются; после обработки SVG JavaScript получает правильные незакодированные символы.

Казалось бы, блоку сценария всегда требуется закрывающий тег. По крайней мере в Firefox это неверно: внутри SVG элемент script может быть самозакрывающимся.

Нужен именно атрибут href, поскольку мы находимся в SVG, а не HTML, и src там не поддерживается.

Ещё один распространённый приём XSS использует window.name для скрытой передачи полезных нагрузок между доменами или страницами. Браузеры ограничивают его, удаляя имя при междоменной навигации верхнего уровня, но с фреймами метод по-прежнему работает.

Тем же способом можно спрятать cookie и получить их после перехода на подконтрольную страницу.

Недавно я обнаружил, что полезную нагрузку можно скрыть через свойство protocol объекта location. Этот метод лучше нагрузки в имени окна, поскольку не требует отдельной страницы. В JavaScript свойству protocol присваивается javascript. URL начинает обрабатываться как JavaScript, часть http:// воспринимается как комментарий, а перевод строки во фрагменте или запросе позволяет выполнить произвольный JS.

К сожалению, браузеры исправили этот замечательный трюк. Сначала Safari пытался блокировать переводы строк, но разработчики забыли о разделителях абзаца и строки, которые тоже действуют в JavaScript как новые строки. Некоторое время в Safari работало следующее:

В последней версии это исправлено. Может быть, вы найдёте другой способ?

Карты исходного кода дают интересный способ вызвать DNS- или HTTP-взаимодействие и вывести данные. При внедрении внутрь однострочного комментария запрос карты позволяет вывести данные, стоящие после комментария. Есть одна проблема: у жертвы должны быть открыты DevTools. Впрочем, это можно обратить в свою пользу: обратный запрос почти наверняка означает, что DevTools действительно были открыты. Работает это так:

При вычислении комментария браузер запрашивает карту исходного кода. Приём работает также в eval() и других функциях. Потребуется внеполосный инструмент, например Burp Collaborator или Interactsh, поскольку DevTools не показывает запрос на вкладке Network.

Chrome добавил новый способ клиентского перенаправления: navigation.navigate(). Метод принимает URL JavaScript, поэтому способен вызвать произвольный код. Достаточно передать ему URL JavaScript или HTTP.

JavaScript поддерживает целый набор синтаксических форм комментариев. Однострочных разновидностей несколько:

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

Закрывающий комментарий HTML тоже разрешён в JavaScript и в начале строки действует как однострочный. Но поскольку последовательность потенциально разбирается как декремент и операция «больше», внутри произвольного выражения или инструкции она не поддерживается. Любой однострочный комментарий продолжается до символа новой строки: возврата каретки, перевода строки, разделителя абзаца или разделителя строки.

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

JavaScript поддерживает несколько символов, разделяющих инструкции: возврат каретки, перевод строки, разделитель строки и разделитель абзаца.

Если внедрение находится в однострочном комментарии, а WAF блокирует новую строку, стоит попробовать эти альтернативные символы.

В JavaScript много пробельных символов, и они помогают обходить примитивные WAF, которые регулярными выражениями ищут ключевые слова вроде eval. Ниже простой способ найти пробельные символы; в результат входят также новые строки, возврат каретки и разделители строки и абзаца.

Можно использовать исходные символы либо закодировать их как HTML-сущности, если они находятся в SVG или атрибутах HTML:

JavaScript позволяет динамически загружать модуль через import(). Это выражение похоже на обычную функцию, но движок JavaScript сам решает, действительно ли загрузка необходима. В нём можно указывать URL импорта, включая URL данных, который выполняет произвольный JavaScript.

Если вы управляете XML-файлом с типом содержимого text/xml, выполнить JavaScript всё равно можно, добавив пространство имён XHTML.

Без пространства имён браузер отобразит код как XML в соответствующем режиме просмотра. Но стоит добавить пространство имён к img, и он будет отображён как XHTML.

Это полезно при загрузке файлов или контроле ответа REST API с типом содержимого XML.

Веб-приложения часто разрешают загружать изображения, но многие забывают, что документы SVG могут содержать сценарии. В отличие от SVG внутри HTML, документ SVG с правильным MIME-типом разбирается строже. Необходимо добавить верный атрибут пространства имён и соблюдать правила XML, например заключать все атрибуты в кавычки.

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

Современный браузер не должен отображать такой SVG. Но есть оговорка: при встраивании через элемент <use> он всё равно будет отрисован.

Как отмечалось выше, документ SVG можно встроить через элемент <use> и получить выполнение JavaScript, если документ находится в том же домене. Допустимы и URL данных:

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

Вынужден сообщить, что в современном браузере это больше не работает: URL данных для элементов use теперь ограничены. Наверное, разработчики браузеров читают эту книгу =).

Возможно, вам встречалась XSS-инъекция в атрибуте скрытого input, где угловые скобки закодированы. Из-за малого числа событий, работающих со скрытыми полями, вызвать alert могло не получиться. Не бойтесь: способ существует, хотя требует активного участия пользователя. Ключом служит accesskey, назначающий элементу клавишу и вызывающий события при её нажатии. Атрибут предназначен для доступности и навигации с клавиатурой или экранным диктором, но годится и для XSS.

В следующем примере скрытому полю назначены клавиша X и событие onclick.

При нажатии Alt+Shift+X в Windows или Ctrl+Alt+X в OS X событие onclick срабатывает, хотя поле скрыто. Это работает и с другими элементами, например link:

Chrome и Firefox поддерживают поведение, но сочетание клавиш может различаться. Я указал клавиши Chrome.

Chrome добавил увлекательную возможность HTML под названием Popovers. Она создаёт всплывающие модальные окна только средствами HTML, фактически наделяя HTML состоянием и открывая новые XSS-векторы.

Имеются цель всплывающего элемента, то есть модальное окно, и ссылка либо кнопка, указывающая на него.

У кнопки задан popovertarget, связывающий её с модальным окном. У div есть идентификатор всплывающего элемента и атрибут popover, который превращает элемент во всплывающий и скрывает его. После щелчка кнопки div показывается с сообщением Hello world!.

Чем это полезно для XSS? Возможность вводит новые события и позволяет выполнять их на любом теге, потенциально запуская JavaScript даже из meta и других элементов.

Добавим к модальному div событие и посмотрим на onbeforetoggle:

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

Недавно я написал об этом в блоге, и мой друг Марио Хайдерих заметил, что события работают даже со скрытыми полями ввода.

Можно было бы ожидать, что скрытые поля нельзя превращать во всплывающие элементы, но Chrome это разрешает; возможно, разрешат и другие браузеры. Это полезно, когда внедрение находится в скрытом input, а угловые скобки кодируются. Можно нацелиться на существующий всплывающий элемент страницы, при условии что точка внедрения расположена раньше, и выполнить JavaScript через onbeforetoggle, когда пользователь щёлкнет существующую кнопку или ссылку.

Матиас Карлссон также отметил, что всплывающие элементы работают с meta. Обычно большинство событий на meta выполнить нельзя, но благодаря Popovers доступны ontoggle и onbeforetoggle, если на странице имеется существующий всплывающий элемент.

В этом вымышленном приложении существующий код позволяет подписаться на рассылку и показывает диалог через всплывающий элемент. Кроме того, внутри атрибута meta имеется уязвимость внедрения. Угловые скобки кодируются, поэтому можно добавлять только атрибуты. Но тег meta находится раньше, что позволяет перехватить существующий всплывающий элемент. В результате onbeforetoggle сработает при щелчке существующей кнопки Subscribe to my newsletter.

В этой главе мы рассмотрели очень многое. По сути, я постарался выгрузить из головы все вспомнившиеся малоизвестные приёмы и ответы на вопросы из Twitter. Сначала мы узнали, как закрывать сценарии без закрывающего тега, затем злоупотребляли комментариями HTML внутри сценариев и сущностями HTML внутри SVG, передавали полезные нагрузки и cookie через window.name. Мы научились отправлять обратный запрос на сервер злоумышленника с помощью карт исходного кода. Потом продемонстрировали новый приёмник JavaScript navigate(), работающий в Chrome. Далее разобрали все комментарии и пробельные символы JavaScript, динамический импорт с URL данных и получение HTML внутри документа XML. Затем рассмотрели загрузку SVG и элементы use, после них - сущности HTML, а в завершение - несколько малоизвестных событий JavaScript.