安全测试之我见

安全评估

Word count: 8.1kReading time: 29 min

 2020/08/18 

业务安全测试
漏洞功能点
漏洞类型
学习文章
问题记录
- token未及时失效问题记录
- XSS漏洞的修复
Others

业务安全测试

安全测试之我见

漏洞功能点

登录认证处

暴力破解
- 测试方法
  常常使用 Bp 结合字典对账号密码进行暴力破解
- 小技巧：
  intercept is on关闭的时候浏览器的请求依然会经过 Bp 只是不被拦截，所有的请求可以在 history 中查看
- 修复建议
1.设置登录验证码，并在尝试登录后改变，同时验证码的强度不能过低，防止攻击者使用 OCR 识别
2.设置登录失败次数限制，相同用户五分钟内失败6次则三小时内禁止登录
3.可增加手机短信校验等辅助校验方式
本地加密传输测试
- 测试方法
  (1)首先查看是否使用了 SSL(HTTPS)，如果没有使用 SSL 的话，使用 Bp 获登录数据包，查看是否存在明文传输
  (2)如果是使用了 SSL 可以使用 wireshark 抓包看一下是不是真的加密了

搜索处

1、SQL注入
2、XSS
3、SSRF

留言处

1、XSS
2、SSRF
3、越权

删除处

1、CSRF
2、SSRF

修改密码处

1、CSRF
2、越权

修改信息处

1、CSRF
2、越权

订单处

1、越权

遍历订单信息、修改操作

2、CSRF

文件下载处

任意文件下载
- eg：记一次艰难的任意文件下载漏洞挖掘和总结思考
  - 下载各种配置文件分析出用户凭据进行利用
  - 通过目录结构下载源码进行审计
  - 文件下载getshell：
    - 首先收集系统信息，包括系统版本，中间件，cms版本，服务器用途，服务器使用者信息，端口，web路径等，然后根据收集到的信息，下载配置文件，如weblogic，ftp，ssh，等，根据下载到的配置文件进行渗透。
      - 常见漏洞利用方式：
        
        下载到密码配置文件，下载到软件配置文件，如weblogic，ssh，ftp，数据库配置文件等，当解出密码后，进行登陆，getshell
        
        下载web目录的web文件进行代码审计
        
        一般是先猜测web目录的地址，在下载web业务文件，审计常用的漏洞，据架构不同常常分为以下几种方式:
        
        php+mysql ，审计常见的sql注入，代码执行，密码找回逻辑，文件上传等，进行getshell
        
        jsp+oracle| , 先下载/WEB-INF/classes/applicationContext.xml，再下载/WEB-INF/classes/xxx/xxx/ccc.class 进行反编译
        
        aspx+mssql
        
        下载日志
        
        下载日志文件，找到登录/上传/后台/ 操作，找到登录入口可以爆破，测试默认口令，弱口令，找到文件上传点则测试文件上传漏洞，找到后台操作试试有没有未授权访问
越权，文件遍历
目录遍历

文件上传处

1、文件上传XSS
2、普通上传

漏洞类型

java

shiro

shiro rememberMe反序列化漏洞（Shiro-550）

Apache Shiro框架提供了记住密码的功能（RememberMe），用户登录成功后会生成经过加密并编码的cookie。
在服务端对rememberMe的cookie值，先base64解码然后AES解密再反序列化，就导致了反序列化RCE漏洞。
影响版本
Apache Shiro < 1.2.4

特征判断
返回包中包含rememberMe=deleteMe字段

漏洞利用
检查是否存在默认的key。
这里我们使用一个 Shiro_exploit，获取key
Github项目地址：https://github.com/insightglacier/Shiro_exploit

shiro Padding Oracle Attack（Shiro-721）

由于Apache Shiro cookie中通过 AES-128-CBC 模式加密的rememberMe字段存在问题，用户可通过Padding Oracle 加密生成的攻击代码来构造恶意的rememberMe字段，并重新请求网站，进行反序列化攻击，最终导致任意代码执行。

影响版本
Apache Shiro < 1.4.2版本

逻辑漏洞

登录界面

安全测试之我见

图形验证码绕过

验证码刷新之后，而历史刷新的验证码还是可以继续使用
验证码使用过后不刷新，时效性不过期，可以一直复用
很多验证码的显示很简单，容易被机器识别

短信类验证码绕过

