第十一周 学习总结

用户头像
熊桂平
关注
发布于: 2020 年 12 月 07 日

1.安全架构

1.1互联网系统面临的安全问题和应对方法

  • XSS攻击

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

  • SQL注入攻击

当系统使用sql拼接的方式来执行业务处理,攻击者在知道了表结构的情况下,可以通过sql特殊字符的方式来获取系统数据或对系统造成危害。使用SQL预编译手段,绑定参数是最好的防SQL 注入方法。目前许多数据访问层框架,如myBatis,Hibernate 等,都实现SQL 预编译和参数绑定,攻击者的恶意SQL 会被当做SQL 的参数,而不是SQL 命令被执行。

  • CSRF攻击

用户登录受信服务器后,攻击者通过让用户访问攻击者服务器的方式,来向受信服务器发送攻击请求。CSRF 是一个伪造用户请求的操作,所以需要构造用户请求的所有参数才可以。表单Token 就是阻止攻击者获得所有请求参数的可能,在页面表单中增加一个随机数Token,每次请求的Token 都不相同,请求提交后检查Token 的值是否正确以确定请求提交者是否合法。

  • 其他需要关注的攻击和漏洞

Error Code:也称作错误回显,许多Web 服务器默认是打开异常信息输出的,即服务器端未处理的异常堆栈信息会直接输出到客户端浏览器,这种方式虽然对程序调试和错误报告有好处,但同时也给黑客造成可乘之机。通过故意制造非法输入,使系统运行时出错,获得异常信息,从而寻找系统漏洞进行攻击。防御手段也很简单,通过配置Web 服务器参数,跳转500页面(HTTP 响应码500表示服务器内部错误)到专门的错误页面即可,这个功能Web 应用常用的MVC 框架也可以做到。

1.2加密解密

加密就是通过密码算术对数据进行转化,使之成为没有正确密钥任何人都无法读懂的报文。而这些以无法读懂的形式出现的数据一般被称为密文

加密,即采用一些方式对数据进行处理后,使数据从表面上看,已经不能表达出原有的意思。

解密,就是对加密过的数据采用某些方法,去还原原有数据面貌,从而了解所包含信息的真实意图。

1.2.1单向散列加密

将数据进行计算变成另一种固定长度的值,而且这种行为不可逆。这种加密算法具备几个特点:

  • 定长输出,碰撞几率极低

  • 相同消息反复加密获得同样的密文

  • 雪崩效应,即使微小的单个字节的变化,也能引起加密结果的巨大变化

  • 密文不可逆,即从密文不可以推出原明文。

常用算法

MD5、SHA1、、SHA256、SHA384、SHA512

1.2.2对称加密技术

使用同一个密钥,对数据镜像加密和解密,这种加密技术,称为对称加密。

常用算法:

DES,3DES,IDEA,AES

优点

  • 算法公开、计算量小、加密速度快、加密效率高

缺点

  • 不同通讯双方使用不同密钥,导致密钥过多,难以管理

  • 通讯双方密钥交换,无法保证安全

  • 无法验证发送者和接受者身份

  • 数据完整性无法保证

1.2.3非对称加密技术

Public-key cryptography,即公开密钥加密,又称非对称加密。在这个加密过程中,需要一对密钥,不公开的密钥称为私钥,公开的那一个密钥称为公钥。

常用算法:

RSA,DSA,EIGamal

优点

  • 密钥数目较少。

  • 从一对密钥中的任何一个密钥都不能计算出另一个密钥。

  • 使用一对密钥中的任何一个加密,只有另一个密钥才能解密。如果截获公钥加密数据,没有私钥也无法解密。

缺点

  • 算法复杂,加密解密速度要慢

  • 密钥交换也不是非常安全

1.3反垃圾与风控

常用的信息过滤与反垃圾手段有以下几种。

1.3.1文本匹配

文本匹配主要解决敏感词过滤的问题。通常网站维护一份敏感词列表,如果用户发表的信息含有列表中的敏感词,则进行消毒处理(将敏感转义为***)或拒绝发表。

那么如何快速的判断用户信息是否含有敏感词呢?如果敏感词比较少,用户提交信息文本长度也较短,可直接使用正则表达式匹配。但是正则表达式的效率一般较差,当敏感词很多,用户发布的信息也很长,网站并发量较高时,就需要更合适的方法来完成,这方面公开的算法有很多,基本上都是Trie树的变种,空间和时间复杂度都比较好的有双数组Trie算法等。

Trie算法的本质是确定一个有限状态自动机,根据输入数据进行状态转移。双数组Trie算法优化了Trie算法,利用两个系数数组存储树结构,base数组存储Trie树的节点,check数组进行状态检查。双数组Trie树需要根据业务场景和经验确定数组大小,避免数组过大或者冲突过多。

