Вы предпочитаете оборачивать массивы JSON в другой объект JSON или всегда требует POST для предотвращения перехвата JSON?

Question

Я недавно начал изучать создание веб-приложений с использованием .NET MVC, и наткнулся на это сообщение в блоге Фила Хаака: JSON Hijacking . Для тех из вас, кто не знает об этой уязвимости при использовании JSON для передачи конфиденциальных данных, это действительно необходимо прочитать.

Кажется, что есть три способа справиться с этой уязвимостью.

1. Требовать POST вместо GET в вашем сервисе JSON.
2. Оберните ваши ответы массива JSON в объект JSON.
3. Не подвергайте конфиденциальные данные никаким сервисам, которые не защищены 1 или 2.

Третий вариант на самом деле не вариант, поскольку он действительно ограничивает использование JSON.

Так какой из двух других вы предпочитаете?

Предварительный просмотр .NET MVC 2 требует ответов POST для JSON по умолчанию, я думаю, что это отличный способ защитить любого разработчика, который еще не знает об этой проблеме. Но мне кажется немного "хаки" сломать REST таким образом. Если кто-то не говорит мне об этом, я придерживаюсь того, чтобы обернуть мои массивы в другой объект и развернуть его на стороне клиента.

Answer 1

Я лично обертываю все свои комментарии в комментарии:

/* {
    "foo": 3,
    "bar": "string with *\x2F sequence in"
} */

и удалите это перед JSON.parsing. Это делает его бесполезным в качестве цели для тегов скрипта.

Стоит отметить, что эта проблема связана не только с JSON, но и с любым ответом HTTP, который вы обслуживаете, который может быть интерпретирован как JavaScript. Даже, скажем, текстовый файл с защитой .htaccess уязвим для утечки при включении сторонних тегов сценария, если он находится в формате, который является допустимым JavaScript.

И вот в чем дело: благодаря E4X даже обычные статические XML-документы также являются допустимым JavaScript. E4X - катастрофическое и бесполезное расширение для JavaScript, реализованное и изобретенное в Mozilla, которое позволяет писать <element>content</element> встроенных XML-литералов в JS; Таким образом, защищенный XML-файл теперь уязвим к тем же рискам межузловой утечки, что и JSON. Спасибо, Мозилла. См. Статью Google doctype .

Answer 2

Это классический csrf (подделка межсайтовых запросов).

Вот решение:

http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Answer 3

Поскольку это в основном CSRF-атака, вы можете поместить токен (например, хэш идентификатора сеанса и секрет) в каждый из ваших вызовов JSON и проверить его действительность на сервере. Это то же самое, что вы должны делать для обычных запросов POST в любом случае.