验证码过于简易&接口未限制：有些手机短信验证码都为 4-8位纯数字的验证码，在接口没有任何限制的情况下是可以直接爆破的
验证码发送复用&时效性过长&接口未限制：位数验证码时效性为5分钟，但是在这里同一手机号发送的验证码都是一样的，所以可以在4分钟的时候重新发送一次验证码这样验证码就又有效了，因为验证码一直在被复用，所以可以爆破
万能验证码：这是很多大企业的诟病，在未上线前为了方便测试加了888888、000000这样的万能验证码但是上线后没去删除测试的3内容导致被恶意利用

sql注入

漏洞原理
原理：开发者在编写操作数据库代码时，直接将外部可控的参数拼接到SQL语句中，没有经过任何过滤就直接放入数据库引擎执行。
把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。
漏洞危害
（1）攻击者未经授权可以访问数据库中的数据，盗取用户的隐私以及个人信息，造成用户的信息泄露。
（2）可以对数据库的数据进行增加或删除操作，例如私自添加或删除管理员账号。
（3）如果网站目录存在写入权限，可以写入网页木马。攻击者进而可以对网页进行篡改，发布一些违法信息等。
（4）经过提权等步骤，服务器最高权限被攻击者获取。攻击者可以远程控制服务器，安装后门，得以修改或控制操作系统。
测试方法
手工&自动化工具一把梭
SQL注入漏洞测试的方式总结
修复建议
- sql语句预编译
- 使用标准化的数据库查询语句API接口，进行参数过滤，转义等方式防止用户输入恶意字符

xss跨站脚本攻击

漏洞原理
XSS的漏洞主要成因是后端接收参数时未经过滤，导致参数改变了HTML的结构，从而被浏览器或后端代码执行
漏洞危害
1、网络钓鱼，包括盗取各类用户账号；
2、窃取用户cookies资料，从而获取用户隐私信息，或利用用户身份进一步对网站执行操作；
3、劫持用户(浏览器)会话，从而执行任意操作，例如进行非法转账、强制发表日志、发送电子邮件等；
4、强制弹出广告页面、刷流量等；
5、网页挂马，进行恶意操作，例如任意篡改页面信息、删除文章等；
6、进行大量的客户端攻击，如DDoS攻击；
7、获取客户端信息，例如用户的浏览历史、真实IP、开放端口等；
8、控制受害者机器向其他网站发起攻击；
9、结合其他漏洞，如CSRF漏洞，实施进一步作恶；
10、提升用户权限，包括进一步渗透网站；
11、传播跨站脚本蠕虫等；
测试方法
- 找到一个存在问题的地方，提交一下代码，如果出现弹窗或者打开开发者，发现报错，即为XSS漏洞
- 获取流量，对流量进行分析，比如Xray
修复建议
a、在服务器端检查敏感的HTML代码，对敏感字符进行转义
b、接入xss过滤平台，做统一的XSS关键字的过滤及管控

csrf跨站请求伪造

漏洞原理
CSRF：跨站请求伪造，在一个用户登录一个网站后会产生一个cookie，在没有登出的情况下，访问另外的页面，这个页面向该网站进行请求，网站仅用cookie做验证，没有做其他的校验，从而认为这个请求是合法的，就带来了CSRF跨站请求伪造漏洞。
漏洞危害
修改任何允许修改的数据，执行任何用户允许的操作，例如修改密码，登录注销等
测试方法
Csrf多处存在于修改增加删除等操作中都可以尝试使用跨站请求伪造
去掉一些认证字段如token、referer等认证字段，如果可以正常请求，说明存在漏洞
- GET类型的CSRF的检测
  如果有token等验证参数，先去掉参数尝试能否正常请求。如果可以，即存在CSRF漏洞
- POST类型的CSRF的检测
  如果有token等验证参数，先去掉参数尝试能否正常请求。如果可以，再去掉referer参数的内容，如果仍然可以，说明存在CSRF漏洞，可以利用构造外部form表单的形式，实现攻击。如果直接去掉referer参数请求失败，这种还可以继续验证对referer的判断是否严格，是否可以绕过
