我似乎完全没有理解ajax的安全性,而且我不断帮助我不断回答我的问题.所以我做了这个实验.
我在site1.com上有这个js代码,位于http://site1.com/script.js.在服务器端,它进入数据库但不返回任何输出.当我从site1.com调用此函数时,我看到该条目已按预期记录在数据库中.
function enterdb(){
$.ajax({
async: false,
url: 'http://site1.com/test?format=json',
type: 'POST',
data: { input: '1' },
success: function(resp) {
alert(resp);
}
});
}
我将相同的js复制到了othersite.com的js文件中,现在位于http://othersite.com/script.js,看看它是否会登录到数据库.它不是很好,因为我不希望人们从其他外部脚本播放我的ajax URL.但这与我在之前的几个问题中读到的一些答案相矛盾
这个答案与我得到的结果相符
Cross domain is always banned because
of the Same Origin Policy.
但同样的答案也说
your JavaScript making a XHR and someone spoofing one, they are
the same and impossible to
differentiate (though you can
definitely make it harder).
那么判决是什么?我的目标是保护ajax网址,以便它们不被外部网站(如API)用于将数据转储到我的数据库中.
解决方法:
简短的回答:你提到的问题并不安全.
答案很长:
鉴于:
> A – 您控制的网站
> B – 其他人控制的网站
>查理 – 您网站的访问者,拥有凭据
your JavaScript making a XHR and someone spoofing one, they are the same and impossible to differentiate (though you can definitely make it harder).
这意味着你不能区分Charlie访问A和Charlie之间的区别,手动构建HTTP请求以访问您为JavaScript访问提供的URL.
So what’s the verdict? My goal is to secure the ajax urls so that they’re not used by external sites like an API to dump data into my database.
如果Charlie访问站点B,那么站点B无法通过Charlie的浏览器(具有Charlie的凭据)从站点A读取数据.
站点B可以通过Charlie的浏览器向站点A发出请求(例如,通过向JS提交不可见的iframe提供不可见的表单),因此站点B可能导致数据被插入.这是Cross Site Request Forgery,但有办法到defend against this.
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 [email protected] 举报,一经查实,本站将立刻删除。