第十一周 作业 2

安全架构：Web 攻击与防护

信息加密和网络攻击相关内容

XSS 攻击

跨站点脚本攻击，是最常用的攻击。

• 推送可执行的 js 脚本给用户，用户主动触发 js 脚本执行。

• 将脚本输入到应用服务器中，浏览者访问的时候执行。

防御手段

• 消毒：攻击者一般都是通过在请求中嵌入恶意脚本达到攻击目的，这些脚本是一般用户输入中不使用的，如果进行过滤或消毒处理，即对某些 HTML 危险字符转义，如 “>” 转义为 “&gt” 等，就可以防止大部分攻击。

为了避免对不必要的内容错误转义，如 3>5 中的 >，需要进行文本匹配后再转义。

SQL 注入攻击

客户端提交了包含了 其他 sql 命令的内容，如

http://www.a.com?username=frank';drop table users-

前提是获取数据库表结构

• 开源：网站是开源网站，如 Discuz! 论坛，用户可以直接知道数据库表结构和逻辑；

• 错误回显：故意构造非法参数，服务端将异常信息输出到浏览器端，为攻击猜测数据库表结构提供了便利；

• 盲注：网站关闭了错误回显，攻击者根据页面变化情况判断 SQL 语句的执行情况，据此猜测数据库表结构，此种攻击难度较大。

防御手段

• 消毒：请求参数消毒。通过正则匹配，过滤请求数据中可能注入的 SQL 文。

如 drop table、"\b(?:update\b.?)\b" 等。

• SQL 预编译参数绑定：攻击者的恶意 SQL 会被当做 SQL 的参数，而不是 SQL 命令执行。

CSRF 跨站脚本跨站点请求伪造

与 XSS 攻击很像。

用户登录受信任服务器，又访问了攻击者服务器，攻击者服务器响应中包含了受信任服务的请求。导致在用户不知情的情况下，向受信任服务器提交了攻击的请求。

安全银行和金融方面。

防御手段

• 表单 Token：CSRF 需要构造用户请求的参数才可以。表单 Token 就是阻止攻击者获得所有请求参数的可能，在页面表单中增加一个随机数，每次请求的 token 都不同，请求提交后检查 Token 的值是否正确以确认提交者是否合法。APP 上可以使用用户的设备指纹。

• 验证码：即提交请求时，需要用户输入验证码，以避免在用户不知情的情况下被攻击者伪造请求。但是输入验证码是一个糟糕的用户体验，只要在必要的情况下才用。

• Referer check: HTTP 请求头中的 referer 域中记录着请求来源，可通过检查请求来源，验证其是否合法。该方法有局限，并不一定总能得到。

其他需要关注的点

• Error Code，设置一个专用的出错页面

• HTML 注释，最终发布代码前需要进行代码 review 或自动扫描，避免 HTML 注释漏洞

• 文件上传，避免上传可执行程序。设置上传文件白名单，只允许上传可靠的文件类型。还可以修改文件名、使用专门的存储手段，保护服务器免受上传文件攻击。

• 路径遍历，请求的 URL 中使用相对路径，遍历系统未开放的目录和文件。防御方法主要是将 JavaScript、CSS 等资源文件独立服务器、独立域名部署，其他文件不使用静态 URL 访问，动态参数不包含文件路径信息。

• Web 应用防火墙。统一做防御，通用、成熟、开源。ModSecurity

• 网站安全漏洞扫描。网站安全漏洞扫描工具根据内置规则，模拟黑客攻击行为，用以发现网站安全漏洞。

安全架构：加密与解密

防止黑客攻击的第一道门槛，防止网络攻击；第二道是信息的加密存储。

• 单项散列加密。不需要知道明文，通过加盐加强加密强度。

• 对称加密。加密与解密的密钥相同。

• 非对称加密。加密与解密的密钥不同。

专门密钥安全管理与加解密服务系统架构，降低不同业务系统处理的复杂度和提高公司整体的安全性

应用服务器、密钥服务器、密钥存储设备（密钥分片存储）

安全架构：反垃圾与风控

反垃圾邮件：贝叶斯分类算法

布隆过滤器黑明单：较小的空间，存储大量的黑名单信息。检查是否符合某个条件。只会错判、不会漏判。

规则引擎

当交易的某些指标满足一定条件的时候，就会被认为具有高风险的欺诈可能性。

机器学习

高可用：高可用度量

可用性指标：通常用多少个 9 来衡量网站的可用性。通常以年为时间单位

网站年度可用性指标=（1 - 网站不可用时间/年度总时间）* 100%

