安全架构：web 攻击与防护

XSS 攻击

XSS 攻击防御手段

消毒：XSS 一般是在请求中嵌入恶意脚本达到攻击目的，这些脚本是一般用户输入中不使用的，如果进行过滤和消毒处理，即对某个 HTML 危险字符转义，如“>”转义为”&gt”、”<”转义为”&lt”等，就可以防止大部分攻击。为避免对不必要内容错误转义，如” 3<5”中的”<”，需要进行文本匹配后再转义，如：”<img src=”这样的上下文中才转义。实际上，消毒是所有网站最必备的 XSS 攻击防御手段。

SQL 注入攻击

获取数据库表结构信息的手段

l  开源：使用开源软件搭建，网站数据结构公开，攻击者可以直接获得。

l  错误回显：如果开启错误回显，攻击者恶意构造非法参数，服务器异常信息会输出到浏览器端，为攻击者猜测数据库表结构提供便利。

l  盲注：攻击者根据页面变化情况判断 SQL 语句执行情况，据此猜测数据库结构情况，此攻击难度较大。

注入攻击防御手段

l  消毒：通过正则匹配过滤掉数据中可能注入的 SQL。

l  SQL 预编译参数绑定：绑定参数是最好防 SQL 注入方式。

CSRF 攻击

CSRF 攻击防御手段

l  表单 token：CSRF 是一个伪造用户请求的操作，需要构造用户请求所有参数。表单 token 就是阻止攻击者获得所有请求参数的可能，在调单中增加一个随机数 token，每次 token 都不同，请求提交后检查 token 的值是否正确以确定请求提交者是否合法。

l  验证码：简单有效，请求提交时，需要用户输入验证码，以避免在用户不知情的情况下被攻击者伪造请求。但输入验证码是一个糟糕的用户体验，所以必要的时候才使用，如支付交易等关键页面。

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

其他需关注的攻击和漏洞

Error Code：也称错误回显，许多 web 服务器默认是打开异常信息输出的，即服务器端未处理的异常堆栈信息会直接输出到客户端浏览器，这种虽然对调试和错误报告有好处，但同时给黑客造成可乘之机，通过故意制造非法输入，使系统运行出错，获得异常信息，从而寻找系统漏洞进行攻击。

防御方式也很简单，通过配置 web 服务器参数，跳转 500 页面到专门错误页。

HTML 注释：程序开发人员为了调试方便会在 PHP、JSP 等页面程序中使用 HTML 注释语法进行程序注释，这些 HTML 注释会显示在客户端浏览器，给黑客造成攻击便利。程序最终发布前需要进行代码 review 或自动扫描，避免 HTML 注释漏洞。

文件上传：如果上传文件是可执行的程序，并通过该程序获得服务端命令执行能力，那么攻击者几乎可以在服务器上为所欲为，并以此为跳板攻击集群其他机器。最有效的防御手段设置文件上传白名单，只允许上传可靠文件类型。此外还可以修改文件名、使用专门的存储等手段，保护服务器免受上传文件攻击。

路径遍历：攻击者在请求的 url 中使用相对路径，遍历系统未开放的目录和文件。防御方法是将 js、css 等资源文件独立服务器、独立域名，其他文件不使用静态 url 访问，动态参数不包括文件路径信息。

开源 web 应用防火墙 ModSecurity

Modsecurity 是一开源 web 应用防火墙，探测攻击并保护 web 应用程序，既可以嵌入到 web 应用服务器中，也可以作为独立的应用程序启动。

网站安全漏洞扫描

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

安全架构：加密与解密

信息加密技术及密钥安全管理

信息加密技术分为三类：

l  单向散列加密：加密后的密文，不可还原明文。

l  对称加密：加密、解密使用相同密钥，通过解密算法可以算出明文。

l  非对称加密：加密密钥和解密密钥不同。例如：1. HTTPS 技术，使用公钥加密，私钥解密；2. 区块链技术使用私钥加密，公钥解密，正确解出密文，证明交易有效。

安全架构：反垃圾与风控

反垃圾邮件

对已分类的邮件，通过分类算法训练出一个分类模型，通过分类算法识别是否垃圾邮件。

贝叶斯分类算法

贝叶斯算法解决概率论中一个典型问题：1 号箱放红色球和白色球各 20 个，2 号箱放有白色球 10 个，红色球 30 个，现随机挑选个箱子，取出一个球的颜色是红色的，请问这个球来自 1 号箱的概率是多少？

贝叶斯公式:

布隆过滤器黑名单

