Рекомендации по безопасности JSON?

Существует ряд атак безопасности для JSON, особенно XSRF.

Уязвимость возникает, когда веб-служба использует файлы cookie для аутентификации и отвечает массивом JSON, содержащим конфиденциальные данные в ответ на запрос GET.

Если злоумышленник может обмануть пользователя, который зарегистрирован в службе, naive-webapp.com, для посещения своего сайта (или любого сайта, на котором установлен управляемый IFRAME, например, через встроенные объявления), тогда они могут вставить <script> с SRC на naive-webapp.com и потенциально украсть пользовательские данные. Это зависит от javascript quirk с конструктором JavaScript Array следующим образом:

 <script>
   // Overload the Array constructor so we can intercept data
   var stolenArrays = [];
   var RealArray = Array;
   Array = function () {
     var arr = RealArray.apply(arguments);
     stolenArrays.push(arr);
     return arr;
   }
 </script>
 <!-- even though the attacker can't access the cookies,
   - he can cause the browser to send them to naive-webapp.com -->
 <script src="//naive-webapp.com/..."></script>
 <script>
   // now stolenArrays contains any data from the parsed JSON
 </script>

EcmaScript 5 устранил запутанное поведение, которое вызвало [] поиск Array глобального объекта, и многие современные браузеры больше не подвержены этой атаке.

Кстати, Oil ошибается в отношении непредсказуемых URL-адресов. Криптографически безопасные случайные идентификаторы в URL-адресах - прекрасный способ защитить ресурсы. Безопасность, основанная на удостоверениях личности, не является панацеей, как предполагает Oil. См. http://waterken.sourceforge.net/ для примера схемы защищенного распределенного приложения на основе криптографически защищенных идентификаторов в URL-адресах, которая не требует понятия идентичности.

EDIT:

При рассмотрении JSON vs XML вы также должны знать о специфических для атак векторах XML.

XXE, XML Атаки внешних объектов, используют обработанный XML для доступа к файловой системе и сетевым ресурсам через брандмауэр.

<!DOCTYPE root 
[
<!ENTITY foo SYSTEM "file:///c:/winnt/win.ini">
]>
...
<in>&foo;</in>

Приложение вставляет вход (параметр "in", содержащий файл win.ini) в ответ веб-службы.

он по-прежнему лучший для защиты ваших защищенных данных с помощью не предсказуемых URL-адресов.

Акцент мой. Какая ерунда! Это лучший, чтобы защитить ваши защищенные данные с помощью надлежащей проверки подлинности и, возможно, некоторого шифрования. Обмен JSON может по-прежнему использовать существующие методы аутентификации (например, сеансы через файлы cookie) и SSL.

Полагаясь на то, что кто-то не догадывается о URL-адресе (что они фактически говорят) будет разумным методом (и даже тогда, только когда-то), когда вы используете JSON для экспорта данных анонимному третьему лицу (например, веб-сервис). Одним из примеров является Google API различных веб-сервисов, в котором анонимные пользователи получают доступ к данным Google через другие веб-сайты. Они используют ключи доменного имени и API, чтобы убедиться, что веб-сайт "мужчина-в-середине" разрешен для предоставления данных Gooogle.

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

Изменить: чтобы продемонстрировать, что они означают, подумайте об этом. Представьте, что ваш банк предоставил JSON API для получения заявлений. Если бы я мог просто набрать http://yourbank.com/json-api/your-name/statement, вам, вероятно, было бы не очень приятно.

Они могут генерировать уникальную строку для вашей учетной записи, которая требовалась в любом запросе JSON, например: http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement

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