雷池社区版动态防护功能小测
原创
5 月底，雷池社区版 WAF 发布了动态防护功能。
毕竟需要测试这个功能，我先理解了一下动态防护的功能逻辑，应该是一种将后端返回的 HTML（JS）代码进行加密返回到前端，并在浏览器中完成解密、渲染来展示网页原有逻辑的功能。
老规矩，先看动态防护的优势
1、在一定程度上保护了前端代码的隐私性，后端只返回加密的 JS 代码，然后由浏览器解析完成真实页面的渲染。
2、能阻止爬虫行为，一些爬虫框架不支持 JS 代码执行，所以无法获取页面的真实内容，就被盾住了。
3、Anti 漏扫，一些漏扫就专门扫框架版本号，只要正则查找到框架版本号就说有漏洞也不做漏洞验证，通过动态加密可以把这部分内容混淆掉，自然就不会被漏扫报漏洞了。
动态防护引入后对网页的影响
雷池给网页赋予了新的技术特性，我们应该理解在实现这个特性的基础上可能会产生额外的开销。
1、由于引入了动态加密，加密后的数据会在浏览器中进行解密，所以解密速度和电脑配置以及浏览器内核有关，整体上会感觉页面载入会变慢。雷池这边处理的还比较友好，执行解密的过程会展示等待页面。
2、这个和好处 2 的相对的。开启这个功能，将会对站点的 SEO 有影响，动态加密的网页像是 SPA 应用，遇到没有 JS 代码执行能力的爬虫，将无法获取到页面的内容。
建议各位站长依照自己的业务需要，来看是否要进行动态防护。
PS：动态防护让我的网站从 SSR 一键变成了 SPA。
防护能力测试
被测站点：
是一个 JS 和 HTML 的混合页面，做为被测站点。
代码隐私保护
未开启动态防护：
开启动态防护后：
可以看到，原站的代码已经被加密了，无法直接看到原始代码。代码隐私保护能力测试通过：✔。
爬虫保护
测试脚本：
import requests
from bs4 import BeautifulSoup
# 获取HTML页面内容
url = 'http://waftest.testsite.cn/index.html' # 将这个URL替换为实际的HTML页面地址
header = { 'User-Agent':'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36 Edg/125.0.0.0' }
response = requests.get(url,headers=header)
html_content = response.content
# 解析HTML页面
soup = BeautifulSoup(html_content, 'html.parser')
#print(soup)
# 获取新闻列表
news_items = soup.find_all('li', class_='news-item')
# 提取新闻标题和内容
news_list = []
for item in news_items:
title = item.find('h2', class_='news-title').text
content = item.find('p', class_='news-content').text
news_list.append({'title': title, 'content': content})
# 打印新闻列表
for news in news_list:
print(f"标题: {news['title']}")
print(f"内容: {news['content']}")
print('-' * 40)
if len(news_list) == 0:
print("爬虫失败了...")爬虫无法获取到真实页面的内容，所以无法解析网页的内容，测试通过：✔。
Anti 漏扫
测试网站使用了不安全的 JQuery 框架，存在 CVE-2016-7103 漏洞。本次使用的漏扫是根据读取到文件的版本号和漏洞数据库进行匹配，判断是否为漏洞。本次匹配的 JQuery 版本是 1.1.0。
测试脚本：
import requests
def check_version_in_webpage(url, version):
# 发送HTTP请求获取网页内容
header = { 'User-Agent':'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36 Edg/125.0.0.0' }
response = requests.get(url,headers=header)
# 检查请求是否成功
if response.status_code == 200:
# 检查网页内容中是否存在特定版本号
if version in response.text:
return True
else:
return False
else:
print(f"Failed to retrieve the webpage. Status code: {response.status_code}")
return False
# 示例网址和要查找的版本号
url = "http://waftest.testsite.cn/index.html"
version = "1.1.0"
# 检查网页中是否存在指定版本号
if check_version_in_webpage(url, version):
print(f"Version {version} found in the webpage. CVE-2016-7103!!!!")
else:
print(f"Version {version} not found in the webpage. SAFE!!!!")开启动态防护前，漏洞扫描结果存在 CVE-2016-7103。开启动态防护后，漏洞扫描结果不存在 CVE-2016-7103。
成功使用了动态防护功能，绕过了不必要的漏扫，测试通过：✔。
动态防护逻辑分析
以雷池 v6.0.2 为例。在架构中，新增了一个 safeline-chaos 的容器，负责动态防护。默认运行在 tcp 23333 端口上，是一个 Rust 的程序（长亭牛皮，技术栈追新点赞）。
tengine 配置的变化，在 safetable.conf 中，新增了两段配置来支持该功能。
定义了 chaos 服务器的地址。
foreach_server 中增加了 location @safeline_chaos 的配置。按照 t1k 协议的定义，每个被代理网站中都会插入这段代码块。
尝试查了一下 t1k 的定义，很遗憾没有找到 tx_chaos_pass 相关含义的描述。由于 C 语言版本的 t1k 支持响应修改，猜测可能会将 Respose Body 转发给 chaos 进行加密（类似于响应的修改）。
动态防护前端解密算法分析
以雷池 v6.0.2 为例。测试网站是一个由 JS、HTML 以及 Frame 组成的 UPS 管理卡页面。
未加密时，大小为 640B。
开启动态防护，大小为 102kB。前后比较，发现 Response Body 体积增大了不少。
未加密时，页面渲染时间图：
开启动态防护，页面渲染时间图：
前端界面算法分析，断点调试，发现加密算法为 AES-GCM。
在前端代码中，定义了 encrypted（加密数据），以及 tag，raw_key 和 iv（与 AES-GCM 相关）。
var encrypted
var tag
var raw_key
var iv
// 解密
var decipher = forge.cipher.createDecipher("AES-GCM", raw_key);
decipher.start({
iv: iv,
tag: tag
});
decipher.update(forge.util.createBuffer(encrypted, "raw"));
var pass = decipher.finish(); // 解密完成的标志，完成之后会开始渲染 HTML。
// 渲染 HTML（操作 Dom）
var newDoc = new DOMParser().parseFromString(decipher.output, "text/html");
setTimeout(function() {
ocument.head.innerHTML = newDoc.head.innerHTML;
document.open();
document.write(decipher.output);
document.close()
}, 3e3) // 3e3 = 3 X（10 的 3 次方）3000 ms断点断出来的解密结果：
这样看，HTML 增大的部分，除了 BASE64 的 LOGO，猜测可能是 node-forge 引入的原因。
顺便我想试试对纯 JS 的保护能力，好像没有识别出来 JS 资源？
整体总结
动态加密功能常见于企业级的 WAF 中，雷池又一次把企业级功能释放给社区和专业版来用，让普通用户也能体验到企业级 WAF 的优秀功能，整体上来说是非常棒的。
对于动态加密的一些问题，雷池社区也在积极响应，让我们一起期待后续版本的大招吧！
以上为对社区版动态加密功能的一些简单分析，希望各位师傅批评指正。
参考资料
文章作者: 小谈谈
文章链接: https://www.txisfine.cn/archives/ae22a391.html
版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 弹霄博科！
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。