企业官网建设流程全解析

1. 应用网关与HTTPS

1.1. 各业务团队各自保存自己的私钥，很容易出现保存不当或备份不当，比如将私钥备份文件存放在自己的个人电脑中，可能会在无意中泄露或被黑客窃取

1.2. 私钥文件明文放置在Web服务器文件系统中，可能会被木马通过翻找文件的方式窃取

1.3. 私钥文件可能被开发员工误上传到外部开源网站

1.4. 负载均衡

• 1.4.1. 支持多节点部署，支持用户侧负载均衡（对用户分流）​，以及后端负载均衡（调度到不同的后端入口）​

• 1.4.2. 如果只有一个入口，则其中任何一个业务面临DDoS攻击的时候，全部业务都会受到影响

1.5. 证书及私钥管理：能够基于访问的域名，动态调用对应的证书和私钥

1.6. 私钥保护：私钥本身属于敏感数据，需要额外的保护，建议加密存储

2. WAF

2.1. Web应用防火墙

2.2. WAF的作用就是拦截针对Web应用的入侵行为，如SQL注入、跨站脚本、文件遍历、WebShell上传或通信等

2.3. 单机WAF

• 2.3.1. 如ModSecurity、Naxsi等开源WAF模块，或者使用Lua扩展的Web服务器功能，直接部署在每一台目标Web服务器上，并整合到Web服务器软件里面

• 2.3.2. 该模式支持HTTPS

2.4. 中小型企业自建的扩展WAF

• 2.4.1. 采用扩展Web服务器功能，配合云端管理政策的模式，如基于Nginx + Lua扩展实现，需要在每一台目标Web服务器上部署，云管理的实现方式就比较多样化了

• 2.4.2. 比单机模式简化很多，管理员使用浏览器进行管理维护，在不新增Web服务器的情况下，还是比较方便的

2.5. 云WAF

• 2.5.1. 使用云服务商或第三方WAF服务，工作在反向代理模式，通常和CDN一起使用

• 2.5.2. 云WAF为了解密HTTPS流量，通常需要采用keyless方案，这种方案不需要租户交出自己网站的私钥，而是在用户和云WAF之间启用另外一张证书，在云WAF到真实服务器之间使用原来的证书

• 2.5.3. 无论是keyless方案还是严格的HTTPS方案，第三方的云WAF均需要对流量进行解密，所以不太适合对数据安全要求比较高的大型企业

2.6. 硬件WAF网关

• 2.6.1. 工作在网络层的硬件WAF，一般串行或旁路接入网络，直接对网络层IP包进行解包，*默认不支持HTTPS

• 2.6.2. 随着HTTPS的普及，工作在网络层的硬件WAF网关用处已不是太大

2.7. 软件实现的WAF应用网关

• 2.7.1. 应用网关（Application Gateway）​，或称为反向代理服务器，早期只有统一接入、反向代理、负载均衡等功能，但随着安全形势的严峻，应用网关也开始加入安全特性

• 2.7.2. 加入安全特性的应用网关，充分利用了各个模块的优势，消除了传统WAF的缺点，通常整合证书管理、HTTPS统一接入、WAF等功能

• 2.7.3. 与硬件WAF网关相比，软件实现的WAF网关除了可在自有机房部署，也可适用于云计算等场景下的部署

2.8. 无论是哪一种WAF，最基本的功能是可以对异常参数进行正则表达式匹配

2.9. WAF的控制点在入口，比如应用网关、单机WAF（与静态Web服务器如Nginx等整合在一起）​，防护引擎作用在应用外部，主要基于规则匹配，不区分应用的上下文

3. CC攻击防御

3.1. CC（Challenge Collapsar，挑战黑洞）攻击，是早期为绕过抗DDoS产品Collapsar而发展出来的一种攻击形式，是模拟大并发用户量，访问需要消耗较多资源的动态页面或数据接口，以达到耗尽目标主机资源的目的

3.2. CC攻击也是DDoS（分布式拒绝服务）的一种

3.3. 在CC攻击过程中，每一个请求看起来都是合法的，因此基于参数特征的防御机制就对CC攻击失效了

3.4. 对付CC防御，一般是基于访问频率和访问统计，在设定的单位时间内，同一来源的访问次数超过设定的阈值，就触发拦截或验证码等机制

4. RASP

4.1. RASP（Runtime Application Self-Protection，运行时应用自我保护）的概念，即“应用程序需要具备自我保护的能力，不应该依赖于外部系统”​

4.2. RASP的控制点在应用程序里面（PHP、Java等）​，直接将防护引擎嵌入到应用内部，能够感知到应用的上下文，可以先标记可疑行为，将前后访问关联起来进行判断，判定为高风险行为后加以阻断

