文章 - 终端PC Web安全 PartA

多数行业Windows APP已经过渡到了Web化，Web PC容器足够稳定，版本迭代稳定，错误率更少，跨平台方便，相对C/C++客户端，成本更低。

对于C/C++客户端开发来说，这是一把双刃剑，优点是减少了客户端UI工作量，可以把工作效率释放出来，但是过剩的C/C++开发可能被淘汰。

商化产品过程中，也经历过从Duilib、QT，到内嵌CEF，WebView2.0和Electron，参与过不同Web商化产品研发工作。内嵌浏览器本质还是浏览器，以PC APP的形式，可以提供更丰富的体验和功能。

收益和用户体验是重中之重，两者相辅相成，好的体验不一定能转化更高的收益，反之问题将被最大化，通常安全数据维度偏向软件生效率和错误率。

客户端安全性分为内和外，内因如研发BUG，程序内存数据修改和破坏，接口安全权限过高被滥用等。外因如注入，被拦截，流量代理篡改等。很多团队都会上驱动或者更底层的保护方案，其次尽可能将数据维度丰富起来，具备标签和分析能力。

在原有的安全基础上，增加且不局限于Cookie，Web通信，XSS，CSRF等漏洞防御能力，属于Web安全和终端安全一次融合，在原有能力成熟度上做加法。

PC Web安全系列文章，也是和大家一起交流讨论，面对软件安全的复杂性，如何提升产品的防御能力成熟度。

PC Web APP

软件应用都是有生命周期，安全流程体系来说分为事前，事中和事后，不同的场景三要素的认知不同，流程和对应的安全方案也是天差地别，对于终端APP安全来讲：

事前不局限于系统环境，软件运行环境，登录保护，身份认证等。
事中不局限于接口请求，运行态安全，数据态安全，权限管控，审计等。
事后不局限于可追溯，可排查，可定性。

URL Awareness

URL感知？听上去有点扯，实际很多商化产品已经做的比较完善，URL可以感知当前的运行环境，是不是运行在PC容器中。

防护属于事前和事中，加载数据之前检测软件运行环境环境，双向认证等。但是要考虑业务，过渡的安全措施可能会影响性能和用户体验。检测方案不局限于浏览器感知，包括接口安全和过程安全也同样适用。

聊天软件某微部分页面就会有运行环境感知，是不是运行在客户端，如果不是URL不会进行主要页面渲染，也不触发接口功能等。

逆向或抓包，很快就可以能梳理URL和接口列表，在浏览器开发者模式下调试易如反掌，但端内调试难度将会大大增加。

认证

基于Cookie数据认证，客户端加载URL后，Cookie包含客户端密钥和PC系统属性，识别属性信息判断是否运行在客户端中，Cookie不能直接暴漏，避免写入明文数据，Value数据要经过加密后在写入Cookie。

如上图，基于Cookie模式判别简单方便，但容易被攻击者仿造，或盗取Cookie进行绕过检测。

引入机制，PC Client环境和每次随机特征填充Cookie，浏览器加载获取Cookie后，基于规则或者约定对随机特征数据二次加密。浏览器回调客户端方法解密和确认数据，双向认证都通过后，客户端重新填充真实Cookie数据。

基于Cookie双向认证方式增加对抗难度，只要和浏览器约束特征规则，每次都可以随机运算，双方进行识别加密，破解会越复杂。

基于共享数据或通信认证，通过RPC和Socket方式，将客户端运行态的数据给发送给浏览器，客户端和浏览器握手来认证对方的合法性，需要完整性约束。

基于共享内存或通信认证要比Cookie对抗更复杂，而且灵活可控。客户端内存数据要靠逆向破解，不会通过浏览器Cookie暴露攻击面。Socket或者RPC双向认证完成以后，客户端将真实数据发给浏览器，浏览器这时候在写入到Cookie或跨域内存存储。

攻击者想要跑通流程，需要构造对应的模拟服务，攻击成本比较高。如Socket或者RPC Server，相当于做了客户端代理，还要分析私有协议，模拟RPC进行攻击，然后让页面认为和客户端建立完成认证，才可以正常渲染和调用业务接口。

基于三方服务认证，上面两种本质都是客户端和浏览器的双向认证，只不过变通了办法，增加了对抗难度。

双向认证也属于身份认证的一种，也有很多常规身份认证方法，但都属于业务认证/鉴权的手段，包括不局限于账号密码，二维码扫描，会话Cookie传输, JWT鉴权等。

这里探讨场景是PC Web环境运行安全，可以使用本地或线上Token服务认证，浏览器和客户端都会与认证服务握手。只有双方鉴权都成功，才会生效合法的Token，才能够获取合法的Cookie或者接口数据，正常加载浏览器，反之接口数据和浏览器都将会失效。

客户端和Web加载后基于特征数据生成认证Data，使用Server提前生成PublicKey数据加密。
客户端和Web分别发送加密数据到在线/本地认证服务，服务器进行认证，最好有完善的审计，认证成功以后分发Token。
Web接口请求和PC Client操作都需要基于Token，接口和PC Client基于Token鉴权并执行一定权限的功能请求。

题外话，感知当前运行在异常环境，采集数据，截屏系统态状态，发掘潜在威胁。

Loading Local Page

为了用户体验，缓解因网络或环境问题导致的加载Web页慢，卡等问题，设计WebPage Loading时候要求快速渲染界面，优先加载本地Loading Local Page也是解决方案之一。Loading Local Page跳转到线上Real Page。基于Loading Local Page利用非常简单无脑，但是提供了非常方便的注入办法，不能因为简单忽略带来的安全隐患。

某商化产品的Loading Local Page代码如下，为了用户体验，要求程序被双击后最快的速度渲染页面，也是采用了加载Loading Local Page方案，HTML JS先加载动画，再去请求接口获取JSON，解析数据跳转主URL。

......
......
const xmlHttpReq = new XMLHttpRequest()
xmlHttpReq.open()
xmlHttpReq.onreadystatechange=function(){
    ......
    location.href = res.data
    ......
}
...
xmlHttpReq.send()

加上两行代码，Loading Local Page就可以加载payload.js

<script type="text/javascript" src="require.js"></script>
    <script type="text/javascript">
        require(["launcher"]);
    </script>

function launcher() {
        alert("loading success.");
    }

    (function(){
        launcher()
    })()

Loading Local Page本身没有什么价值，但这种注入方式简单有效，可以跳转到精心伪造的钓鱼页面，盗取Cookie，安全隐患不可小视。

function launcher() {
        alert("loading success.");
    }

    (function(){
        launcher()
    })()

建议

1. PC Web商化产品，避免业务HTML存储在本地，非必要不包含业务接口请求，如XMLHttpRequest获取配置，可以在客户端中来做。

2. 客户端加载本地HTML之前，校验本地HTML完整性, 存在问题可覆盖本地文件重新加载或客户端请求线上加载。

PartB和大家分享关于入侵式注入CEF 、WebView2的攻击面。