利用比特位，可以使用 2G 存储空间，存储 2G 个数据。有可能会错判，但不会漏判。

风控系统

电子商务系统，大致分为以下几种：

l  账户风险

l  买家风险

l  卖家风险

l  交易风险

规则引擎

当交易某些指标达到一定条件，会被认为具有高风险欺诈行为，如：

l  用户来自欺诈高发地区；

l  交易金额超过阈值；

l  和上次交易地址距离差距很大；

l  登录地和收货地不符；

l  用户第一次交易；

机器学习

规则引擎虽然技术简单，但随着规则逐渐增加，出现规则冲突，难以维护等情况。规则越多，性能越差。大型互联网，倾向使用机器学习模型进行风控。

高可用：可用性度量

可用性指标

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

网站不可用时间（故障时间）=故障修复时间点-故障发现（报告）时间点

对可用性的定性描述，两个 9 是基本可用；3 个 9 是较高可用；4 个 9 是具有自动恢复能力的高可用；5 个 9 是极高可用，年度停机小于 5 分钟。

故障处理流程及考核

引起故障的原因

l  硬件故障

l  软件 bug

l  系统发布

l  并发压力

l  网络攻击

l  外部灾害

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

解耦

l  高内聚、低耦合的组件设计原则

l  面向对象基本设计原则

l  面向对象设计模式

l  领域驱动设计建模

隔离

l  业务与子系统隔离

l  微服务与中台架构

l  生产者与消费者隔离

l  虚拟机与容器隔离

异步

l  多线程编程

l  响应式编程

l  异步通信网络编程

l  事件驱动异步架构

备份

l  集群设计

l  数据库复制

l  CAP 原理

Failover（失效转移）

l  数据库主主失效转移

l  负载均衡失效转移

幂等

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

事务补偿

l  传统事务 ACID

l  分布式事务 BASE

基本可用（Basic Availabilty）,软状态（soft-state）、最终一致性（Eventual-consistency）

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

重试

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

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

熔断

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

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

限流

在高并发场景下，如果系统访问量超过系统承载能力，可通过限流进行保护。如果超过系统最大处理能力，就会丢弃一部分用户请求，保证大部分用户能够访问系统。

限流几种算法：

l  计数器算法（固定窗口、滑动窗口）

l  令牌桶算法

l  漏桶算法

自适应限流

实时自动评估 QPS。

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

降级

非核心功能关闭，减少系统压力。

异地多活

如果数据中心城市遭遇地震，机房遭遇火灾或停电等不可控的因素，一般采用异地多活多机房架构策略，异地多活难点是数据一致。

高可用：架构运维方案

自动化测试

目前大部分网站采用 web 自动化测试技术，使用自动测试工具或脚本完成测试。比较流行的 selenium 运行在浏览器中，模拟用户操作进行测试，可以同时完成 web 功能测试和浏览器兼容测试。

自动化部署

开发人员开发完功能后，提交代码到 git 仓库，自动测试部署。

持续部署三步走

l  持续集成：允许工程师随时向公共分支提交代码，并立即进行自定化测试。

l  持续交付：除了跑单元测试及软件包，持续交付机制会将软件部署到各种测试环境中。

l  持续部署：代码在没有人工干预的情况下被测试、构建、部署并推送到生产环境。

预发布验证

预发布机器是一种特殊用途服务器，和生产服务器的区别是没有配置在负载均衡服务器上，外部用户无法访问。

代码版本控制

l  主干开发、分支发布：

代码修改都在主干上进行，需要发布时，从主干上拉一个分支发布，该分支即成为一个发布版本，如果该版本发现 bug，继续在该分支上修改发布，并将修改合并回主干，直到下次主干发布。

l  分支开发、主干发布：

任何修改都不得在主干上直接进行，需要开发一个新功能或修复一个 bug 时，从主干拉一个分支进行开发，开发完成测试通过后，合并会主干，然后进行主干发布，主干上代码永远是最新发布的版本。

自动化发布

灰度发布

将服务器集群分成若干部分，每天发布一小部分，期间如果发现问题，就只需要回滚已发布的一部分服务器即可。

灰度发布不只保障系统高可用，还保障系统业务的持续发展。

网站运行监控

尽早发现问题，为问题发现提供数据查询。

用户行为日志收集

日志收集手段有 2 种：

l  服务端日志收集

l  客户端浏览器日志收集

报警

       监控管理系统可以配置报警阈值和值守人员，报警方式包括：邮件、手机短信、手机语音，及时在夜间也能及时通知，迅速响应。

自动控制

l  自动失效转移