4.3. RASP也可以理解为运行在中间件（如PHP、Tomcat、WebLogic等）内部的WAF

5. 业务风险控制

5.1. 验证码

• 5.1.1. 学名为CAPTCHA（Completely Automated Public Turing Test to tell Computers and Humans Apart，全自动区分计算机和人类的图灵测试）​，目的是区分出计算机和人类，让人类能很容易通过但计算机却很难通过

• 5.1.2. 最简单的验证码就是在服务器侧基于一串数字生成添加干扰的图片，用户侧浏览器只收到图片而不知道数字本身，添加干扰主要是为了增加黑客使用OCR（Optical Character Recognition，光学字符识别）进行识别的难度

• 5.1.3. 借助人工智能技术，可以识别出很大比例的验证码图片，就算识别不出来（通过服务器返回来判断识别是否正确）​，还可以跳过不认识的图片，刷新图片后继续识别，从而可以极大提高识别率

• 5.1.4. 由于国内很多地区人工成本还相对较低，黑产还采用了通过互联网招募人工打码的方式，开发了手机打码APP

5.2. 基于大数据的互联网风控系统

• 5.2.1. 验证码主要用于判断请求是来自人类，还是计算机程序，这种方式相对简单有效，但如果黑产已经绕过了验证码机制，就需要其他的手段了，最典型的一种就是基于大数据的风控系统

5.3. 基于人工智能的内容风控系统

5.4. 反爬虫

• 5.4.1. 当我们希望提升网站知名度的时候，总希望尽快被各大搜索引擎抓取并收录，这时候爬虫对我们来说是好事

• 5.4.2. 爬虫与反爬虫的战争不断上演，这种现象在盗版、同行竞争方面比较突出

• 5.4.3. 在WAF中封杀相应的User-Agent，这是最简单的一种做法，但也最容易绕过，因为修改一下User-Agent就绕过了

• 5.4.4. 在WAF中启用CC防护，限定指定时间段内请求的次数，但前提是采集量需要远远超过正常用户的访问量，不然就容易误伤正常用户

• 5.4.5. 使用前端JavaScript执行解码或解密动作，提高爬取成本，因为爬取方需要执行同样的解码或解密动作，但对于直接模拟浏览器类型的爬虫来说，此门槛效果不大

• 5.4.6. 关键数据，不固定其展示格式及HTML标签，可使用＜i＞＜/i＞、＜b＞＜/b＞标签拆分原始数据

• 5.4.7. 可以考虑提高抓取成本

• 5.4.8. 插入不连续的暗语也可以作为典型的盗版爬虫证据

6. 客户端数据安全

6.1. 客户端，是指包括手机APP、电脑客户端软件等参与网络通信的客户端软件

6.2. 客户端敏感数据保护

• 6.2.1. 如果我们需要在客户端存储数据，不要直接使用明文存储任何敏感数据，包括但不限于口令、密钥、Cookie、个人信息及隐私等，因为这些文件可能会被窃取

• 6.2.1.1. 用于身份认证时，不建议上传用户的原始口令

• 6.2.2. 客户端不能展示用于身份认证的相关敏感数据，包括口令、生物特征等

• 6.2.2.1. 生物识别图像无法像口令一样修改，如果处理或存储不当，一旦泄露，可能给具体的个人带来严重的影响

6.3. 安全传输与防劫持

• 6.3.1. 在客户端与服务器通信时，尽量不要采用明文的HTTP协议，如果之前计划采用HTTP协议，则建议启用HTTPS

• 6.3.2. 如果不使用HTTPS协议，也可以考虑使用RPC加密通信

• 6.3.3. 在手机APP客户端访问服务器接口时，却没有验证服务器证书的合法性，有些证书过期了仍在使用中

• 6.3.3.1. 购买证书的钱基本白花了，用免费的自签发证书也完全可以代替

• 6.3.3.2. 手机APP的后台流量实际上是可以被劫持的

• 6.3.4. 数字证书是依赖根证书的信任传递机制的，所以验证一张数字证书的合法性，需要其上级证书参与来进行验证

• 6.3.4.1. 验证根证书是否为受信任的根证书：如果根证书为自签名证书，需使用预置的根证书的公钥来验证

• 6.3.4.2. 验证证书是否在有效期内及证书是否被吊销

• 6.3.4.3. 建议高安全等级的应用在和服务侧建立连接的时候，采取上述全部步骤进行验证，普通的应用可以适当降低标准，但也必然会导致漏洞，要分析存在的漏洞是否会给业务带来损失

6.4. 客户端发布

• 6.4.1. 任何客户端程序的发布都需要执行安全检查，并在安全检查通过后执行数字签名