大型网站技术架构笔记

七、网站的安全架构-固若金汤

1. XSS攻击

XSS攻击即跨站点脚本攻击（Cross Site Script），指黑客通过篡改网页，注入恶意HTML脚本，在用户访问网页时，控制用户浏览器进行恶意操作的一种攻击方式。

常见的XSS攻击类型有两种，一种是反射型，攻击者诱使用户点击一个嵌入恶意脚本的链接，达到攻击的目的（盗取用户Cookie、密码来伪造交易、盗窃用户财产等）。另一种XSS攻击是持久型XSS攻击，黑客提交含有恶意脚本的请求，保存在被攻击的Web站点的数据库中，用户浏览网页时，恶意脚本被包含在正常页面中，达到攻击的目的。

（1）消毒

对某些html字符转义，如“>”转义为“>”等。

（2）HttpOnly

即浏览器禁止页面JavaScript访问带有HttpOnly属性的Cookie。可通过对Cookie添加HttpOnly属性，避免被攻击者利用Cookie获取用户信息。

2. 注入攻击

注入攻击主要有两种形式，SQL注入攻击和OS注入攻击。SQL注入攻击的原理如下图所示。攻击者在HTTP请求中注入恶意的SQL命令，服务器用请求构造数据库SQL命令时，恶意SQL被一起构造，并在数据库中运行。

攻击者获取数据库表结构信息的手段有如下几种：

（1）开源，如果网站采用开源软件搭建，那么网站数据库就是公开的；

（2）错误回显，如果网站开启了错误回显，即服务器内部500错误会显示到浏览器上，攻击者可以通过故意构造非法数据，使服务器异常信息输出到浏览器端，为攻击猜测数据库表结构提供了便利；

（3）盲注，攻击者根据页面变化情况判断SQL语句的执行情况来猜测数据库表结构；

除了SQL注入，攻击者还根据具体应用，注入OS命令、编程语言代码等达到攻击目的。

防御措施：

（1）消毒

和防XSS攻击一样，过滤请求数据中可能注入的SQL，如"drop table"等。另外还可以利用参数绑定来防止SQL注入。

（2）参数绑定

使用参数绑定是最好的防SQL注入方法。目前请多数据层访问框架，如MyBatis、Hibernate都实现了SQL预编译和参数绑定，攻击者的恶意SQL会被当做SQL的参数而不是SQL命令插入。

3. CSRF攻击

CSRF即Cross Site Request Forgery（跨站点请求伪造），攻击者通过跨站点请求，以合法用户的身份进行非法操作。CSRF的主要手段是利用跨站请求，在用户不知情的情况下，以用户的身份伪造请求。其核心是利用了浏览器Cookie或服务器Session策略，盗取用户身份。

CSRF的防御手段主要是识别请求者身份：

（1）表单Toke

CSRF是一个伪造用户请求的操作，所以需要构造用户请求的所有参数才可以，表单Token通过在请求参数中增加随机数的办法来组织攻击者获取所有请求参数。

（2）验证码

更加简单高效，即请求提交时，需要用户输入验证码，以避免在用户不知情的情况下被攻击者伪造请求。

（3）Referer Check

HTTP请求头的Referer域中记录着请求来源，可通过检查请求来源，验证其是否合法，还可以利用这个功能来实现突破防盗链。

4. 其他攻击和漏洞