另一种更简单的的实现是通过构造多级Hash表进行文本匹配。假设敏感词表包含敏感词:阿拉伯、阿富汗、阿油、北京、北大荒、北风。那么可以构造如下图所示的过滤树,用户提交的信息逐字顺序在过滤树中匹配。过滤树的分支可能会比较多,为了提高匹配速度,减少不必要的查找,同一层中相同父节点的字可以放在Hash表中。该方案处理速度较快,稍加变形,即可适应各种过滤场景,缺点是使用Hash表会浪费部分内存空间,如果网站敏感词数量不多,浪费部分内存还是可以接受的。

多级Hash表进行文本匹配



1.3.2分类算法

早期网站识别垃圾信息的主要手段是人工方式,后台运营人员对信息进行人工审核。对大型网站而言,特别是以社交为主的Web2.0网站,如Facebook或Linkedin这样的网站,每天用户提交的信息数千万计,许多垃圾信息混杂其中,影响用户体验;而对于B2B类的电子商务交易撮合网站,用户主要通过站内信等手段进行商品信息咨询,有时候站内信充斥大量广告,甚至淹没正常询盘,引起用户不满和投诉。

对如此海量的信息进行人工审核是不现实的,对广告贴、垃圾邮件等内容识别比较好的自动化方法是采用分类算法。

以反垃圾邮件为例说明分类算法的使用,如下图所示。先将批量已分类的邮件样本(如50000封正常邮件,2000封垃圾邮件)输入分类算法进行训练,得到一个垃圾邮件分类模型,然后利用分类算法结合分类模型对待处理邮件进行识别。

反垃圾邮件

贝叶斯算法

贝叶斯算法解决概率论中的一个典型问题:一号箱子放有红色球和白色球各20个,二号

箱子放有白色球10个,红色球30个,现在随机挑选一个箱子,取出来一个球的颜色是红

色的,请问这个球来自一号箱子的概率是多少。

利用贝叶斯算法进行垃圾邮件的识别基于同样原理,根据已分类的样本信息获得一组特

征值的概率(如“茶叶”这个词出现在垃圾邮件中的概率和非垃圾邮件中的概率),就

得到分类模型,然后对待处理信息提取特征值,结合分类模型,判断其分类。

贝叶斯公式



1.3.3黑名单

对于垃圾邮件,除了用分类算法进行内容分类识别,还可以使用黑名单技术,将被报告的垃圾邮箱地址放入黑名单,然后针对邮件的发件人在黑名单列表中查找,如果查找成功,则过滤该邮件。

黑名单也用于信息去重,如将文章标题或者文章关键段落记录在黑名单中,以减少搜索引擎收录重复信息等用途。

黑名单可以通过Hash表实现,该方法实现简单,时间复杂度小,满足一般场景使用。但是当黑名单列表非常大时,Hash表需要占据极大的内存空间。例如在需要处理10亿个黑名单邮件地址列表的场景下,每个邮件地址需要8个字节的信息指纹,即需要8GB内存,为了减少Hash冲突,还需要一定的Hash空间冗余,加入空间利用率为50%,则需要16GB的内存空间。随着列表的不断增大,一般服务器将不可承受这样的内存需求。而且列表越大,Hash冲突越多,检索速度越慢。

1.3.4电子商务风险控制

电子商务网站在给人们代理购物交易的极大便利的同时,也将风险带给了对网络安全一无所知的人们。由于买卖双方的信息不对等,交易本来就存在风险,而当交易在网上发生的时候,买卖双方彼此一无所知,交易风险也就更加难以控制。如果一个电商网站骗子横行,诚信的交易者屡屡被骗,那么网站就到了最危险的时候,可以说,交易安全是电子商务网站的底线。

电子商务具有多种形式,B2B,B2C,C2C 每种交易的场景都不相同,风险也各有特点,

大致可分为以下几种:

  • 账户风险:包括账户被黑客盗用,恶意注册账号等几种情形。

  • 买家风险:买家恶意下单占用库存进行不正当竞争;黄牛利用促销抢购低价商品;此外还有

良品拒收,欺诈退款以及常见于B2B 交易的虚假询盘等。

  • 卖家风险:不良卖家进行恶意欺诈的行为,例如货不对板,虚假发货,炒作信用等,此外还

有发布违禁商品、侵权产品等。

  • 交易风险:信用卡盗刷,支付欺诈,洗钱套现等。

风控

大型电商网站都配备有专门的风控团队进行风险控制,风控的手段也包括自动和人工两种。机器自动识别为高风险的交易和信息会发送给风控审核人员进行人供审核,机器自动风控的技术和方法也不断通过人工发现的新风险类型进行逐步完善。

2.高可用

2.1可用性指标

业界通常用多少个9来衡量网站的可用性,如QQ 的可用性是4个9,即QQ 服务99.99%可用,这意味着QQ 服务要保证其在所有运行时间中,只有0.01%的时间不可用,也就是一年中大约53分钟不可用。



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

  • 网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点



