欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

白帽子讲Web安全(第 1 章 我的安全世界观)

程序员文章站 2022-03-03 20:35:19
第 1 章 我的安全世界观互联网本来是安全的,自从有了研究安全的人之后,互联网就变得不安全了。1.1 Web安全简史研究计算机系统和网络的人,被称为“ Hacker ”,他们对计算机系统有着深入的理解,因此往往能够发现其中的问题。“ Hacker ”在中国按照音译,被称为“黑客”。在计算机安全领域,黑客是一群破坏规则、不喜欢拘束的人,因此总想着能够找到系统的漏洞,以获得一些规则之外的权力。对于现代计算机系统来说,在用户态的最高权限是 root ( administrator ),也是黑客们最渴望能够...

第 1 章 我的安全世界观

互联网本来是安全的,自从有了研究安全的人之后,互联网就变得不安全了。

1.1 Web安全简史

研究计算机系统和网络的人,被称为“ Hacker ”,他们对计算机系统有着深入的理解,因此往往能够发现其中的问题。“ Hacker ”在中国按照音译,被称为“黑客”。在计算机安全领域,黑客是一群破坏规则、不喜欢拘束的人,因此总想着能够找到系统的漏洞,以获得一些规则之外的权力。

对于现代计算机系统来说,在用户态的最高权限是 root ( administrator ),也是黑客们最渴望能够获取的系统最高权限。“ root ”对黑客的吸引,就像大米对老鼠的吸引,美女对色狼的吸引。

不想拿到“ root ”的黑客,不是好黑客。

黑客们使用的漏洞利用代码。被称为“ exploit ”。

在黑客的世界里,有的黑客,精通计算机技术,能自己挖掘漏洞,并编写 exploit ;而有的黑客,则只对攻击本身感兴趣,对计算机原理和各种编程技术的了解比较粗浅,因此只懂得编译别人的代码,自己并没有动手能力,这种黑客被称为“ Script Kids ”,即“脚本小子”。

在现实世界里,真正造成破坏的,往往并非那些挖掘并研究漏洞的“黑客”们,而是这些脚本小子。而在今天已经形成产业的计算机犯罪、网络犯罪中,造成主要破坏的,也是这些“脚本小子”。

1.1.1 中国黑客简史

中国黑客的发展分为了:启蒙时代、黄金时代、黑暗时代。

  1. 启蒙时代,这个时期大概处在20世纪90年代,此时中国的互联网也刚刚处于起步阶段,一些热爱新兴技术的青年受到国外黑客技术的影响,开始研究安全漏洞。启蒙时代的黑客们大多是由于个人爱好而走上这条道路,好奇心与求知欲是驱动他们前进的动力,没有任何利益的瓜葛。这个时期的中国黑客们通过互联网,看到了世界,因此与西方发达国家同期诞生的黑客精神是一脉相传的,他们崇尚分享、*、免费的互联网精神,并热衷于分享自己的最新研究成果。
  2. 黄金时代,这个时期以中美黑客大战为标志。在这个历史背景下,黑客这个特殊的群体一下子几乎吸引了社会的所有眼球,而此时黑客圈子所宣扬的黑客文化以及黑客技术的独特魅力也吸引了无数的青少年走上这条道路。自此事件后,各种黑客组织如雨后春笋般冒出。此阶段的中国黑客,其普遍的特点是年轻,有活力,充满激情,但在技术上也行还不够成熟。此时期黑客圈子里贩卖漏洞、恶意软件的现象开始升温,同时因为黑客群体的良莠不齐,也开始出现以赢利为目的的攻击行为,黑色产业链逐渐成型。
  3. 黑暗时代,这个阶段从几年前开始一直延续到今天,也许还将继续下去。在这个时期黑客组织也遵循着社会发展规律,优胜劣汰,大多数的黑客组织没有坚持下来。在上一个时期非常流行的黑客技术论坛越来月缺乏人气,最终走向没落。所有门户型的漏洞披露站点,也不再公布任何漏洞相关的技术细节。

伴随着安全产业的发展,黑客的功利性越来越强。

