1、七、网站的安全架构-固若金汤1. XSS 攻击XSS 攻击即跨站点脚本攻击（Cross Site Script），指黑客通过篡改网页，注入恶意HTML 脚本，在用户访问网页时，控制用户浏览器进行恶意操作的一种攻击方式。常见的 XSS 攻击类型有两种，一种是反射型，攻击者诱使用户点击一个嵌入恶意脚本的链接，达到攻击的目的（盗取用户 Cookie、密码来伪造交易、盗窃用户财产等）。另一种 XSS 攻击是持久型 XSS 攻击，黑客提交含有恶意脚本的请求，保存在被攻击的 Web站点的数据库中，用户浏览网页时，恶意脚本被包含在正常页面中，达到攻击的目的。（1）消毒对某些 html 字符转义，如“” 转义
2、为“>”等。（2）HttpOnly即浏览器禁止页面 JavaScript 访问带有 HttpOnly 属性的 Cookie。可通过对 Cookie添加 HttpOnly 属性，避免被攻击者利用 Cookie 获取用户信息。2. 注入攻击注入攻击主要有两种形式，SQL 注入攻击和 OS 注入攻击。SQL 注入攻击的原理如下图所示。攻击者在 HTTP 请求中注入恶意的 SQL 命令，服务器用请求构造数据库 SQL 命令时，恶意 SQL 被一起构造，并在数据库中运行。攻击者获取数据库表结构信息的手段有如下几种：（1）开源，如果网站采用开源软件搭建，那么网站数据库就是公开的；（2）错误回显，如果网
3、站开启了错误回显，即服务器内部 500 错误会显示到浏览器上，攻击者可以通过故意构造非法数据，使服务器异常信息输出到浏览器端，为攻击猜测数据库表结构提供了便利；（3）盲注，攻击者根据页面变化情况判断 SQL 语句的执行情况来猜测数据库表结构；除了 SQL 注入，攻击者还根据具体应用，注入 OS 命令、编程语言代码等达到攻击目的。防御措施：（1）消毒和防 XSS 攻击一样，过滤请求数据中可能注入的 SQL，如“drop table“等。另外还可以利用参数绑定来防止 SQL 注入。（2）参数绑定使用参数绑定是最好的防 SQL 注入方法。目前请多数据层访问框架，如MyBatis、Hibernate
4、都实现了 SQL 预编译和参数绑定，攻击者的恶意 SQL 会被当做SQL 的参数而不是 SQL 命令插入。3. CSRF 攻击CSRF 即 Cross Site Request Forgery（跨站点请求伪造），攻击者通过跨站点请求，以合法用户的身份进行非法操作。CSRF 的主要手段是利用跨站请求，在用户不知情的情况下，以用户的身份伪造请求。其核心是利用了浏览器 Cookie 或服务器 Session 策略，盗取用户身份。CSRF 的防御手段主要是识别请求者身份：（1）表单 TokeCSRF 是一个伪造用户请求的操作，所以需要构造用户请求的所有参数才可以，表单Token 通过在请求参数中增加随
5、机数的办法来组织攻击者获取所有请求参数。（2）验证码更加简单高效，即请求提交时，需要用户输入验证码，以避免在用户不知情的情况下被攻击者伪造请求。（3）Referer CheckHTTP 请求头的 Referer 域中记录着请求来源，可通过检查请求来源，验证其是否合法，还可以利用这个功能来实现突破防盗链。4. 其他攻击和漏洞（1）Error Code(错误回显）：获取异常信息进行攻击。通过配置 Web 服务器参数跳转 500 页面到专门的错误页面。（2）HTML 注释，HTML 注释会显示在客户端浏览器中。（3）文件上传，上传病毒文件。设置上传白名单，只允许上传可靠的文件类型。还可以修改文件名、
6、使用专门的存储等。（4）路径遍历，在 URL 中使用相对路径，遍历系统未开放的目录和文件。防御方法是将 JS、CSS 等资源部署在独立服务器、使用独立域名，其他文件不使用静态 URL 访问。5. WEB 应用防火墙ModSecurity 是一个开源的 Web 应用防火墙（拦截请求、过滤恶意参数，自动消毒、添加 Token），探测攻击并保护 Web 应用程序，既可以嵌入到 Web 应用服务器中，也可以作为一个独立的应用程序启动。ModSecurity 最早只是 Apache 的一个模块，现在已经有 Java、NET 多个版本，并支持 Nginx。ModSecurity 采用处理逻辑与攻击规则集合
7、分离的架构模式。处理逻辑（执行引擎）负载请求和相应的拦截过滤，规则加载执行等功能。而攻击规则集合则负责描述对具体攻击的规则定义、模式识别、防御策略等功能。处理逻辑比较稳定，规则集合需要不断针对漏洞进行升级，这是一种可扩展的架构设计。6. 信息加密技术为了保护网站的敏感数据，应用需要对某些数据进行加密处理。（1）单向散列加密（MD5、 SHA） 给散列算法加点盐（salt）增加破解难度。（2）对称加密（DES）（3）非对称加密（RSA）非对称加密使用的加密和解密不是同一密钥，其中一个对外界公开，被成为公钥，另一个只有所有者知道，被称作私钥。用公钥加密的信息必须用私钥才能解开，反之，用私钥加密的信
8、息只有用公钥才能解开。数字签名的过程则相反，签名者用自己的私钥对信息进行加密，然后发送给对方，接收者用签名者的公钥信息进行解密，获得原始明文信息，由于秘钥只有签名者拥有，因此该信息是不可抵赖的，具有签名的性质。HTTPS 传输中浏览器使用的数字证书实质上是经过权威机构认证的非对称加密的公钥。（4）密钥安全管理把密钥和算法放在一个独立的服务器上，甚至做成一个专用的硬件设施，对外提供加密和解密服务。但这种方式成本较高，而且有可能成为应用的瓶颈，每次加密、解密都需要进行一次远程服务调用，系统性能开销也较大。另一种方案是将加解密算法放在应用系统中，密钥则放在独立的服务器中，为了提高密钥的安全性，实际存
9、储时，密钥被切分成数片，加密后保存在不同存储介质中。7. 信息过滤与反垃圾（1）文本匹配主要解决敏感词过滤的问题，通过 Trie 树、多级 Hash 表进行文本匹配。（2）分类算法主要解决识别垃圾信息，分类算法先将批量已分类的邮件样本（5000 正常，2000 垃圾）输入分类算法进行训练，得到一个垃圾邮件分类模型，然后利用分类算法结合分类模型对待处理出险的进行识别。如贝叶斯分类算法，如“茶叶”出现在垃圾邮件中的概率为20%，出现在正常邮件的概率为 1%，就得到了这个分类模型，会存在误判和漏判。（3）黑名单8. 电子商务风险控制账户风险：账户被盗、恶意注册等；买家风险：恶意下单占用库存，良品拒收
10、，欺诈退款等；卖家风险：货不对板、虚假发货、炒作信用、出售违禁品、侵权产品；交易风险：盗刷卡、洗钱等（1）风控规则引擎：当交易的某些指标满足一定条件时，就会被认为具有高风险的欺诈可能性。比如用户来自欺诈高发地区；交易金额超过某个数量，和上次登陆的地址距离差距很大，用户登陆地与收货地不符，用户第一次交易等。（2）统计模型根据历史交易中的欺诈交易信息训练分类算法，然后将经过采集加工后的交易信息输入分类算法，即可得到交易风险分值。八、网购秒杀系统架构设计案例分析1. 秒杀活动的技术挑战（1）对现有网站业务造成冲击秒杀活动只是网站营销的一个附加活动，特点是：时间短、并发访问量大，如果和网站原有应用部署
11、在一起，必然会对现有业务造成冲击。 稍有不慎可能导致整个网站瘫痪。（2）高并发下的应用、数据库负载用户在秒杀开始前，通过不停刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器和数据库服务器造成负载压力。（3）突然增加的网络及服务器带宽假设商品页面大小 200K（主要是商品图片大小），10000 个请求的带宽就是 2G。（4）直接下单秒杀的游戏规则是到了秒杀才能开始对商品下单购买，在此时间点之前，只能浏览商品信息，不能下单。而下单页面也是一个普通的 URL，如果得到这个 URL，不用等到秒杀开始就可以下单了。 2. 秒杀系统的应对策略
12、（1）秒杀系统独立部署将秒杀系统独立部署，甚至使用独立域名，使其与网站完全隔离。即使秒杀系统崩溃也不会对网站造成任何影响。（2）秒杀商品页面静态化重新设计秒杀商品页面，不使用网站原来的商品详细页面，页面内容静态化（将商品描述、商品参数、成效记录和用户评价全部写入一个静态页面），用户请求不需要经过应用服务器的业务逻辑处理，也不需要访问数据库。所以秒杀商品服务不需要部署动态的 Web服务器和数据库服务器。（3）租借秒杀活动网络带宽因为秒杀新增的网络带宽，必须和运营商重新购买或者租借。为了减轻网站服务器的压力，需要将秒杀商品页面缓存在 CDN，同样需要和 CDN 服务商临时租借新增的出口带宽。（4）
13、动态生成随机下单页面 URL为了避免用户直接访问下单页面 URL，需要将改 URL 动态化，即使秒杀系统的开发者也无法在秒杀开始前访问下单页面的 URL。办法是在下单页面 URL 加入由服务器端生成的随机数作为参数，在秒杀开始的时候才能得到。3. 秒杀系统架构设计（1）如何控制秒杀商品页面购买按钮的点亮购买按钮只有在活动开始的时候才能点亮，在此之前是灰色的。如果是动态页面，可以很容易解决这个问题，但为了减轻服务器负载压力，该页面设计为静态页面，缓存在CDN、反向代理服务器上，甚至用户浏览器上。秒杀开始时，用户刷新页面，请求根本不会到达应用服务器。解决方案是使用 JavaScript 脚本控制，
14、在秒杀商品静态页面中加入一个 JavaScript 文件引用，该 JavaScript 文件中加入秒杀是否开始的标志和下单页面 URL 的随机数参数，当秒杀开始的时候生成一个新的 JavaScript 文件并被用户浏览器加载，控制秒杀商品页面的展示。这个 JavaScript 文件使用随机版本号，并且不被浏览器、CDN 和反向代理服务器缓存。这个 JS 文件非常小，即使每次器刷新都访问 JS 文件服务器也不会对服务器集群和网络带宽造成太大压力。（2）如何只允许第一个提交的订单被发送到订单子系统由于最终能够成功秒杀到商品的用户只有一个，因此需要在用户提交订单时，检查是否已经有订单提交。为了减轻下
15、单页面服务器的负载压力，可以控制进入下单页面的入口，只有少数用户能进入下单页面，其他用户直接返回秒杀结束页面。活动开始：请求发送至下单服务器；下单服务器检查本机已处理的下单请求数目；如果超过 10 条，直接返回已结束页面给用户。如果未超过 10 条，则用户可进入填写订单及确认页面； 检查全局已提交订单数目，已超过秒杀商品总数，返回已结束页面给用户。未超过秒杀商品总数，提交到子订单系统。九、大型网站典型故障案例分析大型网站的架构师最有价值的地方不在于他们掌握了多少技术，而在于他们经历过多少故障。1. 写日志也会引发故障故障现象：某应用服务器集群发布后不久就出现多台服务器相继报警，硬盘可用空间低于
16、警戒值，并且很快有服务器宕机，登录到线上服务器，发现 log 文件夹里的文件迅速增加，不断消耗磁盘空间。原因分析：查日志内容发现开发人员将 log 输出的 level 全局配置为 Debug，这样一次简单的 web 请求就会产生大量的 log 文件输出，在高并发的用户请求下，很快就消耗完磁盘空间。经验：线上的日志输出级别至少为 Warn。2. 高并发访问数据库引发故障故障现象：某应用发布后，数据库 Load 居高不下，远超正常水平，持续报警。原因分析：检查数据库，发现报警是因为某条 SQL 引起，这条 SQL 是一条简单的有索引的数据查询，不应该引发报警。继续检查，发现这条 SQL 执行频率非
17、常高，远超正常水平。追查这条 SQL，发现被网站首页应用调用，首页是被访问最频繁的网页，这条 SQL 被首页调用，也就被频繁执行了。经验：首页不应该访问数据库，首页需要的数据可以从缓存服务器或者搜索引擎服务器获取；首页最好是静态的。3. 高并发情况下锁引发的故障故障现象：某应用服务器不定时因为响应超时而报警，但是很快又超时解除，恢复正常，如此反复，让运维人员非常苦恼。原因分析：程序中某个单例对象(Singleton object)中多处使用了 synchronized(this)，由于 this 对象只有一个，所有的并发请求都要排队获得这唯一的一把锁。一般情况下，都是一些简单操作，获得锁，迅速
18、完成操作，释放锁，不会引起线程排队。但是某个需要远程调用的操作也被加了 synchronized(this)，这个操作只是偶然被执行，但是每次执行都需要较长的时间才能完成，这段时间锁被占用，所有的用户线程都要等待，响应超时，这个操作执行完后释放锁，其他线程迅速执行，超时解除。经验：谨慎使用锁。4. 缓存引发的故障故障现象：没有新应用发布，但是数据库服务器突然 Load 飙升，并很快失去响应。DBA将数据库访问切换到备机，Load 也很快飙升，并失去响应。最终引发网站全部瘫痪。原因分析：缓存服务器在网站服务器集群中的地位一直比较低，服务器配置和管理级别都比其他服务器要低一些。人们都认为缓存是改善性能的手段，丢失一些缓存也没有什么问
