同源和浏览器安全

同源和浏览器安全

在开发中遇到的同源问题

在业务系统的开发中，浏览器，或者是前端，在一定程度上被划分在了可信域外，因为总是可以通过非正常的手段模拟端行为，来进行一些攻击。

尽管如此，作为网络连接的主要应用客户端，浏览器仍旧采用了一些安全措施的来防范最简单的模拟行为。

同源的管理，本质上是不同域的cookie管理。浏览器，作为HTTP Client的cookie存储器，对不同的服务器进行了区分，确保在不同服务器下发的代码不会接触到其他服务器的cookie。

由于同源是以“协议+主机+端口”为区分的，于是乎，当你看到了相同二级域下有一个好用的接口，然后发现是一个用POST做查询，妥妥地被浏览器跨域拦截，肯定像吃了屎一样难受。

有什么方法？

从根上解决问题：支持CORS。最直接的办法当然是要求别人的服务器支持跨域请求，但是带来的问题是管理成本的上升。因为从安全的角度而言，CORS的开放应该是狭窄的，即有需求时开发。这意味着每次接入都要沟通和配置，劳神伤心。

那么委屈求全一点呢？代理。这个方案我是想到了的，但是其实没有狠下心去做，一方面，要设计一套新的代理协议，包括重定向和cookie的翻译两部分。绝大部分的网文都只考虑了重定向的问题，但是没有考虑到鉴权，因此，cookie的domain和path也需要基于你的代理协议进行订正，确保符合语义。

但，上述两种方法的问题都在于我们在服务器上动了手脚。在服务器上动手脚的核心要义就是，客户端不感知这种转发。从我的角度，干嘛不让客户端知道呢？我的跨域产品需要明确给用户知道，我在调用你其他页面的信息。

那么，除了修改document.domain这种半吊子方案之外，最有趣的就是window.postMessage机制。

通过消息在多个标签页间通信，从而完成真·跨域请求。然后，可能有点恶心的方案就是如何修改其他域的客户端以支持window.postMessage机制了。

其实也不恶心，用油猴之类的脚本就行了。

所以最后可以做个啥？

现在的东家，在技术管理上，最重要的问题是“散”。无论是数据、配置、排查记录，都像雪花一样散落在各个mng和子系统里。

那么，需要有一个东西帮你把很多页面的东西汇总起来看一看。这个汇总不应该就是一个报表的页面，而是可以随时切来切去的。信息，不应该就摘要化，而是将其关系提取在一个页面上，并根据关系，决定真正重要的细节。

那么，这玩意儿做的怎么样了呢？我感觉在跑路前弄不完了。