而在上一个时期技术还不成熟的黑客们,凡是坚持下来的,都已经成长为安全领域的高级人才,有的在安全公司贡献着自己的专业技能,有的则带着非常强的技术进入了黑色产业。此时期的黑客群体因为互相之间缺失信任已经不再具有开放和分享的精神,最纯粹的黑客精神实质上已经死亡。

1.1.2 黑客技术的发展历程

从黑客技术发展的角度看,在早期,黑客攻击的目标以系统软件居多。一方面,是由于这个时期的 Web 技术发展还远远不成熟;另一方面,则是因为通过攻击系统软件,黑客们往往能够直接获取 root 权限。

相对于那些攻击系统软件的 exploit 而言,基于 Web 的攻击,一般只能让黑客获得一个较低权限的账户,对黑客的吸引力远远不如直接攻击系统软件。

防火墙技术的兴起改变了互联网安全的格局。防火墙、ACL技术的兴起,使得直接暴露在互联网的系统得到了保护。

在有了防火墙的保护后,通过ACL可以控制只允许信任来源的访问。系统软件处于信任边界之内,从而杜绝了大部分的攻击来源

2003 年的冲击波蠕虫是一个里程碑式的事件,整个互联网对于安全的重视达到了一个空前的高度。

运维商、防火墙对于网络的*,使得暴露在互联网上的非 Web 服务越来越少,且 Web 技术的成熟使得 Web 应用的功能越来越强大,最终成为了互联网的主流。黑客们的目光,也渐渐转移到了 Web 这块大蛋糕上。

1.1.3 Web 安全的兴起

Web 攻击技术的发展也可以分为几个阶段。在 Web 1.0 时代,人们更多的是关注服务器端动态脚本的安全问题,比如将一个可执行脚本(俗称 webshell )上传到服务器上,从而获得权限。伴随着 Web 2.0 的兴起, XSS、CSRF 等攻击已经变得更为强大。 Web 攻击的思路也从服务器端转向了客户端,转向了浏览器和用户。

1.2 黑帽子,白帽子

正如一个硬币有两面一样,“黑客”也有好坏之分。在黑客的世界中,往往用帽子的颜色来比喻黑客的好坏。白帽子,则是指那些精通安全技术,但是工作在反黑客领域的专家们;黑帽子,则是指利用黑客技术造成破坏,甚至进行网络犯罪的群体。

同样是研究安全,白帽子和黑帽子在工作时的心态是完全不同的。

对于黑帽子来说,只要能够找到系统的一个弱点,就可以达到入侵系统对的目的;而对于白帽子来说,必须找到系统的所有弱点,不能有遗漏,才能保证系统不会出现问题。这种差异是由于工作环境与工作目标的不同所导致的。白帽子一般为企业或安全公司服务,工作的出发点就是要解决所有的安全问题,因此所看所想必然要求更加的全面、宏观;黑帽子的主要目的是要入侵系统,找到对他们有价值的数据,因此黑帽子只需要以点突破,找到对他们最有用的一点,以此渗透,因此思考问题的出发点必然是有选择性的、微观的。

从对待问题的角度来看,黑帽子为了完成一次入侵,需要利用各种不同漏洞的组合来达到目的,是在不断地组合问题;而白帽子在设计解决方案时,如果只看到各种问题组合后产生的效果,就会把事情变复杂,难以细致入微的解决根本问题,所以白帽子必然时在不断地分解问题,再对分解后的问题逐个予以解决。

“ No Patch For Stupid! ”,在安全领域也普遍认为:“最大的漏洞就是人!”。写得再好的程序,在有任参与的情况下,就可能会出现各种各样不可预知的情况,比如管理员的密码有可能泄露,程序员有可能关掉了安全的配置参数等等。

防御技术在不断完善的同时,攻击技术也在不断地发展。

1.3 返璞归真,揭秘安全地本质

安全时什么?什么样地情况下会产生安全问题?我们要如何看待安全问题?只有搞明白了这些最基本地问题,才能明白一切防御技术地出发点,才能明白为什么我们要这样做,要那样做。

