Лучшие практики безопасности JSON?

Question

Лучшие практики безопасности JSON?

Примечание: Преобразование в строковое преобразование

Это происходит просто, если вы пытаетесь рассматривать массив как строку:

$arr = array('foo', 'bar');

echo $arr;  // Notice: Array to string conversion
$str = 'Something, ' . $arr;  // Notice: Array to string conversion

Массив не может быть просто echo 'd или конкатенируется с строкой, потому что результат не определен. PHP будет использовать строку «Array» вместо массива и вызвать уведомление, чтобы указать, что это, вероятно, не то, что было предназначено, и что вы должны проверять свой код здесь. Вероятно, вы захотите что-то вроде этого:

echo $arr[0];  // displays foo
$str = 'Something ' . join(', ', $arr); //displays Something, foo, bar

Или зациклируйте массив:

foreach($arr as $key => $value) {
    echo "array $key = $value";
    // displays first: array 0 = foo
    // displays next:  array 1 = bar
}

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

73

javascript ajax security json

задан Community 23 May 2017 в 11:54

3 ответа

Существует много нападений безопасности на JSON, особенно XSRF.

уязвимость происходит, когда веб-сервис использует cookie для аутентификации и отвечает массивом JSON, содержащим уязвимые данные в ответ на ПОЛУЧИТЬ запрос.

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

РЕДАКТИРОВАНИЕ:

При рассмотрении JSON по сравнению с XML, необходимо знать об определенных векторах атаки XML также.

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

<!DOCTYPE root 
[
<!ENTITY foo SYSTEM "file:///c:/winnt/win.ini">
]>
...
<in>&foo;</in>
Приложение встраивает вход (параметр "в", который содержит файл win.ini) к ответу веб-сервиса.

53

ответ дан Mike Samuel 24 November 2019 в 12:25

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

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

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

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

<час>

Редактирование: для демонстрации, что они имеют в виду рассмотрите это. Предположите, что Ваш банк обеспечил 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

ответ дан Oli 24 November 2019 в 12:25

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

javascript ajax security json

Лучшие практики безопасности JSON?

Примечание: Преобразование в строковое преобразование

3 ответа

Похожие вопросы: