《白帽子讲Web安全》：互联网安全深度解析

web安全

需积分: 5 22 浏览量更新于2024-07-17 收藏 12.52MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

个威胁对应的风险分别计算如下：

走正面的入口：

Risk = D(3) + R(3) + E(3) + A(3) + D(3) =

3+3+3+3+3=15

走后山小路：

Risk = D(3) + R(1) + E(1) + A(3) + D(1) =

3+1+1+3+1=9

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

高危： 12 ～ 15 分中危： 8 ～ 11 分低危： 0 ～ 7 分

那么，正面入口是最高危的，必然要派重兵把守；而后山小路竟然是中危的，因此也不能忽视。之所以会被这个模型判断为中危的原因，就在于一旦被突

破，造成的损失太大，失败不起，所以会相应地提高该风险值。

介绍完威胁建模和风险分析的模型后，我们对安全评估的整体过程应该有了一个大致的了解。在任何时候都应该记住——模型是死的，人是活的，再好的模

型也是需要人来使用的，在确定攻击面，以及判断风险高低时，都需要有一定的经验，这也是安全工程师的价值所在。类似STRIDE和DREAD的模型可能还

有很多，不同的标准会对应不同的模型，只要我们觉得这些模型是科学的，能够帮到我们，就可以使用。但模型只能起到一个辅助的作用，最终做出决策的

还是人。

1.6.4　设计安全方案　设计安全方案

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

设计解决方案不难，难的是如何设计一个好的解决方案。设计一个好的解决方案，是真正考验安全工程师水平的时候。

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

品的一种属性。一个从未考虑过安全的产品，至少是不完整的。

比如，我们要评价一个杯子是否好用，除了它能装水，能装多少水外，还要思考这个杯子内壁的材料是否会溶解在水里，是否会有毒，在高温时会不会熔

化，在低温时是否易碎，这些问题都直接影响用户使用杯子的安全性。

对于互联网来说，安全是要为产品的发展与成长保驾护航的。我们不能使用“粗暴”的安全方案去阻碍产品的正常发展，所以应该形成这样一种观点：没有不

安全的业务，只有不安全的实现方式。产品需求，尤其是商业需求，是用户真正想要的东西，是业务的意义所在，在设计安全方案时应该尽可能地不要改变

商业需求的初衷。

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

在性能上也不能拖后腿。

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

微软在推出Windows Vista时，有一个新增的功能叫UAC，每当系统里的软件有什么敏感动作时，UAC就会弹出来询问用户是否允许该行为。这个功能在

Vista众多失败的原因中是被人诟病最多的一个。如果用户能够分辨什么样的行为是安全的，那么还要安全软件做什么？同样的问题出现在很多主动防御的桌

面安全保护软件中，它们动辄弹出个对话框询问用户是否允许目标的行为，这是非常荒谬的用户体验。

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

合、易于扩展。比如Nmap的用户就可以自己根据需要写插件，实现一些更为复杂的功能，满足个性化需求。

最终，一个优秀的安全方案应该具备以下特点：

能够有效解决问题；

用户体验好；

高性能；

低耦合；

易于扩展与升级。

关于产品安全性的问题，在本书的“互联网业务安全”一章中还会继续深入阐述。

1.7　白帽子兵法　白帽子兵法

在上节讲述了实施安全评估的基本过程，安全评估最后的产出物就是安全方案，但在具体设计安全方案时有什么样的技巧呢？本节将讲述在实战中可能用到

的方法。

1.7.1　　Secure By Default原则原则

在设计安全方案时，最基本也最重要的原则就是“Secure by Default”。在做任何安全设计时，都要牢牢记住这个原则。一个方案设计得是否足够安全，与有

没有应用这个原则有很大的关系。实际上，“Secure by Default”原则，也可以归纳为白名单、黑名单的思想。如果更多地使用白名单，那么系统就会变得更

安全。

1.7.1.1　黑名单、白名单　黑名单、白名单

比如，在制定防火墙的网络访问控制策略时，如果网站只提供Web服务，那么正确的做法是只允许网站服务器的80和443端口对外提供服务，屏蔽除此之外

的其他端口。这是一种“白名单”的做法；如果使用“黑名单”，则可能会出现问题。假设黑名单的策略是：不允许SSH端口对Internet开放，那么就要审计SSH

的默认端口：22端口是否开放了Internet。但在实际工作过程中，经常会发现有的工程师为了偷懒或图方便，私自改变了SSH的监听端口，比如把SSH的端口

从22改到了2222，从而绕过了安全策略。

又比如，在网站的生产环境服务器上，应该限制随意安装软件，而需要制定统一的软件版本规范。这个规范的制定，也可以选择白名单的思想来实现。按照

白名单的思想，应该根据业务需求，列出一个允许使用的软件以及软件版本的清单，在此清单外的软件则禁止使用。如果允许工程师在服务器上随意安装软

件的话，则可能会因为安全部门不知道、不熟悉这些软件而导致一些漏洞，从而扩大攻击面。

在Web安全中，对白名单思想的运用也比比皆是。比如应用处理用户提交的富文本时，考虑到XSS的问题，需要做安全检查。常见的XSS Filter一般是先对用

户输入的HTML原文作HTMLParse，解析成标签对象后，再针对标签匹配XSS的规则。这个规则列表就是一个黑白名单。如果选择黑名单的思想，则这套规

则里可能是禁用诸如<script>、<iframe>等标签。但是黑名单可能会有遗漏，比如未来浏览器如果支持新的HTML标签，那么此标签可能就不在黑名单之中

了。如果选择白名单的思想，就能避免这种问题——在规则中，只允许用户输入诸如<a>、<img>等需要用到的标签。对于如何设计一个好的XSS防御方案，

在“跨站脚本攻击”一章中还会详细讲到，不在此赘述了。

然而，并不是用了白名单就一定安全了。有朋友可能会问，作者刚才讲到选择白名单的思想会更安全，现在又说不一定，这不是自相矛盾吗？我们可以仔细

分析一下白名单思想的本质。在前文中提到：“安全问题的本质是信任问题，安全方案也是基于信任来做的”。选择白名单的思想，基于白名单来设计安全方

案，其实就是信任白名单是好的，是安全的。但是一旦这个信任基础不存在了，那么安全就荡然无存。

在Flash跨域访问请求里，是通过检查目标资源服务器端的crossdomain.xml文件来验证是否允许客户端的Flash跨域发起请求的，它使用的是白名单的思想。

比如下面这个策略文件：

<cross-domain-policy>

<allow-access-from domain="*.taobao.com"/>

<allow-access-from domain="*.taobao.net"/>

<allow-access-from domain="*.taobaocdn.com"/>

<allow-access-from domain="*.tbcdn.cn"/>

<allow-access-from domain="*.allyes.com"/>

</cross-domain-policy>

指定了只允许特定域的Flash对本域发起请求。可是如果这个信任列表中的域名变得不可信了，那么问题就会随之而来。比如：

<cross-domain-policy>

<allow-access-from domain="*"/>

</cross-domain-policy>

通配符“”

，代表来自任意域的

Flash

都能访问本域的数据，因此就造成了安全隐患。所以在选择使用白名单时，需要注意避免出现类似通配符

“”的问题。

1.7.1.2　最小权限原则　最小权限原则

Secure By Default的另一层含义就是“最小权限原则”。最小权限原则也是安全设计的基本原则之一。最小权限原则要求系统只授予主体必要的权限，而不要

过度授权，这样能有效地减少系统、网络、应用、数据库出错的机会。

比如在Linux系统中，一种良好的操作习惯是使用普通账户登录，在执行需要root权限的操作时，再通过sudo命令完成。这样能最大化地降低一些误操作导致

的风险；同时普通账户被盗用后，与root帐户被盗用所导致的后果是完全不同的。

在使用最小权限原则时，需要认真梳理业务所需要的权限，在很多时候，开发者并不会意识到业务授予用户的权限过高。在通过访谈了解业务时，可以多设

置一些反问句，比如：您确定您的程序一定需要访问Internet吗？通过此类问题，来确定业务所需的最小权限。

1.7.2　纵深防御原则　纵深防御原则

与Secure by Default一样，Defense inDepth（纵深防御）也是设计安全方案时的重要指导思想。

纵深防御包含两层含义：首先，要在各个不同层面、不同方面实施安全方案，避免出现疏漏，不同安全方案之间需要相互配合，构成一个整体；其次，要在

正确的地方做正确的事情，即：在解决根本问题的地方实施针对性的安全方案。

某矿泉水品牌曾经在广告中展示了一滴水的生产过程：经过十多层的安全过滤，去除有害物质，最终得到一滴饮用水。这种多层过滤的体系，就是一种纵深

防御，是有立体层次感的安全方案。

纵深防御并不是同一个安全方案要做两遍或多遍，而是要从不同的层面、不同的角度对系统做出整体的解决方案。我们常常听到“木桶理论”这个词，说的是

一个桶能装多少水，不是取决于最长的那块板，而是取决于最短的那块板，也就是短板。设计安全方案时最怕出现短板，木桶的一块块板子，就是各种具有

不同作用的安全方案，这些板子要紧密地结合在一起，才能组成一个不漏水的木桶。

在常见的入侵案例中，大多数是利用Web应用的漏洞，攻击者先获得一个低权限的webshell，然后通过低权限的webshell上传更多的文件，并尝试执行更高

权限的系统命令，尝试在服务器上提升权限为root；接下来攻击者再进一步尝试渗透内网，比如数据库服务器所在的网段。

在这类入侵案例中，如果在攻击过程中的任何一个环节设置有效的防御措施，都有可能导致入侵过程功亏一篑。但是世上没有万能灵药，也没有哪种解决方

案能解决所有问题，因此非常有必要将风险分散到系统的各个层面。就入侵的防御来说，我们需要考虑的可能有Web应用安全、OS系统安全、数据库安全、

网络环境安全等。在这些不同层面设计的安全方案，将共同组成整个防御体系，这也就是纵深防御的思想。

纵深防御的第二层含义，是要在正确的地方做正确的事情。如何理解呢？它要求我们深入理解威胁的本质，从而做出正确的应对措施。

在XSS防御技术的发展过程中，曾经出现过几种不同的解决思路，直到最近几年XSS的防御思路才逐渐成熟和统一。

XSS防御技术的发展过程

在一开始的方案中，主要是过滤一些特殊字符，比如：

<<笑傲江湖>>

会变成　　

笑傲江湖

尖括号被过滤掉了。

但是这种粗暴的做法常常会改变用户原本想表达的意思，比如：

1<2

可能会变成　　

1 2

造成这种“乌龙”的结果就是因为没有“在正确的地方做正确的事情”。对于XSS防御，对系统取得的用户输入进行过滤其实是不太合适的，因为XSS真正产生危

害的场景是在用户的浏览器上，或者说服务器端输出的HTML页面，被注入了恶意代码。只有在拼装HTML时输出，系统才能获得HTML上下文的语义，才能

判断出是否存在误杀等情况。所以“在正确的地方做正确的事情”，也是纵深防御的一种含义——必须把防御方案放到最合适的地方去解决。（XSS防御的更多

细节请参考“跨站脚本攻击”一章。）

近几年安全厂商为了迎合市场的需要，推出了一种产品叫UTM，全称是“统一威胁管理”（Uni-fied Threat Management）。UTM几乎集成了所有主流安全产

品的功能，比如防火墙、VPN、反垃圾邮件、IDS、反病毒等。UTM的定位是当中小企业没有精力自己做安全方案时，可以在一定程度上提高安全门槛。但是

UTM并不是万能药，很多问题并不应该在网络层、网关处解决，所以实际使用时效果未必好，它更多的是给用户买个安心。

对于一个复杂的系统来说，纵深防御是构建安全体系的必要选择。

1.7.3　数据与代码分离原则　数据与代码分离原则

另一个重要的安全原则是数据与代码分离原则。这一原则广泛适用于各种由于“注入”而引发安全问题的场景。

实际上，缓冲区溢出，也可以认为是程序违背了这一原则的后果——程序在栈或者堆中，将用户数据当做代码执行，混淆了代码与数据的边界，从而导致安

全问题的发生。

在Web安全中，由“注入”引起的问题比比皆是，如XSS、SQL Injection、CRLF Injection、X-Path Injection等。此类问题均可以根据“数据与代码分离原则”设

计出真正安全的解决方案，因为这个原则抓住了漏洞形成的本质原因。

以XSS为例，它产生的原因是HTML Injection或JavaScript Injection，如果一个页面的代码如下：

<html>

<body>

$var

</body>

</html>

其中$var是用户能够控制的变量，那么对于这段代码来说：

<html>

<body>

</body>

</html>

就是程序的代码执行段。

而

$var

就是程序的用户数据片段。

如果把用户数据片段$var当成代码片段来解释、执行，就会引发安全问题。

比如，当$var的值是：

时，用户数据就被注入到代码片段中。解析这段脚本并执行的过程，是由浏览器来完成的——浏览器将用户数据里的<script>标签当做代码来解释——这显然

不是程序开发者的本意。

根据数据与代码分离原则，在这里应该对用户数据片段$var进行安全处理，可以使用过滤、编码等手段，把可能造成代码混淆的用户数据清理掉，具体到这

个案例中，就是针对<、>等符号做处理。

有的朋友可能会问了：我这里就是要执行一个<script>标签，要弹出一段文字，比如：“你好！”，那怎么办呢？

在这种情况下，数据与代码的情况就发生了变化，根据数据与代码分离原则，我们就应该重写代码片段：

<html>

<body>

alert("$var1");

</script>

</body>

</html>

在这种情况下，<script>标签也变成了代码片段的一部分，用户数据只有$var1能够控制，从而杜绝了安全问题的发生。

1.7.4　不可预测性原则　不可预测性原则

前面介绍的几条原则：Secure By Default，是时刻要牢记的总则；纵深防御，是要更全面、更正确地看待问题；数据与代码分离，是从漏洞成因上看问题；

接下来要讲的“不可预测性”原则，则是从克服攻击方法的角度看问题。

微软的Windows系统用户多年来深受缓冲区溢出之苦，因此微软在Windows的新版本中增加了许多对抗缓冲区溢出等内存攻击的功能。微软无法要求运行在

系统中的软件没有漏洞，因此它采取的做法是让漏洞的攻击方法失效。比如，使用DEP来保证堆栈不可执行，使用ASLR让进程的栈基址随机变化，从而使攻

击程序无法准确地猜测到内存地址，大大提高了攻击的门槛。经过实践检验，证明微软的这个思路确实是有效的——即使无法修复code，但是如果能够使得

攻击的方法无效，那么也可以算是成功的防御。

微软使用的ASLR技术，在较新版本的Linux内核中也支持。在ASLR的控制下，一个程序每次启动时，其进程的栈基址都不相同，具有一定的随机性，对于攻

击者来说，这就是“不可预测性”。

不可预测性（Unpredictable），能有效地对抗基于篡改、伪造的攻击。我们看看如下场景：

假设一个内容管理系统中的文章序号，是按照数字升序排列的，比如id=1000, id=1002,id=1003……

剩余377页未读，继续阅读

danyidanfei

粉丝: 4
资源: 11

《白帽子讲Web安全》：互联网安全深度解析

白帽子讲Web安全

白帽子讲Web安全高清完整PDF版

白帽子讲web安全下载

白帽子讲web安全 电子书

白帽子讲web安全 azw3

白帽子讲web安全 pdf

白帽子讲web安全pdf

适合新手小白的web漏洞书籍

网络安全新手入门学习资料

零基础学习网络安全推荐什么书籍

学习网络安全路线和书籍以及网站

java架构师学习路线

python下载安装.zip

dbForge Studio 2023 for MySQL Enterprise 10.0.150 x64亲测可用

mysql实验111111111

弹性力学数值方法：有限元法(FEM)：三维弹性问题有限元分析.docx

弹性力学数值方法：迭代法：弹性力学中的多网格方法.docx

AutoTorch-0.0.2b20201020-py3-none-any.whl.zip

#-ssm-005-mysql-交通管理局路况查询系统-.zip

opengl实现火焰特效

最新资源

白帽子讲web安全电子书