那么,一个安全问题时如何产生地呢?我们不妨先从现实世界入手。火车站、机场里,在乘客们开始正式旅程之前,都有一个必要的程序:安全检查。机场的安全检查,会扫描乘客的行李箱,检查乘客身上时否携带了打火机、可燃液体等危险物品。抽象地说,这种安全检查,就是过滤掉有害的、危险的东西。因为在飞行的过程中,飞机远离地面,如果发生危险,将会直接危害到乘客们的生命安全。因此,飞机时一个高度敏感和重要的区域,任何有危害的物品都不因该进入这一区域。为达到这一目标,登机前的安全检查就是一个非常有必要的步骤。

通过一个安全检查(过滤、净化)的过程,可以梳理未知的人或物,使其变得可信任。被划分出来的具有不同信任级别的区域,我们称为信任域,划分两个不同信任域之间的边界,我们称为信任边界

++数据从高等级的信任域流向低等级的信任域,是不需要经过安全检查的;数据从低等级的信任域流向高等级的信任域,则需要经过信任边界的安全检查。++

安全问题的本质是信任的问题。

一切的安全方案设计的基础,都是建立在信任关系上的。我们必须相信一些东西,必须有一些最基本的假设,安全方案才能得以建立;如果我们否定一切,安全方案就会如无源之水,无根之水,无法设计,也无法完成。

把握住信任条件的度,使其恰到好处,正是设计安全方案的难点所在,也是安全这门学问的艺术魅力所在。

1.4 破除迷信,没有银弹

在解决安全问题的过程中,不可能一劳永逸,也就是说“没有银弹”。

任何人想要一劳永逸地解决安全问题,都属于一厢情愿,是“自己骗自己”,是不现实的。

安全是一个持续的过程。

自从互联网有了安全问题以来,攻击和防御技术就在不断碰撞和对抗的过程中得到发展。从微观上来说,在某一时期可能某一方占了上风;但是从宏观上来看,某一时期的攻击或防御技术,都不可能永远有效,永远用下去。这是因为防御技术在发展的同时,攻击技术也在不断发展,两者是互相促进的辩证关系。以不变的防御手段对抗不断发展的攻击技术,就犯了刻舟求剑的错误。在安全的邻域中,没有银弹。

1.5 安全三要素

既然安全方案的设计与实施过程中没有银弹,注定是一个持续进行的过程,那么我们该如何开始呢?其实安全方案的设计也有着一定的思路与方法可循,借助这些方法,能够理清我们的思路,帮助我们设计出合理、优秀的解决方案。

在设计安全方案之前,要正确、全面地看待安全问题。

要全面地认识一个安全问题,我们有很多种办法,但首先要理解安全问题的组成属性。前任通过无数实践,最后将安全的属性总结为安全三要素,简称 CIA

安全三要素是安全的基本组成元素,分别是机密性( Confidentiality )、完整性( Integrity )、可用性( Availability )

  1. 机密性要求保护数据内容不能泄露,加密是实现机密性要求的常见手段。
  2. 完整性则要求保护数据内容是完整、没有被篡改的。常见的保证一致性的技术手段是数字签名。
  3. 可用性要求保护资源是“随需而得”。
    ++在安全领域种这种攻击叫做拒绝服务攻击,简称 DoS(Denial of Service)。拒绝服务攻击破坏得是安全得可用性。++

在安全领域种,最基本得要素就是这三个,后来还有人想扩充这些要素,增加了诸如可审计性、不可抵赖性等,但最最重要得还是以上三个要素。在设计安全方案时,也要以这三个要素为基本的出发点,去全面地思考所面对的问题。

1.6 如何实施安全评估

有了前面的基础,我们就可以正式开始分析并解决安全问题了。一个安全评估的过程,可以简单地分为 4 个阶段:资产等级划分、威胁分析、风险分析、确认解决方案

白帽子讲Web安全(第 1 章 我的安全世界观)

安全评估的过程

1.6.1 资产等级划分

资产等级划分是所有工作的基础,这项工作能够帮助我们明确目标是什么,要保护什么。

互联网安全的核心问题,是数据安全的问题。

这与我们做资产评估又有什么关系呢?有,因为对互联网公司拥有的资产进行等级划分,就是对数据做等级划分。