l  自动扩容

l  自动限流

监控系统监控架构

高可用故障案例分析

故障 1

故障现象：

应用服务器集群发布后不久就出现多台服务器相继报警，硬盘可用空间低于警戒值，并且很快有服务器宕机。登录到线上服务器，发现 log 文件夹里的文件迅速增加，不断消耗磁盘空间。

原因分析：

应用开发人员将日志 log 输出的 level 全局配置为 debug。这样一次简单的 web 请求就会产生大量的 log 文件输出，在高并发用户请求下，很快消耗完不多的磁盘空间。

故障 2

故障现象：

某应用发布后，数据库 load 居高不下，远远超过正常水平，持续报警。

原因分析：

检查发现，某条 SQL 引起的，但是这条 SQL 是一条简单的有索引的数据查询，不应该引起报警。继续检查，发现这条 SQL 执行频率很高，被首页调用，所以频繁执行。

经验教训：

l  首页不应该访问数据库，需要从缓存服务或搜索引擎服务器获取。

l  首页最好是静态的。

故障 3

故障现象

某应用服务器不定时的因为响应超时而报警，但很快又超时解除，恢复正常，如此反复。

原因分析：

某个单例对象多个方法使用了 synchronize 关键字，由于 this 对象只有一个，即使执行不同方法，所有的并发请求也都要排队获取这唯一一把锁。所有用户线程都要等待，每次执行都需要较长时间排队执行。

经验教训：

l  使用锁要谨慎，特别注意有锁的方法长时间 IO 操作时。

l  针对不同场景，使用不同锁对象，而不是所有方法上都简单加上 synchronize。

故障 4

故障现象

无新功能发布，用户并发请求也没突然增加，但是数据库服务器突然 load 飙升，并很快失去响应，DBA 将数据库切换的备机，Load 也很快飙升，失去响应，最终引发网站瘫痪。

原因分析：

缓存服务器在网站集群中地位一直比较低，服务器配置和管理配置级别都比其他服务器要低一些。由于人们认为缓存是改善性能手段，丢失一些也没什么问题，结果由于误操作关闭了缓存服务器的全部服务，导致网站瘫痪。

经验教训：

l  缓存不仅仅改善性能，而是网站不可或缺部分，对缓存重视级别要提高。

故障 5

故障现象

服务发布后，立刻崩溃。

原因分析：

Web 应用程序使用 Apache+JBoss 模式， 用户请求通过 Apache 转发给 Jboss，再发布时，Apache 和 Jboss 同时启动，由于 Jboss 启动时需要加载很多应用并初始化，花费时间较长，结果 Jboss 还未启动，Apache 就开始接收请求，大量阻塞在 Jboss 进程中，最终导致 Jboss 崩溃。

经验教训：

l  应用启动时，一定要先查看依赖服务是否可正常提供服务。

故障 6

故障现象

某应用主要功能是管理用户图片，接部分用户投诉，上传图片非常慢，有时等待半天结果浏览器显示服务器超时。

原因分析：

图片需要使用存储，检查服务器发现，大部分文件只有几百 k，而有几个文件非常大，有数百兆，读写一次大文件需要 10 多秒，磁盘基本都被这个文件操作独占，导致其他用户操作缓慢。

经验教训：

l  图片应该都是小文件，应该使用专用服务器进行存储，不能和大文件存储共享。

故障 7

故障现象

监控发现，某个应用突然变慢，内网网络访问。

原因分析：

生产环境进行性能压力测试，占据了大部分交换机带宽。

经验教训：

l  访问线上生产环境要规范。

l  数据库中数据更正，要走正常数据订正流程。

故障 8

故障现象

应用发布后，数据库 load 负载飙升，超过警戒值，回滚发布后报警消除。

原因分析：

发布应用后，数据库大量读操作，检查发现，由于测试需要，特意注释读缓存的代码，最终导致注释代码上线前未修改，直接提交到代码库。

经验教训：

l  代码提交时要用 diff 命令比较，确保没有提交不该提交的代码。

l  加强 code review，代码在正式提交前至少被一个工程师 code review，并承担因代码引起的故障责任。

故障 9

故障现象

新功能发布后，少量用户投诉功能不可用，一点就出错。

原因分析：

分析发现，这些用户都是第一次使用，程序根据历史记录构造一个对象，如果该对象为 null，就会导致 nullPointException。

经验教训：

l  程序在处理一个输入的对象时，如果不明确该对象是否为空，必须空指针判断。

l  程序在调用其他方法时，输入对象尽量保证不是 null，必要时构造空对象。