Vivo Internet Server团队Wei Ling
本文主要讲述了根据公司的网络架构和业务特征，如何将正常请求错误判断为交叉域。
当提交某个业务背景时，据报道会跨域错误，如下所示：
从数字可以看出，错误的原因是HTTP请求的失败。因此，您需要了解HTTP请求的完整链接是什么。
HTTP请求通常通过3个级别，即DNS，NGINX和Web服务器。具体过程如下：
在理解HTTP的基本请求链接（结合该问题）之后，进行了初步调查，并发现该表格是由邮政邮政以应用程序/JSON格式提交的。正面和背面的分隔（页面域名和背景服务域名），NGINX已配置了交叉域解决方案。基于此，我们对其进行了分析。
步骤1：自我测试定位
由于它是表单的表单，因此我们使用控制变量方法来尝试修改每个字段并提交测试。多次试验后，表单中ModuleeXport字段的更改将导致此问题。
考虑到ModuleeXport字段是业务中的JS代码，我们试图删除/修改此JS代码，并发现当字段Moduleexport中的JS代码足够小时，问题就消失了。
基于上述发现，我们的第一个猜想是：是否是HTTP响应方的请求体大小限制，这会导致此问题。
步骤2：检查HTTP请求身体限制
由于使用前后 - 末端分离，实际请求由xxx.xxx.xxx表示的服务响应。内部网络域名的响应链如下：
然后，从理论上讲，如果它是HTTP请求主体的限制，则可能发生在LVS层或NGINX层或Tomcat中。我们逐步调查：
首先检查LVS层。如果LVS层失败，网关的问题是异常的，返回代码将为502.从而，通过抓取袋子查看返回代码，可以从下面的图中看到返回代码为418，因此排除了异常LV的可能性
其次，检查nginx层。nginx层的HTTP配置如下：
我们看到，在NGINX层中，最支持的HTTP请求主体为50m，此事故的表单请求表格约为2m，远小于限制，因此：：：不限制NGINX层HTTP请求主体的极限。
然后检查tomcat层并检查tomcat配置：
我们发现，最大帖子请求的Tomcat的尺寸限制为-1，这意味着无限的语义，因此：不是Tomcat层HTTP请求主体限制。
总而言之，我们可以认为这个问题与HTTP请求主体的尺寸限制无关。
因此，问题是，如果不是由这两个层引起的，是否还有其他因素或其他网络层？
步骤3：Baggle广泛利益
我们将相关的操作和维护方提取到一个小组讨论，讨论分为两个阶段。
操作和维护方发现，tomcat是使用容器进行部署的，在容器和NGINX层的中间，有一个带有容器的名称服务器层 - - - - - - - - - 。我们发现，HTTP请求主体的大小限制为3072m。排除是进入的原因。
安全同学表示，为了防止XSS攻击，该公司将对所有背景请求执行XSS攻击验证。如果未批准验证，将报告交叉域错误。
换句话说，理论上完整的网络 - 层调用链，如下所示：
从WAF的工作机制和问题的角度来看，这可能是WAF层的原因。
步骤4：WAF调查
在上述猜测的情况下，我们重新放了袋子，并试图获取整个HTTP请求的OPTRACE路径，以查看它是否在WAF层上拦截。
从包装数据的角度来看，状态是对完整的前端请求的成功请求，返回代码为418，而OPTRACE中的IP地址则作为WAF服务器IP地址查询。
总而言之，ModuleeXport字段的形式形式的变化可能会导致WAF层中的拦截。
在进行字段和一个字段检查后，锁定模块。exports.items.properties.configs.config.config.validator字段将触发WAF拦截机制：在请求WAF模块时，所有攻击规则都将匹配。如果这是高风险风险规则，则触发拦截。
整个失败的原因是业务请求的内容触发了WAF XSS攻击检测。
在解释XS之前，您必须首先告诉浏览器的交叉域保护机制
现代浏览器具有“同源策略”。SO称为同源策略仅指地址：
在同一情况下，仅允许访问相同的cookie，localstorage或发送ajax请求，依此类推。- 域需求。例如，由于使用正面和后端分离，与此问题的故障相对应，导致页面的域名和背景域名必须有所不同。因此，如何合理地交叉 -一个问题。
常见的跨域解决方案是：iframe，jsonp，cors。
跨源资源共享的CORS（跨原始资源共享）CORIOS是解决浏览器的跨域限制的W3C标准（官方文件）。核心想法是在HTTP的请求标题中设置相应的字段。设置了相关字段后，请求将正常启动，背景将确定此请求是否是通过验证这些请求的合理交叉域请求字段。
CORS协议需要服务器支持（非服务器业务流程），例如Tomcat 7及其未来版本。
对于开发人员而言，CORS通信和同源AJAX通信之间没有区别，并且代码完全相同。浏览器发现Ajax请求Cross -Source，它将自动添加一些其他头部信息，有时会有其他信息请求，但是用户不会感觉到。
因此，实现CORS通信的关键是服务器（可以判断服务器，并且可以要求哪些域）。只要服务器实现CORS协议，它就可以传输。
尽管CORS解决了交叉域问题，但它引入了风险，例如XSS攻击，因此您需要在到达服务器之前添加一层Web应用程序防火墙（WAF）。整个请求的规则将匹配。如果规则不匹配，则将直接返回错误（类似于情况下的418）。
总体过程如下：
不合理的交叉域请求，我们通常认为侵略性请求被视为XSS攻击。那么，从广义上讲，XSS攻击是什么？
XSS是跨站点脚本的缩写，可以将代码注入用户浏览的网页。此代码包括HTML和JavaScript。
例如，有一个论坛网站，攻击者可以发布以下内容：
之后，内容可能会呈现为以下形式：
另一个用户浏览包含此内容的页面将跳到domain.com并运行当前的cookie范围。如果此论坛网站通过Cookie管理用户登录状态，则攻击者可以使用此cookie登录攻击者的帐户。
XS可以通过虚假的输入表格窃取用户的cookie，显示伪造的文章或图片等，并假装在窃取cookie后可以访问用户对各种系统的访问，这非常有害。
这是两个XSS防御机制。
XSS防御机制主要包括以下两点：
设置httponly的cookie可以防止JavaScript脚本调用，并且您无法通过document.cookie获得用户cookie信息。
例如 < 转义为 < ，将 > 转义为 >，避免使用HTML和Jascript代码的操作。
富文本编辑器允许用户输入HTML代码，因此他们不能简单地过滤<等待字符，这大大增加了XSS攻击的可能性。
富文本编辑器通常使用XSS滤镜来防止XSS攻击。通过定义某些标签或黑名单，不允许使用积极的HTML代码输入。
在以下示例中，形式和脚本等标签是正义的，将保留H和P等标签。
公义之后：
确定问题后，让安全团队修改WAF拦截规则，问题消失了。
最后，总结这个问题。
查看整个调查过程，最消耗的工作集中在问题定位上：哪个模块有问题。定位模块的最大困难是他们不了解网络的完整链接（我不知道存在以前的WAF层）。
那么，以后我们应该如何加速问题的解决方案？我认为有两点要注意：
让我们一一解释：
一开始，在确定形式引起的问题之后，我们对其进行了修改并逐一修改并验证了它，并最终确定了由其中一个字段引起的现象。定位特定问题后，拆卸先前锁定的场并逐渐分析。该字段中的每个属性，以最终确定XX属性违反WAF规则机制的值。
在这种情况下，跨域拒绝的故障主要是网络层，因此我们必须找出整个业务服务的网络层次结构。
总而言之，我们必须熟悉每个模块的责任，并知道如何判断每个模块是否在整个链接中正常工作。只有基于此，我们才能逐渐减少问题的范围并最终得到答案。
原始：https：//juejin.cn/post/709850952345735694