整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
今天介绍一种走私技术，HTML Smuggling，这不是一种特别新的攻击方法，但是它确实在越来越多的攻击场景中出现，其中就包括网络钓鱼。接下来我们就来了解一下HTML走私的来龙去脉以及它在钓鱼中是怎样被利用的吧。
什么是HTML走私？HTML走私是指，浏览器根据HTML文件的内容在主机上创建恶意文件，而不是直接转发/下载恶意软件的一种技术。HTML走私可以通过在HTML页面中将恶意文件隐藏为编码后的“string”来绕过外围安全性检查和在线检测。
大多数周边/在线安全检测方法都是通过匹配文件中的某些特定模式。但在HTML走私的情况下，恶意文件被嵌在浏览器中，所以检测这样隐藏的代码是困难的。而且由于代码中的混淆，甚至检测HTML走私这种情况本身也很困难。
在去年也就是2020年的网络钓鱼调查中，我遇到了两种本质上不同的HTML走私方式。这两种方案都将数据存储在HTML文件中，并且提供了无需向服务器发送额外请求就可以“下载”数据的方法。此外，这两种方案都是基于HTML5的下载属性（虽然不是强制性的但是有好处）。
先介绍第一种方案，基于JavaScript Blob，也是我经常看到的方案。Blob对象表示一个不可变、原始数据的类文件对象。它的数据可以按照文本或二进制的格式进行读取，也可以转换为ReadableStream来读取。借助Blob，我们可以将我们的恶意文件存储在HTML代码中，然后将其置入浏览器中，而不是直接向Web服务器发送文件上传请求。
我们可以通过下面两个链接来创建我们的HTML页面：
https://gist.github.com/darmie/e39373ee0a0f62715f3d2381bc1f0974
https://developer.mozilla.org/en-US/docs/Web/API/Blob
要存储文件，首先，需要将文件编码为base64，可以在PowerShell中使用一下代码来实现：
$base64string = [Convert]::ToBase64String([IO.File]::ReadAllBytes($FileName))
然后替换下面html文件中<>所指的值。fileName变量表示你希望在默认情况下下载文件的名称。base64_encoded_file变量存储base64编码后的文件。
<html>
<body>
<script>
var fileName = <>
var base64_encoded_file = <>
function _base64ToArrayBuffer(base64,mimeType) {
var binary_string = window.atob(base64);
var len = binary_string.length;
var bytes = new Uint8Array( len );
for (var i = 0; i < len; i++) {
bytes[i] = binary_string.charCodeAt(i);
}
return URL.createObjectURL(new Blob([bytes], {type: mimeType}))
}
var url = _base64ToArrayBuffer(base64_encoded_file,'octet/stream')
const link = document.createElement('a');
document.body.appendChild(link);
link.href = url;
link.download = fileName;
link.innerText = 'Download';
</script>
</body>
</html>
现在只要我们点击上面的链接，就会开始下载步骤。
实现HTML走私的另一种方案是使用DataURL。这种解决方案就不需要使用JavaScript了。使用DataURL进行HTML走私的目标就是将较小的文件嵌入HTML文件中。
虽然上面强调了小文件，但是实际上，限制也不是很严格。DataURL的最大长度由浏览器中的最大URL长度决定。比如，在Opera中，这个大小是65535个字符，虽然这个字节数对于转移1080p的电影来说是远远不够的，但是用来反弹shell已经足够了。
这种方法比第一种基于JS Blob的要简单得多。先看一下语法：
data:：前缀；
[<mediatype>]：可选项，是一个MIME类型的字符串，比如我们最常见的image/jpeg表示JPEG图像，如果缺省，默认值为text/plain;charset=US-ASCII；
[;base64]：可选项，如果数据是base64编码的，那么就用;base64标记
,：将数据与控制信息分开；
<data>：数据本身。
<html>
<body>
<a href="data:text/x-powershell;base64,aXBjb25maWcNCmhvc3RuYW1l"
download="test.ps1">
Download
</a>
</body>
</html>
这是一个简单的HTML例子，加载该页面的时候会显示一个download按钮。我们点击下载，浏览器就会将test.ps1文件保存到我们的电脑上。而写入的内容自然就是aXBjb25maWcNCmhvc3RuYW1lbase64解码后的内容。
发现了一个比较有意思的事情。当讲将<a>标签中的download去掉后，也就是变成了下面的样子：
<html>
<body>
<a href="data:text/x-powershell;base64,aXBjb25maWcNCmhvc3RuYW1l" >
Download
</a>
</body>
</html>
我们重新在Chrome浏览器中打开并尝试下载，这个时候发现，这个按钮已经失效了，点击不会有任何反应。但是用Firefox打开，依旧可以下载文件，只不过firefox会创建一个随机的文件名，并且保存的文件不会有后缀：
综上，我们可以将DataURL和JS Blob相结合来添加一个函数，当然我们可以不适用任何脚本，但是和上面的例子中的问题一样，显然会更到更多的限制。
HTML走私是钓鱼攻击一个很好的补充。在HTML走私的帮助下，攻击者可以逃避一些检测和记录机制。在这种方式下，文件被“注入”到HTML文档中，而绝大多数的安全解决方案根本不会去检测。
当然HTML走私也有一些缺点。首先，它需要用户交互，虽然浏览器会自动处理恶意文件，但是下载到用户主机还是需要用户同意，除非配置了未经用户确认的自动下载。而且即使文件被下载了，还是需要将其执行。
上面介绍了两种常见的HTML走私方法，回到文章的主题，如何利用HTML走私来进行钓鱼呢？这里介绍两种比较常见的方法。首先，第一种是让电子邮件包含一个指向外部网页的链接，而该指向的网页使用了HTML走私技术。这是比较常见的邮件钓鱼方式。另一种方法是，在电子邮件中添加一个HTML附件，该HTML文件走私了恶意代码，这种情况下，用户打开的就是本地的HTML文件，不需要访问外部站点。
在这两种情况下，好处是恶意内容很难被检测到，因为恶意代码隐藏在HTML内容中。通过这种方式，可以绕过很多道安全防御。
首先，我们来看一下正常的文件下载步骤是怎样的。在下图的例子中，用户访问一个网站，然后下载一个exe文件：
1 . 首先，用户打开一个正常的网站。这个网站可以是用户自己输入的，也可以从包含链接的钓鱼邮件中获得。
2 . 浏览器向网站发送HTTP请求。如果存在代理，那么这个流量就会走代理。
3 . 代理会检查浏览器请求的URL。因为许多的代理都有检查域信誉的能力，如果代理认为请求的域是恶意的，那么Proxy不会进行后续的请求，通信将在这一步就停止；反之，代理会将请求转发给Web服务器。
4 . Web服务器返回请求的资源给代理，在本例中，Web服务器返回的就是一个普通的HTML页面。
5 . 代理检查Web服务器的响应。在这一步会进行各种过滤。代理可以阻止用户下载一些类型的文件。此外，代理可以有一个内置的沙箱来测试文件是否安全，而HTML文件通常不会再沙箱中进行测试就被允许通过代理转发给用户。
6 . 页面通过代理转发给浏览器。此时判断文件可信度的角色就变成了用户，用户可以决定浏览器中显示的某个文件是否安全，如果用户信任，就可以进行文件下载，在本例中，该文件是一个exe文件。
7 . 浏览器向Web服务器发送文件下载请求。
8 . 代理的处理和之前相同，这一步没什么区别。
9 . Web服务器将请求的exe文件发送给代理。
10 . 当代理获得该exe文件时候，它会对其进行综合性评估。如果设置了网络中禁止下载exe文件，那么显然，exe下载请求在这一步就结束了，文件将无法到达用户的机器。代理还会检查文件是否是已知的恶意文件。此外，它还可以决定是不是要将文件放到沙箱中进行测试。这里有一个关键点，当代理知道这个文件是一个可执行文件时候，它可以决定是不是要继续转发。而且，网络分路器（Network Taps）可以检测到这个exe文件，如果它们认为该文件是恶意的，也可以阻止用户下载该文件。
11 . 如果一切顺利，那么文件就到达了它的最终目的地——用户的电脑。
在上面的步骤中，最重要的一步就是第10步。这一步有普通文件下载和HTML走私下载的最大区别。在正常下载的情况下，exe文件易于检测和评估（比如检查散列，沙箱执行检查，收集头文件信息来判断等等）。而在HTML走私的情况下，文件不会以一种未编码的方式在网络上传播，它总是会被嵌入到另一个HTML文件中。
首先，先介绍一种很常见的走私技巧。在这种情况下，攻击者会将事先准备好的链接放入电子邮件中。该链接会指向包含走私文件的外部链接。在这种情况下，恶意的内容不会通过电子邮件的网关，而是以隐藏的形式，通过代理被用户访问。
1 . 有一个带着外部链接的e-mail向目标用户发送。
2 . 邮件网关对邮件进行检查。在这一步有很多种检查方法，但在本例的场景下，我们就认为邮件网关并不会阻拦该邮件，因为这里没有包含什么恶意文件。
3 . 用户点击邮件中的链接。
4 . 默认浏览器启动。
5 . 浏览器向存储（或是生成）HTML文档的外部站点发送HTTP请求。
6 . 代理会进行一些必要的检查，但是如果该URL并没有被加入黑名单，那么该请求就会被转发到该站点所对应的服务器。
7 . 服务器返回HTML页面以及隐藏在其中的exe文件。exe文件是以字符串的形式存储在文档中，此时它已经变成了HTML内容的一部分。
8 . 代理会检查响应内容。在本例中，响应只是一个HTML文件，代理不会去拦截HTML文件。而且，HTML文件在绝大多数情况下不会被转发到沙箱中执行检查。因而，隐藏在HTML文档中的恶意内容几乎不会在这里被检测到。当然通过其他的检测技术，它们也可能能识别到HTML走私技术（但是这里指的也只是HTML走私这件事本身，而不是隐藏在HTML中的恶意文件）。现在我们就认为代理没有识别出这个情况，将响应HTML页面转发给浏览器。
9 . 浏览器重新拼接嵌入在HTML页面中的字符串，然后启动下载进程。
10 . 最后恶意exe文件被存储到用户的电脑上。
我们可以看到，在这种情况下，e-mail的安全检查机制并不能起到太大的作用。因为电子邮件本身不是恶意的，其中的链接可以是合法的链接。
代理当然可以查看HTML文件，但是很少有安全性检测方案会对HTML文件进行彻底地处理。大多数情况下，这些文件都是被允许通过代理的。IDS解决方案还倾向于依赖检测文件扩展名或是magic bytes（主要是通过分析文件的第一个字节来判断文件的类型），因此文件中的编码字符串很难被它们捕获。但是其实我们可以创建一个模式匹配解决方案来检测一些隐藏在HTML中的东西。这在后面会提到。
这种方法是指包含走私的HTML文件被附加到了电子邮件中。
1 . 邮件网关收到一份带有HTML附件的电子邮件。
2 . 邮件网关会对电子邮件中附带的HTML进行检查。如果检查未通过，那么邮件网关会阻击电子邮件的后续转发或者选择删除附件。但是，现在还没有听说过什么电子邮件安全解决方案能够通过静态分析或者动态分析来检测HTML走私（即使是在HTML走私的是恶意代码。）
3 . 用户打开HTML附件。
4 . 浏览器打开并加载HTML文档。
5 . 浏览器处理HTML文件的内容，处理被走私的文件并将其提供给用户下载。
6 . 文件被保存到计算机上。当然，在这一步，要么需要用户的批准，要么需要浏览器设置了自动下载，就是未经确认的下载。
这种方法相比上一种的好处就在于，它不需要通过任何代理。而且，网络上的IDS/IPS安全检查通常不会去检查电子邮件，所以，如果攻击者能够成功欺骗电子邮件网关，那么在网络上就没有其他的难处了。
在这一小节中我们来探讨一下如何防御与检测HTML走私。
在发生了HTML走私的情况下，我们可以有两种检测方式，我们要么就关注HTML走私技术本身，要么可以尝试捕获隐藏在HTML文档中的恶意代码。
这里介绍几种防御方法。
虽然对于HTML走私没有什么万能的防御办法。禁用JavaScript看起来是一种可行的方案，毕竟一种HTML走私技术就是基于JavaScript Blob的，但是，在企业环境中禁用JS肯定会带来很多问题。当然，如果在你遇到的显示场景中，禁用JS是可行的，那么也可以尝试这种方法，那么在这个时候，你只需要用模式匹配去识别DataURL是不是存在HTML走私情况就好。
HTML走私的一种类型是使用HTML文件作为附件。不幸的是，这在很多场景中都是常见的，实际上，现在有很多带有HTML附件的合法的、与业务相关的电子邮件在增加。另一方面，不法分子也利用HTML附件来进行钓鱼。
如果你能在不影响业务的情况下阻止带有HTML附件的邮件，那么对于利用邮件中带有的HTML来进行钓鱼的路就被堵住了。那此时我们只需要关注邮件中附带的链接了。
我们可以看到，前面这两种防御方法都无法同时覆盖所有的HTML走私情况。在最好的情况下，我们可以使用这两种方案来防住部分HTML走私；在最坏的情况下，我们甚至都不能使用这些防御解决方案，因为这些方案在大多数现在企业环境中是不适用的。
Microsoft Defender Application Guard是Windows提供的一种安全解决方案，主要用于隔离各种试图使用来自不可信源资源的应用程序，后面简称MDAG。MDAG有两种不同的形式。第一种是Application Guard for Edge，它主要是用来隔离企业定义的不受信任（或不特别受信任）的站点，在企业的员工浏览Internet时保护公司。Application Guard通过在一个启用了Hyper-V的隔离容器中打开站点来实现这一点。而且，它还与Firefox和Chrome浏览器兼容。
另一个版本是Application Guard for Office。它能够保护可信资源不受不可信资源的攻击。它也是通过在一个容器中打开不受信任的Word、Excel、PowerPoint文档来实现。当然，这也和HTML走私无关，所以就不继续讨论了。
我们已经知道，Application Guard for Edge主要是通过在隔离的虚拟环境中打开不受信任的链接来保护我们的系统。如此一来，一个未知的URL，或者说是一个恶意的URL就不会对主机造成危害了。下载的恶意文件会被隔离存储在隔离的环境中，而不会直接与宿主机接触。
如果一个链接在电子邮件中到达，并且给定的URL并不在Application Guard的白名单中，那么它就会在一个隔离的Edge中被打开。因为对于该URL的访问是在隔离的环境中进行的，那么每个文件下载行为也都是在这个隔离的环境中进行的，因此被走私的恶意文件不会对主机造成真实伤害。
当然，这个解决方案也并不是十全十美的。它也有一些缺点：
1 . 为了使Edge能发挥作用，你需要使用白名单和untrust来标记一切网站。这在大公司中，意味着相关的管理员需要承受巨大的负载。因为用户会不断地进行异常请求。
2 . 虽然Application Guard能够防住以链接形式附在电子邮件中的HTML走私请求，但是它无法防御以电子邮件附件形式传递的HTML走私。这些附件到达用户主机后，会作为本地文件在浏览器中打开，因此，这些文件不会被当作不受信任的域来处理，不会在隔离的Edge容器中打开这些HTML文件，也就不会触发Application Guard。因此通过电子邮件附件进行的HTML走私在这种情况下依然可以成功。
3 . 会影响用户访问站点的速度，因为需要启动容器。
如果HTML文件中没有利用JS来走私，而是仅仅使用了DataURL，在这种情况下，我们可以使用模式匹配（比如匹配data:）来判断是不是发生了HTML走私。我们可以实用IDS或是简单的YARA工具来检测，比如github上的开源工具LaikaBOSS就是一款可用的检测工具。
KaikaBOSS对于下载的文件（HTML文件），甚至是电子邮件附带的文件，都非常有效。它可以检测大量的数据，伸缩性很好，所以即使在大型环境中，也同样可以派上用场。
如果使用了JavaScript，那么可能代码是被混淆过的，此时模式匹配可能就不太有效果了。我们只能用其他的方法来检测混淆的代码。
在使用了HTML走私的场景下，被下载的文件是在浏览器中创建的，而在一般的下载场景中，我们可以看到，是需要我们向Web服务器发起请求，然后Web服务器传送给我们的，而且还会经过代理，经由代理检查文件的安全性。因此我们还可以通过关注普通文件下载和基于HTML文件创建下载文件之间的区别来鉴别HTML走私。因此我们可以通过查看代理日志、观察是否有浏览器进行在主机上创建文件等方式来查看是不是发生了HTML走私。
这种方式的缺点在于：
1 . 许多流量在默认情况下不会通过代理。比如，一些公司会配置它们的网络，使其内部网站无法通过代理访问。这个时候，如果通过浏览器生成了一个文件，但是没有代理日志。这种情况经常发生，不应该基于这种情况创建警报。
2 . 在一些情况下，用户可以绕过代理，也不会产生代理日志。
3 . 可以在浏览器中打开本地文件，然后保存为新文件，这也是浏览器创建的文件，同样没有代理日志。
如果用户是在上面的情况下进行合法行为，我们都不应该进行拦截，因此难点就在于我们很难区分这是不是一种走私情况。
您可以将HTML文件发送到沙箱，然后使用沙箱中的浏览器打开它。不是通过互联网访问的HTML文件除了一些临时文件之外，不应该在机器上创建任何文件。理论上，如果在没有网络访问的情况下，HTML文件在沙箱中创建了文件，那么沙箱应该要发出一个警报来提醒用户。
但是，经验表明，HTML文件通常不会放到沙箱中打开。它们可以通过静态分析进行检查（如LaikaBoss），也可以动态分析进行检查，但是动态分析将花费更多的时间，并且会显著降低网络速度。
但是沙箱这个解决方案在大多数的情况下不是特别友好，因为在转发给用户之前打开每个HTML文件负载也挺大的。而且，如果恶意文件是需要用户点击下载的，那么这种方式也行不通，只有在页面配置了自动下载的情况下，我们才能通过沙箱来检测。所以总体来说，这也不是一个特别好的方法。
另一种方式是使用取证分析中可能会使用的技术——Zone.Identifier来区分是不是发生了HTML走私。
由HTML走私创建的文件的Zone.Identifier是这样的（在新版Edge、Chrome和Firefox测试过）：
[ZoneTransfer]
ZoneId=3
HostUrl=about:internet
而正常下载的文件的Zone.Identifier则是（这在不同的浏览器之间存在区别）:
[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://www.sans.org/security-resources/posters/windows-forensic-analysis/170/download
HostUrl=https://www.sans.org/security-resources/posters/windows-forensic-analysis/170/download
这种方法的局限就在于，它只能在Windows(NTFS)上这样做。因此这种方式也不是完全可靠的。
Chrome会存储下载文件的来源，如果源是JavaScript Blob或是DataURL，那么这些信息就会作为源显示。
当我们打开一个本地的HTML被走私文件：
当然上面的信息不会告诉我们该被走私的恶意文件是从哪里下载的。
当我们访问远程的走私HTML文件时，我们就可以看到相应的恶意文件下载URL了，但是也仅仅是在走私文件是使用了JS Blob时能看到，在使用DataURL时则不会显示远程链接：
这种情况相比前面的几种方法看起来更加实用。在远程访问，并使用了JS Blob的情况下，我们甚至能看到恶意文件的真实来源，如果攻击者使用了DataURL，我们还可以利用这个信息重新生成文件，这在一些场景下可能也是有用的。
总体来说，目前想要完全检测和防御HTML走私是一件比较困难的事情。当然，上面介绍的方法也只是相对简单地介绍了HTML走私下的钓鱼事情，在现实攻击场景中，可能会遇到更复杂的情况。
创： K 合天智汇
这篇文章，将教大家基本的手工sql注入和绕过waf的知识；分享一个实例，为了效果建议读者自己去搭建环境，因为真实环境都不怎么理想。
1. sql注入的基础
2. sql注入绕过waf
3. sql注入一个绕过实例
手工sql注入的基础
基础注入，盲注注入（时间和bool），报错注入，联合注入（union）
推荐sql-labs资源这个练习平台，推荐《mysql注入天书pdf》
1.base（基础的语句注入）
我们利用该表可以进行一次完整的注入。以下为一般的流程。
1）猜数据库
2）猜某库的数据表
3）猜某表的所有列
4）获取某列的内容
2.union注入
union注入和基础的注入相差不大，只需将前面的数据置0，即没有那个指定字段即可；当然先要确定字段，下面的文章有分析
3. 时间注入
主要用到一些截断字符对数据库的字符进行判断
1）先试数据库的长度，当数字为6时发生了延时，说明数据库名共五个字符。
2）开始猜数据库的字（当发生延时，说明当前数据库第一个字母为m）：
3）其他的数据只需修改查询语句即可
4. bool注入
是根据回显，对的查询是一种回显，错的查询又是一种回显
也是字符截断函数来操作的
if(length(database())>8,1,sleep)
其他的不多说了
5. 报错注入
是通过报错函数来进行操作的
https://www.cnblogs.com/wocalieshenmegui/p/5917967.html 十种报错注入
作者常尝试的是这三个报错函数updatexml，exp，floor
sql注入绕过waf
ok，这是本篇的重点
作者就不填写那些网上普遍有的，给出几个记得到并且常用的,但是有些简单的还是要简单试下
1. 大小写混写
2. 编码试下 作者常用url编码；拿到数据库名和表名常用16进制替换他们的名字
3. 替换
and &&
or ||
相同函数的替换（这个先要过前面的引号闭合，字符过滤；前面的如果过不了，一般作者都考虑不到这，真要用到时才换）
4. 注释绕过
1）内联/*!50000*/，一般是被杀了的
2）/*!50000union/*!50000/*!(select*/~1,2,3) （过安全狗写法，亲测可用，下面实际操作我们将这样操作）
3）句末注释：//, -- , /**/, #, --+,-- -, ;--a
作者常用 -- -，屡试不爽（一般+是被过滤了的）
实际运用
手工操作一波,我的测试过程：
单引号走起
这种情况gpc一般是打开了
双引号，同样如此：
ok，其实我们首先应该确定是字符型参数还是数字型
当id=2
id=1+1
这里+是被过滤了的，所以我们用-来做个运算
一切正常
ok，说明是数字型的参数，那么就不用引号闭合，可以进行接下来的注入
（这里给大家补充一点小知识：cms审计时，这种id之类的都是inval函数处理的；其他的cms地方sql注入漏洞很有一些是因为数字型参数不需要引号闭合进行操作的）
如果是字符型的怎么办，字符型的gpc情况确实不好办，作者遇到的基本是编码绕过：这里的编码是gbk的编码，sprint函数这类的编码漏洞绕过；编码漏洞情况同样适合xss漏洞，都是绕过waf。
这里，作者是先进行常规注入，id=2 order by 2
id=2 order by 1 正常
说明只能显示一列数据了
OK，我们进行union测试
发现了什么，union不见了
不急，我们有姿势
双写union（作者还真看到过只过滤一次关键词的代码）
嗯，看来是过滤那个单词大小写（虽然过时了，现在匹配函数都直接大小通杀，不妨碍随手试下）
看到UNIon被ban了
OK，不要着急，我们试下其他的方法
用过狗方法，这里就这样过了（普通内联试过无法）
但美中不足的是网站的数据库系统配置出了问题，出现下面这个错误
作者这样尝试
不指定库也是查找当前库；再尝试用limit0,1限制，效果也是如此
Illegal mix of collations for operation 'UNION'
遇到了这个问题，是数据库的编码不一样
原因参考：
https://www.cnblogs.com/google4y/p/3687901.html
ok，我们继续，作者直接or来取数据库
被ban了
|| 代替or
and呢（这比较有意思了，也是经常遇到了情况，waf特定情况才ban字符串，绕过本来就是经验和猜）
我们看到，没有语法错误，是正确的，那我们取下数据库呢
按照mysql的语法，作者原先以为没有错（其实是错的语法）
本地测试了下
错误，再多语句，分号试了下，是对的
想当然的给网址来了下分号（sqlmap中根据数据库的不同也有多语句测试）
当然是错误的
时间注入嘛，测试成功（突破口哦）
作者一开始这样测试
嗯，忘记单引号被过滤
用mysql的其他函数来解决
附上测试代码（sql时间盲注的代码除了sql的语句不同，其他的类似；bool盲注，就是修改返回判断条件，if “aaa” in res.content:，bool就没有去测试了，有兴趣自己试一下吧）
报错注入试下：
这么多报错函数，就没有一一去测试
总结
本篇文章较基础，但对于作者来说，较全面了
手工注入知识就这些，更高级的就是各种姿势了
大体也是这个流程，这也是作者的所有干货了
文章仅用于普及网络安全知识，提高小伙伴的安全意识的同时介绍常见漏洞的特征等，若读者因此做出危害网络安全的行为后果自负，与合天智汇以及原作者无关，特此声明！
假设需要劫持http响应并在html页面中注入一段js代码后再传回浏览器，实现在浏览器出现一个弹框消息提醒。
由于原始html页面编码格式存在UTF-8、GBK等多种编码格式，如果注入的js包含中文消息的话，那么在UTF-8或GBK编码的页面就会有一个出现乱码。有没有办法做到不管是针对GBK、UTF-8编码的页面都能做到正常显示而不会出现乱码哪？
首先来分析一下产生乱码的原因，我们在浏览器看到的信息都是通过图形学手段在显示器上呈现出来的，而实际保存在计算机硬件上的都是0和1（因为计算机实现是基于二进制），那么计算机要显示、传递信息就需要依靠一套规则把一串串的0和1识别为正确的字符，这就是编码。
例如01000001在ASCII编码规则下对应字母A。相同的0/1串，不同的编码解析出的字符一般是不同的，因此如果html页面按照UTF-8的编码解析正常，那么按照GBK的编码解析就会是乱码了。根据上面的示意图，假设注入的js代码为utf-8编码格式，而原始html编码格式也为UTF-8编码格式，那么最终注入这部分中的中文就能正常显示，但是如果原始html为GBK编码，那注入的这部分js代码的中文就会显示乱码。
有一种unicode统一编码字符集，目标是把所有文字、字符统一编码，也就是一串0/1组合在unicode字符集下对应的字符是唯一的，不会存在歧义。而js是支持解析unicode字符的，那么就可以在注入js中把要显示的消息统一转换为unicode编码，浏览器端去解析这个unicode编码，这样不管原始html是UTF-8还是GBK，都能正常显示中文。
原始注入js代码关于中文字符的部分
// utf-8编码格式
let message = "中文";解决乱码的注入js代码关于中文字符的部分
// utf-8编码格式
let message = "\\u4e2d\\u6587"; // 这个编码对应上面的message"中文"注意：
*请认真填写需求信息，我们会在24小时内与您取得联系。