99.99% 可用性，一年有 53 分钟不可用。

故障分管理

故障进行分类，不同级别权重不同，对应不同故障分。

引起故障的原因：

• 硬件故障

• 软件 Bug

• 系统发布

• 并发压力

• 网络攻击

• 外部灾害

高可用：提升系统可用性的架构

高可用的角度看系统，相同的技术方案。

解耦

• 高内聚、低耦合的组件设计原则。不要、减少相互影响

• 面向对象基本设计原则

• 面向对象设计模式

• 领域驱动设计建模

隔离

• 业务与子系统隔离。电子商务系统：买家子系统、卖家子系统，完全隔离开。

• 微服务与中台架构。

• 生产者消费者隔离。

• 虚拟机与容器隔离。将故障局限在虚拟机或者容器内部。

异步

• 多线程编程

• 反应式编程

• 异步通信网络编程

• 事件驱动异步架构

备份

• 集群设计（主要是提升性能，也可以提升可用性）。

• 数据库复制（主从复制）。

1. CAP 原理

2. 失效转移。数据库主主失效转移；负载均衡失效转移

幂等

服务重复调用有时无法避免，必须保证服务重复调用和调用一次产生的结构相同，即服务具有幂等性。

事务补偿

传统事务：ACID，原子性、一致性、隔离性、持久性

分布式事务：基本可用、软状态、最终一致性

事务补偿：通过执行业务逻辑逆操作，使事务回滚到事务前状态

重试

远程服务可能会由于线程阻塞、垃圾回收或者网络抖动，而无法及时返还响应，调用者可以通过重试的方式修复单次调用故障

• 上游调用者时间要大于下游调用者超时时间之和

熔断

当某个服务出现故障，响应延迟或者失败率增加时，继续调用这个服务会导致调用者请求阻塞，资源消耗增加，进而出现服务级联失效，这种情况下使用断路器阻断对故障服务请求的调用。

断路器的状态：关闭、打开、半开

限流

访问量超过承受能力，限制部分流程，保护系统正常运行

• 计数器（固定窗口）算法：使用计数器在周期内累加访问次数，当达到设定的限流值时，触发限流策略。下个周期开始时，进行清零，重新计数。存在临界区问题

• 计数器（滑动窗口）算法：将时间周期分为 N 个小周期，分别记录每个小周期内访问次数，并且根据时间滑动删除过期的小周期。

• 令牌桶算法：以固定的速度向令牌桶中增加令牌，直到令牌桶满，请求达到时向令牌桶请求令牌，如获取到令牌则通过请求，否则触发限流策略。

• 漏桶算法：访问请求达到时直接放入漏桶，如果当前容量已达到限流值，则进行丢弃。漏桶以固定的速率进行释放访问请求，直到漏桶为空。

• 自适应限流：没有提前的人工评估，便没有提前的评估过时与人的评估疏漏

1. 实时自动评估

2. 业务流量的不确定性与技术方案的自适应性天生一对

降级

关闭非核心功能，保护核心系统功能。

异地多活

将数据中心分布在不同地点的机房里，这些机房都可以对外提供服务，用户可以连接任何一个机房进行访问。

难点是数据的一致性。

高可用： 架构运维方案

在系统的发布、运维环节，可能会导致系统故障的问题。

发布

新老两部分系统在同时运行。

自动化测试

保证系统整个功能的完整

Selenium

自动化部署

持续集成

持续交付

持续部署

预发布验证

测试环境无法测试出来，线上特定环境的问题。

代码的版本控制

高效协作、不混乱

• 分支开发、主干发布

自动化发布

发布过程是自动的，

网站运行监控

监控来及时处理系统问题

• 用户行为日志收集

• 服务器性能监控（报警、自动控制）

高可用的价值观

• 保持简单，使问题易于发现，快速解决

• 目标明确，解决特定环境下的具体问题

• 价值回归，成本收益要合理

高可用故障案例分析

不仅是架构，很多细节也会导致了系统不可用。

1. log 文件增大，日志级别太小。

2. 网站首页 SQL 查询。首页不能查数据库（最好是静态的），使用缓存、搜索引擎代替。

3. synchronized 锁，锁中有长时间的远程调用

4. 缓存服务器需要监控。缓存也是网站架构不可或缺的一部分。

5. 后台服务启动完成后，才能启动前台的服务。

6. 大文件与小文件不能放在同一个服务处理。

7. 线上性能压测、带宽不足。

8. 访问缓存方法被注释。加强 code review。

9. NullPointException.