修复建议
1、添加验证码：在一些特殊请求页面增加验证码，验证码强制用户必须与应用进行交互，才能完成最终请求
2、检测referer：检测referer的值，来判断请求来源是否合法
3、添加Token：在每个请求中设置Token是一种流行的方式来防御CSRF。CSRF攻击的原理：攻击者可以猜测到用户请求，现在在每个请求中加一个随机的Toekn值
Token要足够随机————只有这样才算不可预测
Token是一次性的，即每次请求成功后要更新Token————这样可以增加攻击难度，增加预测难度
Token要注意保密性————敏感操作使用post，防止Token出现在URL中

XSS与CSRF的区别

XSS 是代码注入问题，CSRF 是 HTTP 问题
- XSS 是内容没有过滤导致浏览器将攻击者的输入当代码执行
- CSRF 则是因为浏览器在发送 HTTP 请求时候自动带上 cookie，而一般网站的 session 都存在 cookie里面(Token验证可以避免)。
CSRF：需要用户先登录网站A，获取 cookie
XSS：不需要登录
CSRF：是利用网站A本身的漏洞，去请求网站A的api
XSS：是向网站 A 注入 JS代码，然后执行 JS 里的代码，篡改网站A的内容。

ssrf服务器端请求伪造

漏洞原理

SSRF漏洞就是通过篡改获取资源的请求发送给服务器，但是服务器并没有发现在这个请求是合法的，然后服务器以他的身份来访问其他服务器的资源

漏洞危害

可以对外网、服务器所在内网、本地进行端口扫描，获取一些服务的 banner 信息
攻击运行在内网或本地的应用程序（比如溢出）
对内网 WEB 应用进行指纹识别，通过访问默认文件实现
攻击内外网的 web 应用，主要是使用 GET 参数就可以实现的攻击（比如 Struts2，sqli 等）
利用 file 协议读取本地文件等

漏洞检测
1、从WEB功能上寻找

分享：通过URL地址分享网页内容
转码服务：通过URL地址把原地址的网页内容调优使其适合手机屏幕浏览
在线翻译：通过URL地址翻译对应文本的内容
图片加载与下载：通过URL地址加载或下载图片
图片、文章收藏功能
未公开的api实现及其他调用URL的功能

2、从URL关键字中寻找

share、wap、url、link、src、source、target、u、3g、display、sourceURI、imageURI、domain

3.排除法：浏览器f12查看源代码看是否是在本地进行了请求

比如：该资源地址类型为 http://www.xxx.com/a.php?image=（地址）的就可能存在SSRF漏洞

4、dnslog等工具进行测试，看是否被访问

可以在盲打后台用例中将当前准备请求的uri 和参数编码成base64，这样盲打后台解码后就知道是哪台机器哪个cgi触发的请求。

5、抓包分析发送的请求是不是由服务器的发送的，如果不是客户端发出的请求，则有可能是，接着找存在HTTP服务的内网地址.
6、直接返回的Banner、title、content等信息
7、留意bool型SSRF

绕过方法

1、
1
30x跳转
：当防御方限制只允许http(s)访问或者对请求的host做了正确的校验后，可以通过30x方式跳转进行绕过
- 针对只允许http(s)协议的情况，我们可以通过
  Location: dict://127.0.0.1:6379跳转到dict协议，从而扩大我们攻击面，来进行更深入的利用
2、
1
URL解析绕过
- 通过url解析绕过只解析@后面的域名，列如： http://www.baidu.com@127.0.0.1
- 利用语言本身自带的解析函数差异来绕过检测，如在python3中，对于同一个url:http://baidu.com@qq.com，urllib和urllib3的解析就不一致。
3、DNS解析绕过:通过dns解析绕过私有地址限制探测内网列 www.127.0.0.1.xip.io
4、编码进制绕过:列如：ip进制转换
5、利用IPv6绕过:有些服务没有考虑IPv6的情况，但是内网又支持IPv6，则可以使用IPv6的本地IP如::1或IPv6的内网域名–x.1.ip6.name来绕过过滤

修复方案

禁止跳转
过滤返回信息，验证远程服务器对请求的响应是比较容易的方法。如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。
禁用不需要的协议，仅仅允许http和https请求。可以防止类似于file://, gopher://, ftp:// 等引起的问题
设置URL白名单或者限制内网IP（使用gethostbyname()判断是否为内网IP）
限制请求的端口为http常用的端口，比如 80、443、8080、8090
统一错误信息，避免用户可以根据错误信息来判断远端服务器的端口状态。
去除url中的特殊字符（为了防止利用url parse的特性造成url解析差异）
判断是否属于内网ip
如果是域名的话，将url中的域名改为ip（防止dns rebinding）
请求的url为3中返回的url
请求时设置host header为ip（为了防止以ip请求时，某些网站无法访问的问题）
不跟随30x跳转（跟随跳转需要从1开始重新检测）（防止30x跳转进行绕过）