（1）Error Code(错误回显）：获取异常信息进行攻击。

通过配置Web服务器参数跳转500页面到专门的错误页面。

（2）HTML注释，HTML注释会显示在客户端浏览器中。

（3）文件上传，上传病毒文件。

设置上传白名单，只允许上传可靠的文件类型。还可以修改文件名、使用专门的存储等。（4）路径遍历，在URL中使用相对路径，遍历系统未开放的目录和文件。

防御方法是将JS、CSS等资源部署在独立服务器、使用独立域名，其他文件不使用静态URL访问。

5. WEB应用防火墙

ModSecurity是一个开源的Web应用防火墙（拦截请求、过滤恶意参数，自动消毒、添加Token），探测攻击并保护Web应用程序，既可以嵌入到Web应用服务器中，也可以作为一个独立的应用程序启动。ModSecurity最早只是Apache的一个模块，现在已经有Java、NET多个版本，并支持Nginx。

ModSecurity采用处理逻辑与攻击规则集合分离的架构模式。处理逻辑（执行引擎）负载请求和相应的拦截过滤，规则加载执行等功能。而攻击规则集合则负责描述对具体攻击的规则定义、模式识别、防御策略等功能。处理逻辑比较稳定，规则集合需要不断针对漏洞进行升级，这是一种可扩展的架构设计。

6. 信息加密技术

为了保护网站的敏感数据，应用需要对某些数据进行加密处理。

（1）单向散列加密（MD5、SHA）

给散列算法加点盐（salt）增加破解难度。

（2）对称加密（DES）

（3）非对称加密（RSA）

非对称加密使用的加密和解密不是同一密钥，其中一个对外界公开，被成为公钥，另一个只有所有者知道，被称作私钥。用公钥加密的信息必须用私钥才能解开，反之，用私钥加密的信息只有用公钥才能解开。

数字签名的过程则相反，签名者用自己的私钥对信息进行加密，然后发送给对方，接收者用签名者的公钥信息进行解密，获得原始明文信息，由于秘钥只有签名者拥有，因此该信息是不可抵赖的，具有签名的性质。

HTTPS传输中浏览器使用的数字证书实质上是经过权威机构认证的非对称加密的公钥。（4）密钥安全管理

把密钥和算法放在一个独立的服务器上，甚至做成一个专用的硬件设施，对外提供加密和解密服务。但这种方式成本较高，而且有可能成为应用的瓶颈，每次加密、解密都需要进行一次远程服务调用，系统性能开销也较大。

另一种方案是将加解密算法放在应用系统中，密钥则放在独立的服务器中，为了提高密钥的安全性，实际存储时，密钥被切分成数片，加密后保存在不同存储介质中。

7. 信息过滤与反垃圾

（1）文本匹配

主要解决敏感词过滤的问题，通过Trie树、多级Hash表进行文本匹配。

（2）分类算法

主要解决识别垃圾信息，分类算法先将批量已分类的邮件样本（5000正常，2000垃圾）输入分类算法进行训练，得到一个垃圾邮件分类模型，然后利用分类算法结合分类模型对待处理出险的进行识别。如贝叶斯分类算法，如“茶叶”出现在垃圾邮件中的概率为20%，出现在正常邮件的概率为1%，就得到了这个分类模型，会存在误判和漏判。

（3）黑名单

8. 电子商务风险控制

账户风险：账户被盗、恶意注册等；

买家风险：恶意下单占用库存，良品拒收，欺诈退款等；

卖家风险：货不对板、虚假发货、炒作信用、出售违禁品、侵权产品；

交易风险：盗刷卡、洗钱等

（1）风控

规则引擎：当交易的某些指标满足一定条件时，就会被认为具有高风险的欺诈可能性。比如用户来自欺诈高发地区；交易金额超过某个数量，和上次登陆的地址距离差距很大，用户登陆地与收货地不符，用户第一次交易等。

（2）统计模型

根据历史交易中的欺诈交易信息训练分类算法，然后将经过采集加工后的交易信息输入分类算法，即可得到交易风险分值。

八、网购秒杀系统架构设计案例分析

1. 秒杀活动的技术挑战

（1）对现有网站业务造成冲击

秒杀活动只是网站营销的一个附加活动，特点是：时间短、并发访问量大，如果和网站原有应用部署在一起，必然会对现有业务造成冲击。稍有不慎可能导致整个网站瘫痪。（2）高并发下的应用、数据库负载

用户在秒杀开始前，通过不停刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器和数据库服务器造成负载压力。

（3）突然增加的网络及服务器带宽

假设商品页面大小200K（主要是商品图片大小），10000个请求的带宽就是2G。

（4）直接下单

秒杀的游戏规则是到了秒杀才能开始对商品下单购买，在此时间点之前，只能浏览商品信息，不能下单。而下单页面也是一个普通的URL，如果得到这个URL，不用等到秒杀开始就可以下单了。

2. 秒杀系统的应对策略

（1）秒杀系统独立部署

将秒杀系统独立部署，甚至使用独立域名，使其与网站完全隔离。即使秒杀系统崩溃也不会对网站造成任何影响。

（2）秒杀商品页面静态化

重新设计秒杀商品页面，不使用网站原来的商品详细页面，页面内容静态化（将商品描述、商品参数、成效记录和用户评价全部写入一个静态页面），用户请求不需要经过应用服务器的业务逻辑处理，也不需要访问数据库。所以秒杀商品服务不需要部署动态的Web服务器和数据库服务器。

（3）租借秒杀活动网络带宽

因为秒杀新增的网络带宽，必须和运营商重新购买或者租借。为了减轻网站服务器的压力，需要将秒杀商品页面缓存在CDN，同样需要和CDN服务商临时租借新增的出口带宽。（4）动态生成随机下单页面URL

为了避免用户直接访问下单页面URL，需要将改URL动态化，即使秒杀系统的开发者也无法在秒杀开始前访问下单页面的URL。办法是在下单页面URL加入由服务器端生成的随机数作为参数，在秒杀开始的时候才能得到。

3. 秒杀系统架构设计

（1）如何控制秒杀商品页面购买按钮的点亮

购买按钮只有在活动开始的时候才能点亮，在此之前是灰色的。如果是动态页面，可以很容易解决这个问题，但为了减轻服务器负载压力，该页面设计为静态页面，缓存在CDN、反向代理服务器

上，甚至用户浏览器上。秒杀开始时，用户刷新页面，请求根本不会到达应用服务器。

解决方案是使用JavaScript脚本控制，在秒杀商品静态页面中加入一个JavaScript

文件引用，该JavaScript文件中加入秒杀是否开始的标志和下单页面URL的随机数参数，当秒杀开始的时候生成一个新的JavaScript文件并被用户浏览器加载，控制秒杀商品页面的展示。这个JavaScript文件使用随机版本号，并且不被浏览器、CDN和反向代理服务器缓存。这个JS文件非常小，即使每次器刷新都访问JS文件服务器也不会对服务器集群和网络带宽造成太大压力。

（2）如何只允许第一个提交的订单被发送到订单子系统

由于最终能够成功秒杀到商品的用户只有一个，因此需要在用户提交订单时，检查是否已经有订单提交。

为了减轻下单页面服务器的负载压力，可以控制进入下单页面的入口，只有少数用户能进入下单页面，其他用户直接返回秒杀结束页面。

活动开始：

请求发送至下单服务器；

下单服务器检查本机已处理的下单请求数目；

如果超过10条，直接返回已结束页面给用户。如果未超过10条，则用户可进入填写订单及确认页面；

检查全局已提交订单数目，已超过秒杀商品总数，返回已结束页面给用户。未超过秒杀商品总数，提交到子订单系统。

九、大型网站典型故障案例分析

大型网站的架构师最有价值的地方不在于他们掌握了多少技术，而在于他们经历过多少故障。

1. 写日志也会引发故障

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

原因分析：查日志内容发现开发人员将log输出的level全局配置为Debug，这样一次简单的web请求就会产生大量的log文件输出，在高并发的用户请求下，很快就消耗完磁盘空间。经验：线上的日志输出级别至少为Warn。

2. 高并发访问数据库引发故障

故障现象：某应用发布后，数据库Load居高不下，远超正常水平，持续报警。

原因分析：检查数据库，发现报警是因为某条SQL引起，这条SQL是一条简单的有索引的数据查询，不应该引发报警。继续检查，发现这条SQL执行频率非常高，远超正常水平。追查这条SQL，发现被网站首页应用调用，首页是被访问最频繁的网页，这条SQL被首页调用，也就被频繁执行了。

经验：首页不应该访问数据库，首页需要的数据可以从缓存服务器或者搜索引擎服务器获取；首页最好是静态的。

3. 高并发情况下锁引发的故障

故障现象：某应用服务器不定时因为响应超时而报警，但是很快又超时解除，恢复正常，如此反复，让运维人员非常苦恼。

原因分析：程序中某个单例对象(Singleton object)中多处使用了synchronized(this)，由于this对象只有一个，所有的并发请求都要排队获得这唯一的一把锁。一般情况下，都是一些简单操作，获得锁，迅速完成操作，释放锁，不会引起线程排队。但是某个需要远程调用的操作也被加了synchronized(this)，这个操作只是偶然被执行，但是每次执行都需要较长的时间才能完成，这段时间锁被占用，所有的用户线程都要等待，响应超时，这个操作执行完后释放锁，其他线程迅速执行，超时解除。

经验：谨慎使用锁。

4. 缓存引发的故障

故障现象：没有新应用发布，但是数据库服务器突然Load飙升，并很快失去响应。DBA将数据库访问切换到备机，Load也很快飙升，并失去响应。最终引发网站全部瘫痪。

原因分析：缓存服务器在网站服务器集群中的地位一直比较低，服务器配置和管理级别都比其他服务器要低一些。人们都认为缓存是改善性能的手段，丢失一些缓存也没有什么问题，有时候关闭一两台缓存服务器也确实对应用没有明显影响，所以长期疏于管理。结果这次一个缺乏经验的工程师关闭了缓存服务器集群中全部的十几台Mencached服务器，导致了网站全部瘫痪的重大事故。

经验：当缓存已经不仅仅是改善性能，而是成为网站架构不可或缺的一部分时，对缓存的管理就需要提高到和其他服务器一样的级别。

5. 应用启动不同步引发的故障

故障现象：某应用发布后，服务器立即崩溃。

原因分析：应用程序Web环境使用Apache + JBoss的模式，用户请求通过Apache转发JBoss。在发布时，Apache和JBoss同时启动，由于JBoss启动时需要加载很多应用并初始化，花费时间较长，结果JBoss还没完全启动，Apache就已经启动完毕开始接收用户请求，大量请求阻塞在JBoss进程中，最终导致JBoss崩溃。除了这种Apache和JBoss启动不同步的情况，网站还有很多类似的场景，都需要后台服务准备好，前台应用才能启动，否则就会导致故障。这种情况被戏称：“姑娘们还没穿好衣服，老鸨就开门迎客了。”

经验：就本例来说，在应用程序中加入一个特定的动态页面(比如只返回OK)，启动脚本先启动JBoss，然后在脚本中不断用curl命令访问这个特定页面，直到收到OK，才启动Apache。

6. 大文件读写独占磁盘引发故障

故障现象：某应用主要功能是管理用户图片，接到部分用户投诉，表示上传图片非常慢，原来只需要一两秒，现在需要几十秒，有时等半天结果浏览器显示服务器超时。

原因分析：图片需要使用存储，最有可能出错的地方是储存服务器。检查存储服务器，发现大部分文件只有几百KB，而有几个文件非常大，有数百兆，读写这些大文件一次需要几十秒，这段时间，磁盘基本被这个文件操作独占，导致其他用户的文件操作缓慢。

经验：存储的使用需要根据不同文件类型和用户进行管理，图片都是小文件，应该使用专用的存储服务器，不能和大文件共用存储。批处理用的大文件可以使用其他类型的分布式文件系统。

7. 滥用生产环境引发的故障

故障现象：监控发现某个时间段，某些应用突然变慢，内部网络访问延迟非常厉害。

原因分析：检查发现，该时段内网卡流量也下降，但是没有找到原因。过了一阵子才知道，原来有工程师在线上生产环境进行性能压力测试，占用了大部分交换机带宽。

经验：访问线上生产环境要规范。网站数据库有专门DBA维护，如果发现数据库存在错误记录，需要进行数据订正，必须走数据订正流程，申请DBA协助。于是就有工程师为避免麻烦，直接写一段数据库更新操作代码，悄悄放到生产环境上执行，如更新大量数据，会导致系统处于假死状态，如果更新错了数据，后果更严重。

8. 不规范的流程引发的故障

故障现象：某应用发布后，数据库Load迅速飙升，超过报警值，回滚发布后报警消除。

原因分析：发现该应用发布后出现大量数据库读操作，而这些数据本来应该从分布式缓存读取。检查缓存，发现数据已经被缓存了。检查代码，发现访问缓存的那段代码被注释掉了。原来工程师在开发的时候，为了方便测试，特意注释掉读取缓存的代码，结果开发完成后忘记把注释去掉，直接提交到代码库发布到线上环境。

经验：代码提交前使用diff命令进行代码比较，确认没有提交不该提交的代码。

9. 不好的编程习惯引发的故障

故障现象：某应用更新某功能后，有少量用户投诉无法正常访问该功能，一点击就显示出错信息。

原因分析：分析这些用户，都是第一次使用该功能，检查代码，发现程序根据历史使用记录构造一个对象，如果该对象为null，就会导致NullPointException。

经验：编写健壮的代码。