当完成资产等级划分后,对要保护的目标已经有了一个大概的了解,接下来就是要划分信任域和信任边界了。通常我们用一种最简单的划分方式,就是从网络逻辑上来划分。

1.6.2 威胁分析

信任域划好之后,我们如何才能确定危险来自哪里呢?在安全领域里,我们把可能造成危害的来源称为威胁( Threat ),而把可能会出现的损失称为风险( Risk )。

++概念区分,风险一定是和损失联系在一起的。++

什么是威胁分析?威胁分析就是把所有的威胁都找出来。怎么找?一般是采用头脑风暴法。当然,也有一些比较科学的方法,比如使用一个模型,帮助我们去想,在哪些方面有可能会存在威胁,这个过程能够避免遗漏,这就是威胁键模

STRIDE 模型的威胁建模的方法最早由微软提出的。

STRIDE 是 6 个单词的首字母缩写,我们在分析威胁时,可以从以下 6 个方面去考虑。

威胁 定义 对应的安全属性
Spoofing (伪装) 冒充他人身份 认证
Tampering(篡改) 修改数据或代码 完整性
Repudiation(抵赖) 否认做过的事情 不可抵赖性
InformationDisclosure(信息泄露) 机密信息泄露 机密性
Denial of Service(拒绝服务) 拒绝服务 可用性
Elevation of Privileage(提升权限) 未经授权获得许可 授权

在进行威胁分析时,要尽可能地不遗漏威胁,头脑风暴的过程可以确定攻击面( Attack Surface )。

一个威胁到底能够造成多大的危害,如何去衡量它?这就要考虑到风险了。我们判断风险高低的过程,就是风险分析的过程。在“风险分析”这个阶段,也有模型可以帮助我们进行科学的思考。

1.6.3 风险分析

风险由以下因素组成:

Risk = Probability * Damage Potential

影响风险高低的因素,除了造成损失的大小外,还需要考虑到发生的可能性。

如何更科学地衡量风险呢?这里再介绍一个 DREAD 模型,它也是由微软提出的。 DREAD 也是几个单词的首字母缩写,它指导我们应该从哪些方面去判断一个威胁的风险程度。

等级 高( 3 ) 中( 2 ) 低( 1 )
Damage Potential(潜在伤害) 获取完全验证权限;执行管理员操作;非法上传文件 泄露敏感信息 泄露其他信息
Reproducibility(重现性) 攻击者可以随意再次攻击 攻击者可以重复攻击,但有时间限制 攻击者很难重复攻击过程
Exploitability(可利用性) 初学者在短期内能掌握攻击方法 熟练的攻击者才能完成这次攻击 漏洞利用条件非常苛刻
Affected users(受影响的用户) 所有用户,默认配置,关键用户 部分用户,非默认配置 极少数用户,匿名用户
Discoverability(可发现性) 漏洞很显眼,攻击条件很容易获得 在私人区域,部分人能看到,需要深入挖掘漏洞 发现该漏洞及其困难

在 DREAD 模型里,每一个因素都可以分为高、中、低三个等级。在上表中,高、中、低三个等级分别以 3、2、1 的分数代表其权重值,因此,我们可以具体计算出某一个威胁的风险值。

以《智取华山》为例,如果*在威胁建模后发现存在两个主要威胁:第一个威胁是从正面入口强攻,第二个威胁时从后山小路爬悬崖上来。那么这两个威胁对应的风险分别计算如下:

  1. 走正面的入口:
Risk = D(3) + R(3) + E(3) + A(3) + D(3) = 3+3+3+3+3 = 15
  1. 走后山的小路:
Risk = D(3) + R(1) + E(1) + A(3) + D(1) = 3+1+1+3+1 = 9

如果我们把风险高低定义如下:

高危:12~15 分
中危:8~11 分
低危:0~7 分

那么,正面入口是最高危的,必然要派重兵把守;而后山小路竟然是中危的,因此也不能忽视。之所以会被这个模型判断为中危的原因,就在于一旦被突破,造成的损失太大,失败不起,所以会响应地提高该风险值。

