Как я уже писал в Twitter, недавно я начал дополнительный проект по фаззингу API AWS. Это был логичный, следующий шаг к моей предыдущей работе по этой теме. Для его поддержки мне пришлось создать собственную библиотеку для ручного создания запросов API AWS и их изменения. Я думаю, что это был бы очень плодотворный путь исследования, однако, во время фаззинга, я подписался на услугу за 36 000 долларов в год, которую я не мог отключить. В конце концов, проблема была решена (большое спасибо всем, кто помогал / предлагал помощь. Это был тяжелый опыт), но я пока воздержусь от фаззинга API AWS по очевидным причинам.
Хорошая новость заключается в том, что до этого полного фиаско, даже несмотря на то, что библиотека еще даже не была построена, она нашла ошибку, и этот writeup является ее объяснением. Об этом было сообщено через программу раскрытия уязвимостей AWS, и теперь она исправлена. Спасибо Питеру и Патрику из AWS Security за то, что терпели все мои электронные письма!
Обнаружение
Как вы понимаете, фаззинг API AWS - непростая задача. Существуют сотни сервисов AWS и тысячи возможных действий. Это в сочетании с множеством параметров, каждый протокол имеет разный формат, разные регионы, разные версии и все типы входных данных, которые мы хотели бы использовать, делает это очень трудоемким.
Чтобы усугубить эту сложность, я отправляю законный трафик в API, который, в свою очередь, может создавать ресурсы, которые будут стоить денег (примечание авторов: этот раздел был написан до вышеупомянутого инцидента. Это было преуменьшением). В результате я, как ястреб, слежу за панелью биллинга и удаляю все, что создается. Я также просматривал консоль AWS в поисках чего-то неладного.
Во время этих проверок я обнаружил сообщение об ошибке в истории изменений Elastic Beanstalk
Интересно. В то время, однако, я как бы отмахнулся от этой фразы, сказав «Странно, я могу сломать часть консоли AWS», и продолжал работать над библиотекой фаззинга. Я даже разместил фотографию в Твиттере (если вы были одним из двух людей, которым она понравилась до того, как я ее удалил; спасибо). Однако после небольшой работы меня осенило: «Имеет ли это значение для безопасности?» (Да, я правильно понимаю? Мастер-хакер за работой).
Итак, что такое
Это сразу же вернуло ответ. В строке 17240 файла
Пройдясь отладчиком, стало ясно, что страница истории изменений загружает события из CloudTrail и отображает их. Для справки, вот как это должно выглядеть (взято отсюда).
Функция истории изменений в Elastic Beanstalk - довольно новая функция (выпущенная в январе 2021 года), которая позволяет вам видеть изменения в конфигурациях ваших EB-сред.
Это не отвечает на вопрос, почему
Наконец-то мы нашли виновного, но что мы могли сделать с нашей новой обнаруженной ошибкой? Следующим логичным шагом, было немного исследовать ошибку.
HTML Инъекция
Из JavaScript было очевидно, что у нас есть высокая степень контроля над двумя значениями. Это user agent и environmentName. Вдобавок оказалось, что эти значения вставлялись непосредственно в DOM.
На ум приходят атаки Cross-Site Scripting (XSS), но AWS обычно очень хорошо очищает контент перед его отображением в браузере. Это было то, с чем я столкнулся на собственном опыте, когда возился с SSM Agent. В результате я решил, что любой вредоносный контент будет очищен до показа.
Чтобы проверить это, я собрал простую полезную нагрузку тега неработающего изображения (я намеренно установил источник на «x»). Мне нравится использовать это как тест, потому что он дает мне хороший визуальный индикатор, если он отображается, иначе я бы просто увидел закодированное значение.
Я изменил свой фреймворк, установил user agent на полезную нагрузку, нажал «Отправить» и стал ждать. Подождав 10 минут, я обновил консоль и был ошеломлен.
Это действительная HTML-инъекция в Консоль AWS! Следующий шаг, будет ли работать XSS? Изменил полезную нагрузку, отправил и подождал несколько минут. Плохая новость: нет выполнения JavaScript. Причина? Политика безопасности контента (CSP) заблокировала меня. Если вы не знакомы, вы можете думать о CSP как о инструкции, где ваш браузер может загружать определенные ресурсы. JavaScript может загружаться из одних доменов, шрифты могут загружаться из других и т.д
Хотя CSP не устраняет причину атак с использованием межсайтовых сценариев, он может смягчить последствия. В этом случае CSP заблокировал встроенные скрипты, что привело к сбою полезной нагрузки XSS.
Просматривая CSP для консоли, я не мог найти способ обойти это. Это оставило нас с HTML-инъекцией, что немного разочаровало. Не могли бы вы устроить какой-нибудь тупой фишинг или схему социальной инженерии? Да, возможно. Это удобно, но только в том контексте, в котором он был обнаружен в консоли AWS. Я думаю, что наиболее реалистично вы могли бы попытаться вставить сообщение об ошибке со ссылкой и попытаться обмануть кого-нибудь таким образом.
Интересно то, что вам нужны были только действительные учетные данные, связанные с учетной записью, чтобы это работало. Для этих учетных данных НЕ нужны разрешения Elastic Beanstalk или CloudTrail. На этой панели истории изменений также будут загружаться неудачные попытки. Таким образом, даже если у вас было НУЛЕВЫЕ разрешения для роли или пользователя, ваши попытки обновить среду Elastic Beanstalk будут отображаться.
Инъекция Iframe
Не видя способа обойти CSP, я обратился к друзьям за идеями. Во время разговора с моим другом Крисом (посмотрите его блог на schneidersec.com) он заметил кое-что интересное в разделе iframe.
Политика безопасности контента позволяла загружать фреймы из S3 bucket в том же регионе, что и для консоли. Мы оба были удивлены этим, не могли бы мы просто создать свой собственный bucket и разместить HTML? Мы не понимали, почему нет, поэтому я создал S3 bucket, поместил немного HTML и изменил свою полезную нагрузку, чтобы создать iframe. Это привело к следующему:
Действительно, вы можете загрузить iframe из S3 bucket!
Отправка в AWS
Не видя очевидного способа обойти CSP, я остановился на внедрении HTML / iframe. Было круто? Конечно, я имею в виду, что любая уязвимость в Консоли AWS удобна, но внедрение HTML - пустяк для отчета по тестированию на проникновение. В любом случае, я отправил электронное письмо программе AWS Vulnerability Disclosure вместе со снимками экрана и доказательством концепции (скрипт Python для вставки полезной нагрузки HTML в пользовательский агент для вызова API среды обновления).
Команда безопасности AWS незамедлительно отреагировала и заявила, что направила информацию в сервисную группу. Отсюда я подождал около двух недель и заметил, что у меня больше нет событий на странице истории изменений. «Странно, - подумал я, - может, они просто старые и упали»? Итак, я создал несколько новых событий CloudTrail, но они все еще не появлялись.
«Может быть, теперь у них есть подтверждение на события? Либо для проверки злонамеренного ввода, либо для того, чтобы он влиял на существующую среду? ». Я мог сказать, что код JavaScript, отвечающий за построение таблицы, был изменен, но он был уменьшен, и изменение старого и нового казалось слишком трудоемким для продолжения. Итак, я создал законное приложение и среду Elastic Beanstalk. Пока я делал это, я хотел порыться и посмотреть, подвержены ли какие-либо другие поля HTML-инъекции, и их действительно было несколько. Пара примеров:
Чтобы быть полезным (и, надеюсь, не раздражать), я отправил в AWS еще одно письмо со скриншотами. Разочарованный тем, что мне не удалось снова заполнить историю изменений даже в реальном приложении, я начал убираться. Именно в это время у меня возникла мысль: «Какую версию Angular он использует?»? Я быстро понял, что он использовал AngularJS.
Инъекция шаблона
Осознание того, что страница использует AngularJS, представляет другой тип атаки с использованием инъекций, который мы можем попробовать, - внедрение шаблона на стороне клиента. Атаки с внедрением шаблонов происходят, когда злоумышленник может предоставить свои собственные входные данные на языке шаблонов. Это приводит к тому, что эти входные данные оцениваются в браузере пользователя. Например (в зависимости от формата шаблона) вы можете вставить
После того, как я был достаточно разочарован в себе из-за того, что раньше не осознавал ситуацию с AngularJS, я создал приложение с именем шаблона и обновил браузер.
Мы подтвердили, что он подвержен внедрению шаблона, но что нам делать дальше? Хорошая новость заключается в том, что Гарет Хейес из PortSwigger провел огромные исследования в этой области (1,2).
Короче говоря, мы можем использовать внедрение шаблона как метод для выполнения произвольного JavaScript и получения Cross-Site Scripting! Раньше это требовало некоторой работы, чтобы выйти из песочницы Angular expression, однако в AngularJS 1.6 песочница была удалена. Поскольку мы работали с 1.8.1, нам не нужно было беспокоиться об этом, и вместо этого мы могли использовать следующую полезную нагрузку (взятую отсюда).
Это позволило бы нам запускать традиционную полезную нагрузку XSS для предупреждений, но пройдет ли она политику безопасности контента? На самом деле я не был в этом уверен.
Мой мыслительный процесс здесь заключался в том, что я не внедряю новый тег скрипта, я просто прошу AngularJS оценить выражение шаблона, и, поскольку AngularJS уже разрешен, разве это не сработает? Это ведь не встроенная оценка, верно? Итак, я отправил полезную нагрузку и перезагрузил экран, чтобы меня приветствовали этой мерзкой графикой.
Снова сорвали! Даже если мы попросим AngularJS оценить шаблон, он не даст нам XSS. Есть ли способ обойти Content Security Policy?
Обходим CSP
Удивительно то, что AngularJS можно использовать для обхода CSP! Методология для этого примерно эквивалентна идее, которую я имел в виду, за исключением того, что вместо внедрения шаблона мы собираемся внедрить HTML. Подождите, разве это не шаг в обратном направлении? Вы ещё увидите что нет
Благодаря невероятным исследованиям, опять же, проведенным Гаретом Хейесом, мы заставляем AngularJS оценивать JavaScript с помощью директив. После танцев с бубном я получил следующую полезную нагрузку.
Это позволит использовать директиву
Миссия выполнена! Выкуси CSP! Победный вопль!
Убедившись, что у меня нет галлюцинаций, я сделал несколько снимков экрана и отправил их в AWS.
Заключительные мысли
Я хотел бы отметить пару моментов по этому поводу. Во-первых, я думаю, что это очень интересный сценарий атаки, потенциально переходящий от доступа к API к попытке атаковать пользователей через консоль AWS. Чтобы было понятно, это ОЧЕНЬ редкое обстоятельство. Насколько известно мне (и гуглу), в консоли AWS была обнаружена только одна ошибка XSS, которая была публично раскрыта. Это определенно не та вещь, которую ваше обычное консультант по пентесту может спровоцировать. Но для достаточно искушенного противника в нужной ситуации это может быть очень кстати.
В частности, я думаю, что было очень интересно, что мы могли потенциально установить XSS в истории изменений без каких-либо разрешений. Гипотетический сценарий атаки мог быть следующим: Приземляемся на экземпляр EC2 -> Определяем, что Elastic Beanstalk используется с Resource-Based Policies и определяем для него роль, связанную с сервисом -> Отправляем полезную нагрузку как роль без разрешений EB или CloudTrail -> Ждём -> Получаем профит
Я не понимаю, почему история изменений не функционировала какое-то время. В конце концов он вернулся, и я смог доказать, что могу использовать XSS (см. Снимок экрана выше).
Наконец, небольшой совет для исследователей безопасности; Я определенно понимаю желание сообщить об обнаруженной вами ошибке как можно быстрее. Что, если кто-то другой найдет его и отправит первым? Что, если он будет исправлен в течение следующих 30 минут !? Хотя да, два человека могут одновременно обнаружить одну и ту же ошибку, и возможно, что обнаруженная вами ошибка будет исправлена до того, как вы сообщите об этом разработчикам, это вряд ли произойдет. Вместо этого лучше сесть на это, обдумать все до конца (ПРОВЕРИТЬ ВЕРСИЮ С ANGULAR) и сообщать об этом только тогда, когда вы уверены, что зашли так далеко, насколько это возможно.
От ТС
Gif на форум не грузились, так что я просто переконвертировал их в png.
В переводе могут быть ошибки, так как Web-уязвимости не совсем то, в чём я хорошо разбираюсь.
За оригиналом - сюда
Перевод:
Azrv3l cпециально для xss.pro
Хорошая новость заключается в том, что до этого полного фиаско, даже несмотря на то, что библиотека еще даже не была построена, она нашла ошибку, и этот writeup является ее объяснением. Об этом было сообщено через программу раскрытия уязвимостей AWS, и теперь она исправлена. Спасибо Питеру и Патрику из AWS Security за то, что терпели все мои электронные письма!
Обнаружение
Как вы понимаете, фаззинг API AWS - непростая задача. Существуют сотни сервисов AWS и тысячи возможных действий. Это в сочетании с множеством параметров, каждый протокол имеет разный формат, разные регионы, разные версии и все типы входных данных, которые мы хотели бы использовать, делает это очень трудоемким.
Чтобы усугубить эту сложность, я отправляю законный трафик в API, который, в свою очередь, может создавать ресурсы, которые будут стоить денег (примечание авторов: этот раздел был написан до вышеупомянутого инцидента. Это было преуменьшением). В результате я, как ястреб, слежу за панелью биллинга и удаляю все, что создается. Я также просматривал консоль AWS в поисках чего-то неладного.
Во время этих проверок я обнаружил сообщение об ошибке в истории изменений Elastic Beanstalk
Интересно. В то время, однако, я как бы отмахнулся от этой фразы, сказав «Странно, я могу сломать часть консоли AWS», и продолжал работать над библиотекой фаззинга. Я даже разместил фотографию в Твиттере (если вы были одним из двух людей, которым она понравилась до того, как я ее удалил; спасибо). Однако после небольшой работы меня осенило: «Имеет ли это значение для безопасности?» (Да, я правильно понимаю? Мастер-хакер за работой).
Итак, что такое
b.requestParameters и почему консоль AWS расстроена, что он равен нулю? Что ж, чтобы выяснить это, я собрал все навыки и знания, накопленные за годы моего опыта в разработке программного обеспечения и информационной безопасности до …… Ctrl+F для b.requestParameters в JavaScript (опять же, master hacker на работе).Это сразу же вернуло ответ. В строке 17240 файла
beanstalk-xp_en.min.js (этот номер строки взят из улучшенного вывода JS) была ссылка на b.requestParameters.
Пройдясь отладчиком, стало ясно, что страница истории изменений загружает события из CloudTrail и отображает их. Для справки, вот как это должно выглядеть (взято отсюда).
Функция истории изменений в Elastic Beanstalk - довольно новая функция (выпущенная в январе 2021 года), которая позволяет вам видеть изменения в конфигурациях ваших EB-сред.
Это не отвечает на вопрос, почему
b.requestParameters имеет значение null, что произошло? После отладки было ясно, что он ищет определенный атрибут в событии CloudTrail, а фаззер не предоставил его. Глядя в CloudTrail на это конкретное событие, я, конечно же, не предоставил никаких параметров при попытке действия update-environment, и в результате requestParameters было null.
Наконец-то мы нашли виновного, но что мы могли сделать с нашей новой обнаруженной ошибкой? Следующим логичным шагом, было немного исследовать ошибку.
HTML Инъекция
Из JavaScript было очевидно, что у нас есть высокая степень контроля над двумя значениями. Это user agent и environmentName. Вдобавок оказалось, что эти значения вставлялись непосредственно в DOM.
На ум приходят атаки Cross-Site Scripting (XSS), но AWS обычно очень хорошо очищает контент перед его отображением в браузере. Это было то, с чем я столкнулся на собственном опыте, когда возился с SSM Agent. В результате я решил, что любой вредоносный контент будет очищен до показа.
Чтобы проверить это, я собрал простую полезную нагрузку тега неработающего изображения (я намеренно установил источник на «x»). Мне нравится использовать это как тест, потому что он дает мне хороший визуальный индикатор, если он отображается, иначе я бы просто увидел закодированное значение.
Я изменил свой фреймворк, установил user agent на полезную нагрузку, нажал «Отправить» и стал ждать. Подождав 10 минут, я обновил консоль и был ошеломлен.
Это действительная HTML-инъекция в Консоль AWS! Следующий шаг, будет ли работать XSS? Изменил полезную нагрузку, отправил и подождал несколько минут. Плохая новость: нет выполнения JavaScript. Причина? Политика безопасности контента (CSP) заблокировала меня. Если вы не знакомы, вы можете думать о CSP как о инструкции, где ваш браузер может загружать определенные ресурсы. JavaScript может загружаться из одних доменов, шрифты могут загружаться из других и т.д
Хотя CSP не устраняет причину атак с использованием межсайтовых сценариев, он может смягчить последствия. В этом случае CSP заблокировал встроенные скрипты, что привело к сбою полезной нагрузки XSS.
Просматривая CSP для консоли, я не мог найти способ обойти это. Это оставило нас с HTML-инъекцией, что немного разочаровало. Не могли бы вы устроить какой-нибудь тупой фишинг или схему социальной инженерии? Да, возможно. Это удобно, но только в том контексте, в котором он был обнаружен в консоли AWS. Я думаю, что наиболее реалистично вы могли бы попытаться вставить сообщение об ошибке со ссылкой и попытаться обмануть кого-нибудь таким образом.
Интересно то, что вам нужны были только действительные учетные данные, связанные с учетной записью, чтобы это работало. Для этих учетных данных НЕ нужны разрешения Elastic Beanstalk или CloudTrail. На этой панели истории изменений также будут загружаться неудачные попытки. Таким образом, даже если у вас было НУЛЕВЫЕ разрешения для роли или пользователя, ваши попытки обновить среду Elastic Beanstalk будут отображаться.
Инъекция Iframe
Не видя способа обойти CSP, я обратился к друзьям за идеями. Во время разговора с моим другом Крисом (посмотрите его блог на schneidersec.com) он заметил кое-что интересное в разделе iframe.
Политика безопасности контента позволяла загружать фреймы из S3 bucket в том же регионе, что и для консоли. Мы оба были удивлены этим, не могли бы мы просто создать свой собственный bucket и разместить HTML? Мы не понимали, почему нет, поэтому я создал S3 bucket, поместил немного HTML и изменил свою полезную нагрузку, чтобы создать iframe. Это привело к следующему:
Действительно, вы можете загрузить iframe из S3 bucket!
Отправка в AWS
Не видя очевидного способа обойти CSP, я остановился на внедрении HTML / iframe. Было круто? Конечно, я имею в виду, что любая уязвимость в Консоли AWS удобна, но внедрение HTML - пустяк для отчета по тестированию на проникновение. В любом случае, я отправил электронное письмо программе AWS Vulnerability Disclosure вместе со снимками экрана и доказательством концепции (скрипт Python для вставки полезной нагрузки HTML в пользовательский агент для вызова API среды обновления).
Команда безопасности AWS незамедлительно отреагировала и заявила, что направила информацию в сервисную группу. Отсюда я подождал около двух недель и заметил, что у меня больше нет событий на странице истории изменений. «Странно, - подумал я, - может, они просто старые и упали»? Итак, я создал несколько новых событий CloudTrail, но они все еще не появлялись.
«Может быть, теперь у них есть подтверждение на события? Либо для проверки злонамеренного ввода, либо для того, чтобы он влиял на существующую среду? ». Я мог сказать, что код JavaScript, отвечающий за построение таблицы, был изменен, но он был уменьшен, и изменение старого и нового казалось слишком трудоемким для продолжения. Итак, я создал законное приложение и среду Elastic Beanstalk. Пока я делал это, я хотел порыться и посмотреть, подвержены ли какие-либо другие поля HTML-инъекции, и их действительно было несколько. Пара примеров:
Чтобы быть полезным (и, надеюсь, не раздражать), я отправил в AWS еще одно письмо со скриншотами. Разочарованный тем, что мне не удалось снова заполнить историю изменений даже в реальном приложении, я начал убираться. Именно в это время у меня возникла мысль: «Какую версию Angular он использует?»? Я быстро понял, что он использовал AngularJS.
Инъекция шаблона
Осознание того, что страница использует AngularJS, представляет другой тип атаки с использованием инъекций, который мы можем попробовать, - внедрение шаблона на стороне клиента. Атаки с внедрением шаблонов происходят, когда злоумышленник может предоставить свои собственные входные данные на языке шаблонов. Это приводит к тому, что эти входные данные оцениваются в браузере пользователя. Например (в зависимости от формата шаблона) вы можете вставить
{{ 2 + 2 }}, и результат будет равен 4.После того, как я был достаточно разочарован в себе из-за того, что раньше не осознавал ситуацию с AngularJS, я создал приложение с именем шаблона и обновил браузер.
Мы подтвердили, что он подвержен внедрению шаблона, но что нам делать дальше? Хорошая новость заключается в том, что Гарет Хейес из PortSwigger провел огромные исследования в этой области (1,2).
Короче говоря, мы можем использовать внедрение шаблона как метод для выполнения произвольного JavaScript и получения Cross-Site Scripting! Раньше это требовало некоторой работы, чтобы выйти из песочницы Angular expression, однако в AngularJS 1.6 песочница была удалена. Поскольку мы работали с 1.8.1, нам не нужно было беспокоиться об этом, и вместо этого мы могли использовать следующую полезную нагрузку (взятую отсюда).
Код:
{{constructor.constructor('alert(1)')()}}Это позволило бы нам запускать традиционную полезную нагрузку XSS для предупреждений, но пройдет ли она политику безопасности контента? На самом деле я не был в этом уверен.
Мой мыслительный процесс здесь заключался в том, что я не внедряю новый тег скрипта, я просто прошу AngularJS оценить выражение шаблона, и, поскольку AngularJS уже разрешен, разве это не сработает? Это ведь не встроенная оценка, верно? Итак, я отправил полезную нагрузку и перезагрузил экран, чтобы меня приветствовали этой мерзкой графикой.
Снова сорвали! Даже если мы попросим AngularJS оценить шаблон, он не даст нам XSS. Есть ли способ обойти Content Security Policy?
Обходим CSP
Удивительно то, что AngularJS можно использовать для обхода CSP! Методология для этого примерно эквивалентна идее, которую я имел в виду, за исключением того, что вместо внедрения шаблона мы собираемся внедрить HTML. Подождите, разве это не шаг в обратном направлении? Вы ещё увидите что нет
Благодаря невероятным исследованиям, опять же, проведенным Гаретом Хейесом, мы заставляем AngularJS оценивать JavaScript с помощью директив. После танцев с бубном я получил следующую полезную нагрузку.
Код:
<input ng-focus=$event.view.alert('XSS')>Это позволит использовать директиву
ng-focus для запуска JavaScript. Переменная $event.view предоставит нам доступ ко всем обычным функциям JavaScript, которые нам понадобятся. Итак, я создал приложение с этим именем, обновил страницу и…
Миссия выполнена! Выкуси CSP! Победный вопль!
Убедившись, что у меня нет галлюцинаций, я сделал несколько снимков экрана и отправил их в AWS.
Заключительные мысли
Я хотел бы отметить пару моментов по этому поводу. Во-первых, я думаю, что это очень интересный сценарий атаки, потенциально переходящий от доступа к API к попытке атаковать пользователей через консоль AWS. Чтобы было понятно, это ОЧЕНЬ редкое обстоятельство. Насколько известно мне (и гуглу), в консоли AWS была обнаружена только одна ошибка XSS, которая была публично раскрыта. Это определенно не та вещь, которую ваше обычное консультант по пентесту может спровоцировать. Но для достаточно искушенного противника в нужной ситуации это может быть очень кстати.
В частности, я думаю, что было очень интересно, что мы могли потенциально установить XSS в истории изменений без каких-либо разрешений. Гипотетический сценарий атаки мог быть следующим: Приземляемся на экземпляр EC2 -> Определяем, что Elastic Beanstalk используется с Resource-Based Policies и определяем для него роль, связанную с сервисом -> Отправляем полезную нагрузку как роль без разрешений EB или CloudTrail -> Ждём -> Получаем профит
Я не понимаю, почему история изменений не функционировала какое-то время. В конце концов он вернулся, и я смог доказать, что могу использовать XSS (см. Снимок экрана выше).
Наконец, небольшой совет для исследователей безопасности; Я определенно понимаю желание сообщить об обнаруженной вами ошибке как можно быстрее. Что, если кто-то другой найдет его и отправит первым? Что, если он будет исправлен в течение следующих 30 минут !? Хотя да, два человека могут одновременно обнаружить одну и ту же ошибку, и возможно, что обнаруженная вами ошибка будет исправлена до того, как вы сообщите об этом разработчикам, это вряд ли произойдет. Вместо этого лучше сесть на это, обдумать все до конца (ПРОВЕРИТЬ ВЕРСИЮ С ANGULAR) и сообщать об этом только тогда, когда вы уверены, что зашли так далеко, насколько это возможно.
От ТС
Gif на форум не грузились, так что я просто переконвертировал их в png.
В переводе могут быть ошибки, так как Web-уязвимости не совсем то, в чём я хорошо разбираюсь.
За оригиналом - сюда
Перевод:
Azrv3l cпециально для xss.pro