CORS跨域资源共享配置导致XSS攻击漏洞的解决方案

2021-11-19 18:28:00
黎彩霞
原创
135

1. 背景介绍


因为平台采用前后分离的架构来设计,前后端分开部署,部署的域名或者端口不同会导致前端访问后端时存在跨域问题,针对跨域问题比较常见的处理方案有以下几种:

1.  C ORS:后端配置CORS,允许任何域或者指定域能访问后端服务;

2.  反向代理:通过反向代理让前后端处于同一个域;

3.  JSONP:在前端访问后端时通过JSONP解决跨域问题。

以上方案中JSONP的方案对代码逻辑的侵入性太强,不推荐使用。

反向代理需要在部署时通过配置让前后端应用/服务处于同一个域,但是会增加系统部署的配置复杂度。

CORS通过在后端做通用配置解决跨域问题,没有额外配置,是比较推荐的方式,CORS又有两种模式,一种是允许所有来源跨域访问,另一种是允许指定来源的请求跨域访问,前者对于开发环境、测试环境、生产环境都没有配置差异,后者需要按照不同环境分别配置允许跨域的来源域,所以平台默认是按照CORS允许所有来源跨域访问的策略来配置的。

但是这种默认允许所有来源跨域的策略会导致系统有被XSS攻击的风险,下面介绍如何在平台中配置指定来源的CORS策略、反向代理策略。


2. 解决方案


以下两种方案都能解决这个问题,根据系统的部署情况选择一种方案。


2.1 允许指定来源的CORS策略


在如下代码位置配置允许跨域访问的域(多个域可以分别添加),则该域名的前端就可以跨域访问该后端服务了。


2.2 反向代理策略

2.2.1 关闭CORS


如下图所示,首先关闭CORS跨域访问策略。



此时前端访问后端服务时会抛出跨域错误。



2.2.2 Nginx配置反向代理


如下图所示,在Nginx中对每个后端微服务的地址配置反向代理,将请求前端的以/form,/portal,/runtime,/model,/uc开头的请求分别代理到真实的后端地址上去。 特别注意这里做了一个地址rewrite,需要在访问时各自追加一个用于识别的服务名,如下图红色框圈出的部分。



2.2.3 前端配置文件中修改后端地址

修改前端的sso.js(或config.js)中配置的后端地址,首先后端地址的域名/ip和端口需要修改为Nginx的域名/ip和端口,其次后端的微服务需要追加反向代理中配置的识别服务名,如下图红色框圈出的部分。



完成以上配置以后,访问系统前后端时使用的是相同的域名和端口,自然也就不存在跨域问题了。



发表评论
评论通过审核后显示。