在任何时候都应该记住----模型是死的,人是活的,再好的模型也是需要人来使用的,在确定攻击面,以及判断风险高低时,都需要有一定的经验,这也是安全工程师的价值所在。

类似模型很多,标准也不同,只要我们觉得这些模型是科学的,能够帮到我们,就可以使用。但模型只能起到要给辅助的作用,最终做出决策的还是人。

1.6.4 设计安全方案

安全评估的产出物,就是安全解决方案。解决方案一定要有针对性,这种针对性是由资产等级划分、威胁分析、风险分析等阶段的结果给出的。

设计解决方案不难,难的是如何设计一个好的解决方案。

很多人认为,安全和业务是冲突的,因为往往为了安全,要牺牲业务的一些易用性或者性能,笔者不太赞同这种观点。从产品的角度来说,安全也应该是产品的一种属性。一个从未考虑过安全的产品,至少是不完整的。

水杯是否好用,除了它能装水,能装多少水外,还要思考这个杯子材料是否会溶解在水里,是否会有毒,高温熔化?低温易碎?这些问题都直接影响用户使用杯子的安全性。

对于互联网来说,安全是要为产品的发展与成长保驾护航的。我们不能使用“粗暴”的安全方案去阻碍产品的正常发展,所以应该形成这样一种观点:==没有不安全的业务,只有不安全的实现方式。==产品需求,尤其是商业需求,是用户真正想要的东西,是业务的意义所在,在设计安全方案时应该尽可能地不要改变商业需求的初衷。

作为安全工程师,要想的就是如何通过简单而有效的方案,解决遇到的安全问题。安全方案必须能够有效抵抗威胁,但同时不能过多干涉正常的业务流程,在性能上也不能拖后腿。

好的安全方案对用户应该时透明的,尽可能地不要更改用户的使用习惯。

好的安全产品或模块除了要兼顾用户体验外,还要易于持续改进。一个好的安全模块,同时也应该时一个优秀的程序,从设计上也需要做到高聚合、低耦合、易于扩展。

一个优秀的安全方案应该具备以下特点:

  • 能够有效解决问题;
  • 用户体验好;
  • 高性能;
  • 低耦合;
  • 易于扩展与升级。

1.7 白帽子兵法

1.7.1 Secure By Default 原则

在设计安全方案时,最基本也是最重要的原则就是“ Secure by Default ”。在做任何安全设计时,都要牢牢记住这个原则。一个方案设计得是否足够安全,与有没有应用这个原则有很大得关系。实际上,“ Secure by Default ” 原则,也可以归纳为白名单、黑名单得思想。如果更多地使用白名单,那么系统就会变得更安全。

1.7.1.1 黑名单、白名单

基于白名单思想,白名单比黑名单安全。

然而,并不是用了白名单就一定安全了。“安全问题得本质是信任问题,安全方案也是基于信任来做的”。选择白名单的思想,基于白名单来设计安全方案,其实就是信任白名单是好的,是安全的。但是一旦这个信任基础不存在了,那么安全就荡然无存。

1.7.1.2 最小权限原则

Secure By Default 的另一层含义就是“最小权限原则”。最小权限原则也是安全设计的基本原则之一。最小权限原则要求系统只授予主体必要的权限,而不要过度授权,这要能有效地减少系统、网络、应用、数据库出错的机会。

1.7.2 纵深防御原则

纵深防御包含两层含义:首先,要在各个不同层面、不同方面实施安全方案,避免出现疏漏,不同安全方案之间需要相互配合,构成一个整体;其次,要在正确的地方做正确的事情,即:在解决根本问题的地方实施针对性的安全方案。

纵深防御并不是同一个安全方案要做两遍或多遍,而是要从不同的层面、不同的角度对系统做出整体的解决方案。

纵深防御的第二层含义,是要在正确的地方做正确的事情。

1.7.3 数据与代码分离原则

缓冲区溢出,也可以认为是程序违背了这一原则的后果----程序在栈或者堆中将用户数据当作代码执行,混淆了代码与数据的边界,从而导致安全问题的发生。

1.7.4 不可预测性原则

本文地址:https://blog.csdn.net/oschina_40326659/article/details/107604246