越权漏洞

水平越权：普通用户之间操作可互相影响
垂直越权：低权限用户能操作高权限用户才能操作的东西

Bp 抓包查看并修改低权限用户的身份信息为同等权限的其他用户或者是高权限用户后进行重放
或用低权限的账户去访问高权限的账户的数据，一般是通过访问接口来进行测试
如果成功则说明漏洞存在

首先需要确认身份认证的字段，确认确认等字段进行认证，然后更换认证字段的数值，进行测试越权
如：测试通过Authorization字段进行认证，首先需要删除如cookie字段的认证，然后看是否有回显
若有，则表示Authorization字段是唯一认证，可直接进行测试
若无，则需要删除cookie字段的数值进行排查，确认cookie中是否有一些字段和Authorization一起认证，然后修改对应的字段进行测试

水平越权

漏洞原理
指攻击者尝试访问与他拥有相同权限的用户资源。例如，用户A和用户B属于同一角色，拥有相同的权限等级，他们能获取自己的私有数据（数据A和数据B），但如果系统只验证了能访问数据的角色，而没有对数据做细分或者校验，导致用户A能访问到用户B的数据（数据B），那么用户A访问数据B的这种行为就叫做水平越权访问。

水平权限漏洞一般出现在一个用户对象关联多个其他对象（订单、地址等）、并且要实现对关联对象的CRUD的时候。开发容易习惯性的在生成CRUD表单（或AJAX请求）的时候根据认证过的用户身份来找出其有权限的被操作对象id，提供入口，然后让用户提交请求，并根据这个id来操作相关对象。在处理CRUD请求时，往往默认只有有权限的用户才能得到入口，进而才能操作相关对象，因此就不再校验权限了。可悲剧的是大多数对象的ID都被设置为自增整型，所以攻击者只要对相关id加1、减1、直至遍历，就可以操作其他用户所关联的对象了。

测试方法
修改参数的值，若能看到其他账户的数据，即为水平越权

漏洞示例：

1	getAddress.do?addressId=12345

攻击者修改addressId即可得到他人的address信息

修复方案

在web层的逻辑中做鉴权
这个是最直接有效的修复方案：在web层的逻辑中做鉴权，检查提交CRUD请求的操作者（通过session信息得到）与目标对象的权限所有者（查数据库）是否一致，如果不一致则阻断。这个方案实现成本低、能确保漏洞的修复质量，缺点是增加了一次查库操作。我之前一直用这种方案来对已发生的水平权限漏洞做紧急修复。
把权限的控制转移到数据接口层中
最正规的方案：把权限的控制转移到数据接口层中，避免出现select/update/delete ... where addressID=#addressID#的SQL语句，使用selectt/update/delete... where addressID=#addressID# and ownerId=#userId#来代替，要求web层在调用数据接口层的接口时额外提供userid，而这个userid在web层看来只能通过seesion来取到。这样在面对水平权限攻击时，web层的开发者不用额外花精力去注意鉴权的事情，也不需要增加一个SQL来专门判断权限——如果权限不对的话，那个and条件就满足不了，SQL自然就找不到相关对象去操作。而且这个方案对于一个接口多个地方使用的情况也比较有利，不需要每个地方都鉴权了。
但这个方案的缺陷在于实现起来要改动底层的设计，所以不适合作为修复方案，更适合作为统一的控制方案在最开始设计时就注意这方面的问题。
在生成表单时，增加一个token参数
在生成表单时，增加一个token参数，即token=md5(addressId+sessionId+key)；在处理请求时，用addressId、sessionId和key来验证token。

垂直越权

漏洞原理
由于后台应用没有做权限控制，或仅仅在菜单、按钮上做了权限控制，导致恶意用户只要猜测其他管理页面的URL或者敏感的参数信息，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的
测试方法

用低权限的账户去访问高权限的账户的数据
一般就是修改token，通过接口来进行测试

修复方案

对需要权限的页面进行 SESSION 认证，对用户访问的每一个 URL 做身份鉴别

正确校验用户的身份和 token

文件上传漏洞

