用DNS欺骗绕过同源策略

Circumventing the same-origin policy with DNS trickery

本文关键字：策略 DNS 欺骗      更新时间：2023-09-26

我正在用Javascript编写一个web应用程序，该应用程序需要访问第三方API（位于x.apisite.com和y.apisite.com上）。我使用的是XMLHTTPRequest，但在从我自己的本地服务器提供文件时，由于同源策略，此操作失败。

现在，这个网络应用程序应该安装在我的移动设备上，任何下载的文件都会缓存在那里。因此，我更改了DNS条目，将x.apisite.com和y.apisite.com指向我自己的本地服务器。然后我下载文件，然后将DNS条目改回正确的条目。我想，既然浏览器认为脚本是从*.apisite.com下载的，我现在可以将XMLHTTPRequest设置为*.apisite.com。然而，情况似乎并非如此，我仍然会遇到同源策略错误。

我做错了什么？

以下是我正在做的事情的基本想法：

<!DOCTYPE html>
<html>
    <head>
        <!-- this will actually be downloaded from my own local server -->
        <script src="http://x.apisite.com/script-0.js">
        <script src="http://y.apisite.com/script-1.js">
...

在script-0.js中，我制作XMLHTTPRequest到x.apisite.com，同样在script-1.js中，我访问y.apisite.com。

实用答案（不推荐）：从您控制的域中创建到第三方域的CNAME记录，然后使用这些域，并希望第三方的主机不会查看HTTP Host标头。请注意，如果客户端尝试对第三方主机进行身份验证，这也不会起作用；例如在使用HTTPS时（某些客户端浏览器可能会在某些场景中强制使用HTTPS）。

理想的答案是：让第三方使用CORS授权来自您的源域的代码发出的请求（有些主机已经允许来自任何源的代码发出请求，您应该检查一下）。

替代方案：如果第三方不想允许客户端使用您域中的代码进行跨源请求，那么您必须自己（从服务器）进行这些请求。然后，您发送到客户端浏览器的代码将只与相同的源代码进行交互，但这也意味着，如果您代理用户的请求（如果相关的话），用户必须使用他们的凭据信任您，或者您必须拥有自己的凭据才能向第三方主机验证您的服务器，这允许您在那里做任何您想做的事情。这也意味着你还要承担流量负载，根据应用程序的不同，流量负载可能很重，也可能不重。还有许多潜在的其他含义，它们都源于您明确地对这些请求负责的事实。

注意：虽然这听起来可能有点复杂，但了解用户、用户的客户端浏览器、浏览器中执行的代码、代码的来源以及代码请求的域之间的信任机制可能会很有用。始终牢记各方的最大利益，很容易为您的特定问题找到解决方案。

最后的答案（每个人都讨厌它，但你可能预料到了）："这取决于你到底想做什么。"（对不起。）

相关文章：