Ответ 1
В AJAX нет ничего конкретного. Это просто запрос, выполненный вашим браузером. Это просто общий HTTP-запрос и должен быть защищен как любой другой HTTP-запрос, независимо от его характера XHR.
Проблемы безопасности Ajax и возможные атаки
В проекте, над которым я работаю, используются вызовы AJAX для каждой ссылки на странице, в частности, вызовы jQuery AJAX, а также каждая представленная форма, помимо входа в систему, отправляется через AJAX, и есть немного json, и xml, в миксе, Мой вопрос в том, каковы риски для безопасности этого? Весь серверный код - это PHP, и все правильно экранировано.
Ответы
Ответ 2
Широко распространено мнение, что использовать маркеры XSRF для защиты служб, которые открывают только данные через GET и которые разрешали пользователю через куки файлы, было необязательно использовать.
Это неправда. Раньше у них была уязвимость XSSI, специфичная для AJAX, когда выход был массивом JSON.
Рассмотрим службу /getfriends, которая возвращает данные типа [ { "name": "Alice" }, { "name": "Bob" } ].
Атакующая страница могла
<script>
var stolenData;
var RealArray = Array;
Array = function () {
return stolenData = new RealArray();
};
</script>
<script src="https://naivedomain.com/getfriends" type="text/javascript"></script>
а второй тег <script> загрузил JSON через домен с помощью файлов cookie пользователя
и из-за причуды в EcmaScript 3 (исправлено в EcmaScript 5.0 и современных интерпретаторах ES 3), страница могла читать украденные данные, потому что парсер JavaScript вызывал переопределенный конструктор Array при анализе [...] в ответе JSON.
Защита этих сервисов с помощью токенов XSRF в дополнение к обычным подходам на основе файлов cookie позволила решить проблему, так же как и запрет GET, авторизацию через пользовательские заголовки и включение разборки синтаксического анализа. Разрушители разбора работают, делая ответ недействительным JSON, например. возвращая throw 0; [{ "name": "Alice" }, { "name": "Bob" }], поэтому клиент XHR может отключить префикс throw 0;, но загрузка клиента через <script> не может.
Наконец, поскольку парсер JavaScript анализирует загруженный script как программу, это касается только служб, которые возвращают массивы JSON. Служба /getfriend, которая вернула { "names": ["Alice", "Bob"] }, не была бы уязвимой, поскольку этот контент не является допустимой программой - он анализируется как блок с недопустимой меткой. Но недопустимый JSON, такой как { names: [ "Alice", "Bob" ] }, уязвим, поскольку это действительная программа.
Ответ 3
Ajax нарушает правила безопасности, касающиеся процента экранирования зарезервированных символов в данных POST. Чисто и просто, это позволяет напрямую вставлять враждебный код в схемы SQL, которые могут быть такими, как PHP-код для последующего поиска и выполнения на хосте. До тех пор, пока AJAX не начнет избегать всех зарезервированных символов GET и POST, как это делают обычные браузеры с формами, не следует доверять без полной проверки на каждое сообщение для сегментов неактивного кода.