漏洞原理
文件上传是一种数据与代码分理原则的攻击
- 原理:网站WEB应用都有一些文件上传功能，比如文档、图片、头像、视频上传，当上传功能的实现代码没有严格校验上传文件的后缀和文件类型时，就可以上传任意文件甚至是可执行文件后门，通过脚本文件获得了执行服务器端命令的能力
- 危害
  
  : 恶意文件传递给解释器去执行，之后就可以在服务器上执行恶意代码，进行数据库执行、服务器文件管理，服务器命令执行等恶意操作。根据网站使用及可解析的程序脚本不同，可以上传的恶意脚本可以是PHP、ASP、JSP、ASPX文件。
  - 上传文件是Web脚本语言，服务器的Web容器解释并执行了用户上传的脚本，导致代码执行
  - 上传文件是Flash的策略文件crossdo-main.xml，黑客用以控制Flash在该域下的行为（其他通过类似方式控制策略文件的情况类似）
  - 上传文件是病毒、木马文件，黑客用以诱骗用户或者管理员下载执行
  - 上传文件是钓鱼图片或为包含了脚本的图片，在某些版本的浏览器中会被作为脚本执行，被用于钓鱼和欺诈
测试方法
1、查看是否是IIS6.0等搭建的，因为如果是这些服务器搭建的话我们是可以通过解析漏洞或者00截断来上传我们想要上传的文件
2、如果只是前端判断上传的文件后缀名的话，我们可以用Burp来绕过
3、如果是只判断了HTTP/HTTPS的请求包中的Content-type我们就只需要修改为合法的就可以上传了。
上传一个文件，通过一些方法绕过客户端和服务端的校验，具体方法总结如下：
文件上传漏洞总结
修复建议
- 文件扩展名服务端校验：判断文件类型，增加黑名单逻辑
- 文件内容服务端校验
- 上传文件重命名：使用随机数改写文件名跟路径
- 上传文件路径隐藏.
- 单独设置文件服务器的域名
- 文件上传的目录设置为不可执行，文件上传后会放到独立的存储上，做静态文件处理。

cors跨域资源共享漏洞

CORS配置不当—挖掘技巧及实战案例全汇总
 cors安全完全指南

漏洞原理
CORS，即跨源资源共享（Cross-Origin Resource Sharing）。同源策略（Same OriginPolicy）要求不同源之间是无法通信的，而CORS则是放宽同源策略以通过浏览器实现网站之间通信的机制
CORS全称为Cross-Origin Resource Sharing即跨域资源共享，用于绕过SOP（同源策略）来实现跨域资源访问的一种技术。
CORS漏洞则是利用CORS技术窃取用户敏感数据，CORS漏洞的成因是服务端配置的规则不当所导致的，服务器端没有配置Access-Control-Allow-Origin等字段
漏洞危害
1、获取用户数据
2、客户端缓存中毒：这种配置允许攻击者利用其他的漏洞，更改没有验证的字段，看是否正常回显。比如，一个应用返回数据报文头部中包含“X-User”这个字段，这个字段的值没有经过验证就直接输出到返回页面上，此时就可以结合XSS漏洞来利用。
3、服务端缓存中毒：利用CORS的错误配置注入HTTP头部，这可能会被服务器端缓存下来，比如制造存储型xss
测试方法
查看是否存在get请求的json形式敏感信息，在请求头中添加任意Origin值，如https://evil.com，查看返回头是否返回：Access-Control-Allow-Origin:https://evil.com和Access-Control-Allow-Credentials：true，若返回，则构造poc.html进行跨域读取数据。
CORS配置不当通常会导致的危害是用户敏感信息泄露，场景大多数是get请求方式返回的json形式的敏感信息（密钥、token，key等）。CORS配置不当属于响应头中的一种，其他还有X-Frame-Options、Content-Security-Policy等。漏洞利用成功的前提是，两个返回头必须为：Access-Control-Allow-Origin:https://evil.com
更改响应头Access-Control-Allow-Origin或Origin字段等，看返回头是否返回CORS配置字段
修复建议
1、仔细评估是否开启CORS，如果不必要就不要开启CORS。
2、如果是绝对必要的话，要定义“源”的白名单。尽量不使用正则表达式配置，不要配置“Access-Contol-Allow-Origin”为通配符“*”，同时严格校验来自请求的Origin值。
3、仅仅允许安全的协议，有必要验证协议以确保不允许来自不安全通道（HTTP）的交互，否则中间人(MitM)将绕过应用是所使用的HTTPS。
4、要尽可能的返回”Vary: Origin”这个头部，以避免攻击者利用浏览器缓存。
5、如果可能的话避免使用“Credentials”头，由于“Access-Control-Allow-Credentials”标头设置为“true”时允许跨域请求中带有凭证数据，因此只有在严格必要时才应配置它。此头部也增加了CSRF攻击的风险;因此，有必要对其进行保护。
6、限制使用的方法，通过“Access-Control-Allow-Methods”头部，还可以配置允许跨域请求的方法，这样可以最大限度地减少所涉及的方法。
7、限制缓存的时间，通过“Access-Control-Allow-Methods”和“Access-Control-Allow-Headers”头部，限制浏览器缓存信息的时间。可以通过使用“Access-Control-Max-Age”标题来完成，该头部接收时间数作为输入，该数字是浏览器保存缓存的时间。配置相对较低的值（例如大约30分钟），确保浏览器在短时间内可以更新策略（比如允许的源）。
8、仅配置所需要的头，仅在接收到跨域请求的时候才配置有关于跨域的头部，并且确保跨域请求是合法的（只允许来自合法的源）。

