我在阅读了这个网站上的几十篇精彩文章后注册了这个问题。 这是我未回答的问题,不可否认的是,它以应用程序安全性为重点:
对于在调用 REST 服务时返回以下标头的站点:
Content-Type: application/json
Access-Control-Allow-Origin: *
认识到这种宽松的 CORS 策略对于返回敏感数据的服务来说是不好的做法,但我必须证明威胁参与者是否可以代表经过身份验证的受害者调用经过身份验证的 REST 服务(cookie auth(,以便威胁参与者可以看到响应。
我了解此标志指示浏览器发送相关 cookie 以及跨域请求:
withCredentials: true
我观察到浏览器拒绝允许威胁参与者解释返回的响应,这意味着 JSON 对象被返回到浏览器(如代理或数据包捕获所证明的那样(,但永远无法到达威胁参与者自己可以访问的 DOM。
例如,当我通过jQuery调用上述REST服务时,Chrome 会生成消息">当凭据标志为真时,不能在访问控制允许来源中使用通配符"。 如果我尝试 JSONP,我会收到消息">未捕获的语法错误:意外令牌:">,因为我无权修改 REST 服务逻辑以返回正确的回调字符串。
威胁参与者是否真的不可能成功利用过于宽松的 CORS 策略来调用 REST 服务并代表受害者的经过身份验证的会话检索/解析/返回其响应?
我担心:
- 我不知道一两个技巧
- 某些浏览器可能不会主动阻止此类"攻击">
非常感谢任何见解,因为我不是开发人员 - 谢谢!
接受有凭据的请求时不能使用通配符。
响应有凭据的请求时,服务器必须指定域,并且不能使用通配符1
此外,看起来您需要设置以下标头作为来自 REST 服务的响应发送Access-Control-Allow-Credentials: true
如果您使用的是 Apache,则可以添加 .htaccess :
SetEnvIf Origin "^http(s)?://(.*)$" origin_is=$0
Header set Access-Control-Allow-Origin %{origin_is}e env=origin_is
此指令在 then 请求中添加一个带有域名值的 Acess-control-allow-origin。它在响应标头中复制源请求的值。