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

при исследовании вопроса JSON vs XML, я наткнулся этот вопрос. Теперь одна из причин предпочесть JSON была указана как простота преобразования в Javascript, а именно с помощью eval(). Теперь это сразу же поразило меня, как потенциально проблемные с точки зрения безопасности.

Так что я начал делать некоторые исследования в области безопасности JSON и через это сообщение в блоге о том, как JSON не так безопасен, как люди думают это. Эта часть торчала:

обновление: если вы делаете JSON 100% правильно, тогда у вас будет только объекты на верхнем уровне. Матрицы, Строки, числа и т. д. Все будет завернутый. Затем произойдет сбой объекта JSON для eval () потому что JavaScript переводчик будет думать, что он смотрит на блок, а не объект. Этот идет длинный путь к защите от эти атаки, однако это все еще лучше для защиты ваших защищенных данных с помощью не предсказуемые URL-адреса.

хорошо, так что это хорошее правило для начала: объекты JSON на верхнем уровне всегда должны быть объектами и никогда массивами, числами или строками. Звучит как хорошее правило для меня.

есть ли что-нибудь еще, чтобы сделать или избежать, когда речь заходит о безопасности, связанной с JSON и AJAX?

в последней части приведенной выше цитаты упоминаются непредсказуемые URL-адреса. У кого-нибудь есть больше информации об этом, особенно, как вы делаете это в PHP? Я гораздо больше опытный в Java, чем PHP, и в Java это легко (в том, что вы можете сопоставить весь диапазон URL-адресов с одним сервлетом), тогда как все PHP, которые я сделал, сопоставили один URL-адрес с PHP-скриптом.

кроме того, как именно вы используете непредсказуемые URL-адреса для повышения безопасности?

3 72
javascript json security ajax

3 ответа:

основная дыра в безопасности от блога (CSRF), не является специфичным JSON. Это так же большая дыра, используя XML вместо этого. Действительно, это так же плохо, как без асинхронных вызовов вообще; регулярные ссылки так же уязвимы.

когда люди говорят об уникальных URL, они обычно не имеют в виду http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement. вместо этого более распространено делать что-то еще о запросе уникальным; а именно значение в форме post, или параметр URL.

обычно это включает в себя случайный маркер, вставленный в форму на стороне сервера, а затем проверяется при выполнении запроса.

массив/объект, вещь для меня новость:

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

In в этом случае ваш сайт вообще не должен использовать JSON, чтобы быть уязвимым. Но да, если злоумышленник может вставить случайный HTML на ваш сайт, вы тост.

18

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

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

если злоумышленник может обмануть пользователя, который вошел в службу, naive-webapp.com, в посещение своего сайта (или любого сайта, который вставляет IFRAME, который они контролируют, например, через встроенные объявления), тогда они могут вставить <script> тег с SRC к the naive-webapp.com, и потенциально украсть данные пользователя. Это зависит от причуды javascript с 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 на глобальный объект, и многие современные браузеры уже не подвержены этой атаке.

кстати, нефть ошибается насчет непредсказуемых url. Криптографически безопасные случайные идентификаторы в URL-адресах-это прекрасный способ защищенный ресурс. Безопасность на основе идентичности не является панацеей, как предполагает нефть. Смотрите 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", который содержит выигрыш.ini file) к ответу веб-службы.

53

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

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

полагаясь на кого-то, кто не угадывает URL (что они эффективно говоря о) будет только разумным методом (и даже тогда, только тогда), когда вы используете JSON для экспорта данных в анонимную третью сторону (например, веб-сервис). Одним из примеров является API различных веб-сервисов Google, где анонимные пользователи получают доступ к Google-данным через другие веб-сайты. Они используют ключи Domain-referrer и API, чтобы убедиться, что веб-сайт man-in-the-middle может предоставлять данные Gooogle.

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

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

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

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

3