弱口令漏洞

漏洞原理

这个应该是与个人习惯相关与意识相关，为了避免忘记密码，使用一个非常容易记住的密码，或者是直接采用系统的默认密码等。相关的安全意识不够，总认为不会有人会猜到我这个弱口令的，相关的安全意识不够，总认为不会有人会猜到我这个弱口令的。

漏洞危害
通过系统弱口令，可被黑客直接获得系统控制权限。
测试方法
burp抓包或使用批量的脚本，来爆破弱密码
修复建议
规定密码强度，设置密码通常遵循以下原则：
（1）不使用空口令或系统缺省的口令，这些口令众所周之，为典型的弱口令。
（2）口令长度不小于8 个字符。
（3）口令不应该为连续的某个字符（例如：AAAAAAAA）或重复某些字符的组合（例如：tzf.tzf.）。
（4）口令应该为以下四类字符的组合，大写字母(A-Z)、小写字母(a-z)、数字(0-9)和特殊字符。每类字符至少包含一个。如果某类字符只包含一个，那么该字符不应为首字符或尾字符。
（5）口令中不应包含本人、父母、子女和配偶的姓名和出生日期、纪念日期、登录名、E-mail 地址等等与本人有关的信息，以及字典中的单词。
（6）口令不应该为用数字或符号代替某些字母的单词。
（7）口令应该易记且可以快速输入，防止他人从你身后很容易看到你的输入。
（8）至少90 天内更换一次口令，防止未被发现的入侵者继续使用该口令

URL跳转漏洞

漏洞原理

服务端未对传入的跳转url变量进行检查和控制，可能导致可恶意构造任意一个恶意地址，诱导用户跳转到恶意网站。

漏洞危害

由于是从可信的站点跳转出去的，用户会比较信任，所以跳转漏洞一般用于钓鱼攻击，通过转到恶意网站欺骗用户输入用户名和密码盗取用户信息，或欺骗用户进行金钱交易；还可以造成xss漏洞

漏洞检测

修改参数中的合法URL为非法URL，然后查看是否能正常跳转或者响应包是否包含了任意的构造URL

修复方案

1.若跳转的URL事先是可以确定的，包括url和参数的值，则可以在后台先配置好，url参数只需传对应url的索引即可，通过索引找到对应具体url再进行跳转；
2.若跳转的URL事先不确定，但其输入是由后台生成的（不是用户通过参数传人），则可以先生成好跳转链接然后进行签名，而跳转cg首先需要进行验证签名通过才能进行跳转；

3.若1和2都不满足，url事先无法确定，只能通过前端参数传入，则必须在跳转的时候对url进行按规则校验：即控制url是否是你们公司授权的白名单或者是符合你们公司规则的url：

1
2
3

function checkURL ( sURL) {
return (/^(https?:\/\/)?[\w-.]+.(yourDomainA|yourDomainB|yourDomainC).com($|\/|\)/i).test(sUrl)||(/^[\w][\w\/.-_%]+$/i).test(sUrl)||(/^[\/\][^\/\]/i).test(sUrl) ? true : false;
}