Найкращі практики безпеки JSON?

Досліджуючи проблему JSON проти 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-адреси для підвищення безпеки?

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

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

Зазвичай це передбачає випадковий маркер, вставлений у ФОРМУ на стороні сервера, а потім перевіряється, коли робиться запит.

Річ із масивом / об’єктом для мене новина:

Теги сценаріїв: Зловмисник може вбудувати тег сценарію, спрямований на віддалений сервер, і браузер буде ефективно стирати () відповідь за вас, однак він відкидає відповідь, і оскільки JSON - це вся відповідь, ви в безпеці.

У такому випадку ваш сайт взагалі не повинен використовувати JSON, щоб бути вразливим. Але так, якщо зловмисник може вставити випадковий HTML на ваш сайт, ви підсмажуєте.

Існує низка атак безпеки проти JSON, особливо XSRF.

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

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

 <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-адресах - прекрасний спосіб захистити ресурси. Безпека, що базується на особистості, не є панацеєю, як вважає Нафта. Див. 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) у відповідь веб-служби.

все-таки найкраще захистити свої захищені дані за допомогою непередбачуваних URL-адрес.

Акцент мій. Яка нісенітниця! Це краще , щоб захистити ваші захищені дані з деякою належної аутентифікації і , можливо , деякі шифрування на вершині цього. Біржі JSON все ще можуть використовувати існуючі методи автентифікації (наприклад, сеанси за допомогою файлів cookie) та SSL.

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

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

Редагувати: щоб продемонструвати, що вони означають, розгляньте це. Уявіть, ваш банк надав 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

Я мав би набагато менше шансів змогти це здогадатися. Але чи справді ви хотіли б, щоб це був єдиний буфер між вашими справді захищеними даними та потенційними злодіями особистих даних? Ні.