对可用性的定性描述,两个9是基本可用,年度停机时间小于88小时;3个9较高可用,年度停机时间小于9小时;4个9是具有自动恢复能力的高可用,年度停机时间小于53分钟;5个9是极高可用性,年度停机时间小于5分钟。由于可用性影响因素很多,对于网站整体而言,达到4个9,乃至5个9的可用性,除了过硬的技术、大量的设备资金投入和工程师的责任心,还要有个好运气。



2.2故障分管理

分类描述权重

  • 事故级故障:严重故障,网站整体不可用 :100

  • A类故障:网站访问不顺畅,或核心功能不可用 :20

  • B类故障:非核心功能不可用,或核心功能少数用户不可用:5

  • C类故障:其他类故障:1

2.3引起故障的原因

  • 硬件故障

  • 软件bug

  • 系统发布

  • 并发压力

  • 网络攻击

  • 外部灾害

2.4高可用系统的架构

2.4.1解耦

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

  • 面向对象基本设计原则

  • 面向对象设计模式

  • 领域驱动设计建模

2.4.2隔离

  • 业务与子系统隔离

  • 微服务与中台架构

  • 生产者消费者隔离

  • 虚拟机与容器隔离

2.4.3异步

  • 多线程编程

  • 反应式编程

  • 异步通信网络编程

  • 事件驱动异步架构

2.4.5备份

  • 集群设计

  • 数据库复制

  • CAP 原理

2.4.6Failover(失效转移)

  • 数据库主主失效转移

  • 负载均衡失效转移

如何确认失效,需要转移?

  • 设计无状态的服务

2.4.7幂等

应用调用服务失败后,会将调用请求重新发送到其他服务器,但是这个失败可能是虚假的失败。比如服务已经处理成功,但是因为网络故障应用没有收到响应,这时应用重新提交请求就导致服务重复调用,如果这个服务是一个转账操作,就会产生严重后果。

服务重复调用有时候是无法避免的,必须保证服务重复调用和调用一次产生的结果相同,即服务具有幂等性。有些服务天然具有幂等性,比如将用户性别设置为男性,不管设置多少次,结果都一样。但是对于交易等操作,问题就会比较复杂,需要通过交易编号等信息进行服务调用有效性校验,只有有效的操作才继续执行。

2.4.8事务补偿

传统事务的ACID

  • 原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation,又称独立性)、持久性

(Durability)

分布式事务的BASE

  • 基本可用(Basic Availability )、软状态(Soft-state)、最终一致性(Eventual consistency)

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

2.4.9重试

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

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



2.4.10熔断

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

  • 断路器三种状态:关闭,打开,半开

熔断

2.4.11限流

在高并发场景下,如果系统的访问量超过了系统的承受能力,可以通过限流对系统进行保护。限流是指对进入系统的用户请求进行流量限制,如果访问量超过了系统的最大处理能力,就会丢弃一部分的用户请求,保证整个系统可用,保证大部分用户是可以访问系统的。这样虽然有一部分用户的请求被丢弃,产生了部分不可用,但还是好过整个系统崩溃,所有的用户都不可用要好。

限流的几种算法

  • 计数器算法(固定窗口,滑动窗口)

  • 令牌桶算法

  • 漏桶算法

2.4.12降级

有一些系统功能是非核心的,但是它也给系统产生了非常大的压力,比如说在电商系统中有确认收货这个功能,即便我们不去确认收货,系统也会超时自动确认收货。

但实际上确认收货这个操作是一个非常重的操作,因为它会对数据库产生很大的压力:它要进行更改订单状态,完成支付确认,并进行评价等一系列操作。如果在系统高并发的时候去完成这些操作,那么会对系统雪上加霜,使系统的处理能力更加恶化。

解决办法就是在系统高并发的时候,比如说像淘宝双11 的时候,当天可能整天系统都处于一种极限的高并发访问压力之下,这时候就可以将确认收货、评价这些非核心的功能关闭,将宝贵的系统资源留下来,给正在购物的人,让他们去完成交易。

2.4.13异地多活

如果整个数据中心都不可用,比如说数据中心所在城市遭遇了地震,机房遭遇了火灾或者停电,这样的话,不管我们的设计和系统多么的高可用,系统依然是不可用的。

为了解决这个问题,同时也为了提高系统的处理能力和改善用户体验,很多大型互联网应用都采用了异地多活的多机房架构策略,也就是说将数据中心分布在多个不同地点的机房里,这些机房都可以对外提供服务,用户可以连接任何一个机房进行访问,这样每个机房都可以提供完整的系统服务,即使某一个机房不可使用,系统也不会宕机,依然保持可用。



用户头像

熊桂平

关注

还未添加个人签名 2020.09.14 加入

还未添加个人简介

评论

发布
暂无评论
第十一周 学习总结