安全实施脚本标签 hack 来进行 XSS？
像许多开发人员一样，我想让服务器“A”提供的 JavaScript 与服务器“B”上的 Web 服务对话，但我被当前的 同源政策。克服这个问题的最安全的方法（我能找到）是位于服务器“A”上的服务器脚本，并充当它和“B”之间的代理。但是，如果我想在各种客户环境（RoR、PHP、Python、.NET 等）中部署此 JavaScript，并且无法为所有这些环境编写代理脚本，我该怎么办？
使用 JSONP，有些人说。好吧，Doug Crockford 在他的网站上指出了 和 在采访中发现脚本标签被黑客攻击（由JSONP）是一种绕过同源策略的不安全方法。 “A”提供的脚本无法验证“B”是否是他们所说的人，以及它返回的数据不是恶意的，或者会捕获该页面上的敏感用户数据（例如信用卡号），并且传给卑鄙的人。这似乎是一个合理的担忧，但如果我只使用脚本标签 hack 本身并严格使用 JSON 进行通信会怎么样？这样安全吗？如果没有，为什么不呢？使用 HTTPS 会更安全吗？示例场景将不胜感激。
附录：需要支持 IE6。第三方浏览器扩展不是一个选项。请让我们继续讨论脚本标签黑客的优点和风险。
Like a lot of developers, I want to make JavaScript served up by Server "A" talk to a web service on Server "B" but am stymied by the current incarnation of same origin policy. The most secure means of overcoming this (that I can find) is a server script that sits on Server "A" and acts as a proxy between it and "B". But if I want to deploy this JavaScript in a variety of customer environments (RoR, PHP, Python, .NET, etc. etc.) and can't write proxy scripts for all of them, what do I do?
Use JSONP, some people say. Well, Doug Crockford pointed out on his website and in interviews that the script tag hack (used by JSONP) is an unsafe way to get around the same origin policy. There's no way for the script being served by "A" to verify that "B" is who they say they are and that the data it returns isn't malicious or will capture sensitive user data on that page (e.g. credit card numbers) and transmit it to dastardly people. That seems like a reasonable concern, but what if I just use the script tag hack by itself and communicate strictly in JSON? Is that safe? If not, why not? Would it be any more safe with HTTPS? Example scenarios would be appreciated.
Addendum: Support for IE6 is required. Third-party browser extensions are not an option. Let's stick with addressing the merits and risks of the script tag hack, please.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
目前，浏览器供应商对于跨域 javascript 应如何工作存在分歧。 Flash 的 Crossdomain.xml 文件 是一个安全且易于使用的选项。大多数语言都有为其编写的跨域代理，并且它们是开源的。
更邪恶的解决方案是使用 Sammy Worm 的传播方式。 XSS 可用于使用 xmlhttprequest“读取”远程域。如果其他域已添加
，则不需要 XSS。像这样的脚本标签允许您在另一个域的上下文中评估您自己的 JavaScript，这与 XSS 相同。还需要注意的是，即使有同源策略的限制，您可以让浏览器将请求传输到任何域，但您只是无法读取响应。这是CSRF的基础。您可以动态地将不可见的图像标记写入页面，以使浏览器触发无限数量的 GET 请求。这种图像标签的使用是攻击者在另一个域上使用 XSS 获取
documnet.cookie的方式。 CSRF POST 通过构建表单然后在表单对象上调用.submit()来利用工作。要更好地了解同源策略、CSRF 和 XSS，您必须阅读 Google 浏览器安全手册< /a>.
Currently browser venders are split on how cross domain javascript should work. A secure and easy to use optoin is Flash's Crossdomain.xml file. Most languages have a Cross Domain Proxies written for them, and they are open source.
A more nefarious solution would be to use xss how the Sammy Worm used to spread. XSS can be used to "read" a remote domain using xmlhttprequest. XSS isn't required if the other domains have added a
<script src="https://YOUR_DOMAIN"></script>. A script tag like this allows you to evaluate your own JavaScript in the context of another domain, which is identical to XSS.It is also important to note that even with the restrictions on the same origin policy you can get the browser to transmit requests to any domain, you just can't read the response. This is the basis of CSRF. You could write invisible image tags to the page dynamically to get the browser to fire off an unlimited number of GET requests. This use of image tags is how an attacker obtains
documnet.cookieusing XSS on another domain. CSRF POST exploits work by building a form and then calling.submit()on the form object.To understand the Same Orgin Policy, CSRF and XSS better you must read the Google Browser Security Handbook.
看看 easyXDM，它是一个干净的 JavaScript 库，允许您跨域边界进行通信，而无需任何服务器端交互。它甚至支持开箱即用的 RPC。
它支持所有“现代”浏览器，以及 IE6，传输时间 < 10 分钟。 15 毫秒。
一个常见的用例是使用它来公开 ajax 端点，允许您轻松地执行跨域 ajax（查看首页上的小示例）。
Take a look at easyXDM, it's a clean javascript library that allows you to communicate across the domain boundary without any server side interaction. It even supports RPC out of the box.
It supports all 'modern' browser, as well as IE6 with transit times < 15ms.
A common usecase is to use it to expose an ajax endpoint, allowing you to do cross-domain ajax with little effort (check out the small sample on the front page).
假设您有两个服务器 - frontend.com 和 backend.com。 frontend.com 包含一个像这样的
.当浏览器评估
code.js时，它被视为frontend.com的一部分，而不是backend.com的一部分。因此，如果 code.js 包含与 backend.com 通信的 XHR 代码，将会失败。如果您刚刚将
如果您将整个页面及其所有组件转换为 https，则 包括他自己的 javascript 文件。但如果您足够偏执地这样做，那么您也应该偏执地不要依赖外部服务器来获取数据。如果攻击者破坏了 backend.com，那么他实际上已经在 frontend.com 上获得了足够的影响力， frontend2.com 和您的所有网站。
简而言之，https 很有帮助，但如果您的后端服务器受到威胁，它对您没有任何帮助。
我的建议是创建一个代理服务器，并在整个网站中使用 https。
Lets say you have two servers - frontend.com and backend.com. frontend.com includes a
<script>tag like this -<script src="http://backend.com/code.js"></script>.when the browser evaluates
code.jsis considered a part offrontend.comand NOT a part ofbackend.com. So, if code.js contained XHR code to communicate with backend.com, it would fail.If you just converted your
<script src="https://backend.com/code.js>to https, it would NOT be any secure. If the rest of your page is http, then an attacker could easily man-in-the-middle the page and change that https to http - or worse, include his own javascript file.If you convert the entire page and all its components to https, it would be more secure. But if you are paranoid enough to do that, you should also be paranoid NOT to depend on an external server for you data. If an attacker compromises backend.com, he has effectively got enough leverage on frontend.com, frontend2.com and all of your websites.
In short, https is helpful, but it won't help you one bit if your backend server gets compromised.
My recommendation is to create a proxy server, and use https throughout your website.
向所有试图回答我的问题的人致歉。它是在关于脚本标签黑客如何工作的错误假设下进行的。假设人们可以简单地将脚本标签附加到 DOM，并且附加脚本标签的内容不会受到同源策略的限制。
如果我在发布问题之前费心测试我的假设，我就会知道附加标签的 source 属性 是不受限制的。 JSONP 更进一步，建立了一个将传统 JSON Web 服务响应包装在回调函数中的协议。
然而，无论如何使用脚本标签 hack，都无法筛选恶意代码的响应，因为浏览器会执行返回的任何 JavaScript。在这种情况下，IE、Firefox 和 Webkit 浏览器都不会检查 SSL 证书。据我所知，道格·克罗克福德是正确的。从 JavaScript 1.8.5 开始，没有安全的方法可以执行跨域脚本。
Apologies to all who attempted to answer my question. It proceeded under a false assumption about how the script tag hack works. The assumption was that one could simply append a script tag to the DOM and that the contents of that appended script tag would not be restricted by the same origin policy.
If I'd bothered to test my assumption before posting the question, I would've known that it's the source attribute of the appended tag that's unrestricted. JSONP takes this a step further by establishing a protocol that wraps traditional JSON web service responses in a callback function.
Regardless of how the script tag hack is used, however, there is no way to screen the response for malicious code since browsers execute whatever JavaScript is returned. And neither IE, Firefox nor Webkit browsers check SSL certificates in this scenario. Doug Crockford is, so far as I can tell, correct. There is no safe way to do cross domain scripting as of JavaScript 1.8.5.