读软件开发安全之道：概念、设计与实施06模式（下） ...

1. 强力执行

1.1. 强力执行组的模式关注的重点是怎样通过彻底逼迫执行规则的方式来限制代码的行为
1.2. 毛病是任何法律法规的毒药，强力执行组的模式就展示了怎样避免给粉碎系统创造机会
1.3. 我们应该在结构上举行设计，让那些错误的利用根本不可能发生
1.4. 完全仲裁原则

• 1.4.1. 保护全部访问路径，逼迫执行相同的访问，没有任何例外
  
• 1.4.2. 所谓完全仲裁原则，即对受保护资源的访问执行同等的安全检查
  
• 1.4.3. 防守点
  
• 1.4.3.1. 瓶颈(bottleneck)
  
• 1.4.3.2. 要包管对各类访问执行的全部校验都必须在功能上保持同等
  
• 1.4.4. 差别的级别
  
• 1.4.4.1. 高合规性：只能通过一种公共的方式访问资源（瓶颈防守点）​
  
• 1.4.4.2. 中合规性：可以在差别位置对资源发起访问，但每个位置都利用相同的授权校验举行保护（多个公共防守点）​
  
• 1.4.4.3. 低合规性：可以在差别位置对资源发起访问，这些位置分别利用差别的授权校验举行保护（不符合完全仲裁原则）​
  
• 1.4.5. 不要提供多种路径来访问相同的资源，又给每种路径定义专门的代码，且每组代码工作方式又不尽相同
  
• 1.4.5.1. 任何差异都有可能意味着一部分路径的保护措施比另一部分的弱
  
• 1.4.6. 利用多个防守点就会给堕落制造更多的机会，也必要我们付出更大的努力才能举行比力彻底的测试
  

1.5. 最少共同机制

• 1.5.1. least common
  
• 1.5.2. 独立历程之间的共享机制越少越好，这样才能保持这些历程之间相互隔离
  
• 1.5.3. 桥接(bridge)是指泄露信息，大概让一个历程在未经授权的情况下影响其他历程
  
• 1.5.4. 在设计服务时，应该让它们与各个独立历程或用户举行交互，这就是实现最少共同机制模式的方法
  

2. 冗余

2.1. 冗余是工程安全的核心策略，这个策略可以反映在大量日常行为当中

• 2.1.1. 汽车有备胎
  

2.2. 深度防御

• 2.2.1. 把大量独立的保护措施组合在一起，就可以形成强大的总体防御措施，这种总体防御措施可以协同发挥作用，其效果远比其中任何一项措施都更加有力
  
• 2.2.2. 鉴于软件系统不可避免地包含大量错误，这个措施可以让我们的软件系统比系统的组件更加安全
  
• 2.2.3. 叠加两层大概多层保护机制来实施特别紧张的安全策略，这就是实现深度防御的方式
  
• 2.2.4. 沙盒
  
• 2.2.4.1. 所谓沙盒是指任何一个让不可靠的代码可以安全运行的容器
  
• 2.2.4.2. 当今的网页浏览器会在安全沙盒中运行WebAssembly
  
• 2.2.4.3. 相同的缺陷同时存在于这两层的可能性很低，如果它们是分别独立开发的，那么可能性就更低了
  
• 2.2.4.4. 纵然有百万分之一的概率，分析器没有检测出某种攻击方式，同时它也能够欺骗解释器，但一旦这两种机制联合起来，整个系统发生故障的概率就可以低落到十亿分之一以下，这就是这种模式的强大之处
  

2.3. 权限分离

• 2.3.1. 两方总比一方可靠
  
• 2.3.2. 权限分离也称为责任分离(separation of duty)
  
• 2.3.2.1. 如果我们上两把锁，同时把两把钥匙委托给两个差别的人，这样做的安全性比只上一把锁要强
  
• 2.3.3. 如果一项受保护资源存在明显相互重叠的职责，就应该采用这种模式
  
• 2.3.4. 在大型企业中，差别的团队可能会负责数据中心内部的差别数据集，这也是为了举行更大程度的责任分离
  
• 2.3.5. 把一项责任分别成多个职能，避免任何人无意或蓄意给系统造成严峻结果
  
• 2.3.5.1. 为了防止备份数据泄露，我们可以由差别团队用各自的密钥对数据举行两次加密，这样只有两个团队的人员同时提供密钥，人们才能解密备份的数据
  
• 2.3.5.2. 在激活核武器这类极度情况下，则必要两把钥匙同时转动且钥匙孔相互距离3米以上，这种设计的目的是防止任何一个人独立激活核武器
  
• 2.3.6. 审计日志也可以通过权限分离的方法举行保护，由一个团队负责记录和查看事故，同时让另一个团队发起事故
  
• 2.3.6.1. 管理员负责审计用户的行为
  
• 2.3.6.2. 一个独立的团队负责对管理员举行审计
  
• 2.3.6.3. 犯罪人员可能会克制记录他们自己的腐败行为，大概篡改审计日志来掩饰他们的踪迹
  
• 2.3.7. 我们不可能在一台盘算机中实现权限分离，因为拥有超级用户权限的管理员永远可以完全控制这台盘算机
  
• 2.3.7.1. 如果盼望针对管理员执行强大的权限分离，就必要要求管理员通过特殊的ssh网关举行工作，让他们的工作处于独立的控制之下，他们的会话也会被详细地记录下来，同时还可以针对管理员实施其他限制
  
• 2.3.8. 内部人员给系统带来的威胁很难消除，偶然甚至根本不可能消除，但是这并不代表采取缓解措施是在浪费时间
  
• 2.3.8.1. 哪怕让内部人员知道，有人正看着他们，这本身也是一种强大的震慑
  
• 2.3.8.2. 诚信的员工肯定会接待任何权限分离的措施，因为这样可以增强对系统的审计，还可以低落因为他们的错误利用给系统带来的风险
  
• 2.3.8.3. 在逼迫内部的恶意人员把注意力放在掩饰自己的踪迹上，这样他们发起攻击的服从也会有所低落，同时还可以增大抓现行的概率
  

3. 信任与责任

3.1. 信任和责任是合作的黏合剂

• 3.1.1. 软件系统之间的互联越来越多，相互之间的依赖也越来越强，所以这组模式都是紧张的路标
  

3.2. 不盲目信任

• 3.2.1. 信任永远都应该是明确的选择，而且应该有确凿的证据
  
• 3.2.2. 不盲目信任模式确认了一点，那就是信任是非常宝贵的，这也是为什么我们应该保持怀疑态度的原因
  
• 3.2.3. 不盲目信任模式是在告诉我们，不要默认穿着制服的人就拥有合法的身份，要想到电话里谁人自称是警察的人很可能是个骗子
  
• 3.2.4. 在软件领域，这种模式适用于在安装软件之前首先校验代码的真实性，这必要在授权之前首先执行强有力的认证
  
• 3.2.5. 鉴于客户端没有任何任务按照服务器的规则来发出请求，所以服务器永远应该对cookie这种手段持保留态度，不要太相信客户端会老实地执行这项任务，否则会带来巨大的风险
  
• 3.2.6. 纵然没有恶意，我们也不应该盲目信任
  
• 3.2.6.1. 在一个紧张的系统中，我们务必要包管全部组件都保持高质量、高安全性的水准，这样整个系统才不会轻易被入侵
  
• 3.2.6.2. 如果信任了不该信任的人，利用了匿名开发人员提供的代码（代码中可能会包含恶意软件，大概代码中包含很多错误）​，那么系统中的紧张功能可能立刻就会面对安全风险
  

3.3. 接受安全责任

• 3.3.1. 全部软件从业者都有明确的责任，他们都必要对软件的安全负责
  
• 3.3.2. 在协议里面把权责写清楚，界定由谁对请求举行验证，以及如果系统会为下游提供保障的话，它会提供什么样的保障
  
• 3.3.3. 如果盼望系统尽可能安全，就应该采用深度防御模式，让两个组件独立对输入的内容举行验证
  
• 3.3.4. 不要因为“说不定哪天就会有人用到”就给用户提供一种利用的可选项
  
• 3.3.5. 如果需求本身就是不安全的，那么设计人员就应该明确告知用户这个需求存在的风险，并且对用户提供保护，防止他们在不知道结果的情况下配置了这个可选项
  
• 3.3.5.1. 不仅是我们应该把风险记录下来，同时提供各种可能的缓解措施来补充毛病，用户也应该接收到明确的反馈信息
  
• 3.3.6. 在理想情况下，我们最好不要用“你确定吗？​”大概“了解更多信息，详见下列链接”这样的对话框，这是在推卸责任
  
• 3.3.6.1. 在理想情况下，我们应该把责任留给那些完全了解自己所作所为结果的专业管理员，这类选项应该留给这种专业人士举行决议
  

4. 反模式

4.1. 要懂得从别人的灾祸中吸取教训
4.2. 最好的方法是观察大家们是怎样工作的
4.3. 避免犯其他人犯过的错误
4.4. 代理混淆题目

• 4.4.1. 代理混淆题目是很多软件毛病的基本安全挑战
  
• 4.4.2. 代理混淆的常见情况包罗用户代码调用内核，大概用户通过互联网访问Web服务器
  
• 4.4.3. 包罗缓冲区溢出、输入验证不足、跨站请求伪造(Cross-Site Request Forgery，CSRF)攻击等
  
• 4.4.4. 意图与恶意
  
• 4.4.4.1. 开发软件的人员必须是我们信任的人，这个人必须既诚信又有能力提供高质量的产物
  
• 4.4.4.2. 两个条件之间的区别就在于意图
  
• 4.4.5. 可信的代理
  
• 4.4.5.1. 信任界限就是最开始发生混淆的地方，因为混淆代理攻击的目的就是利用更高的权限
  
• 4.4.6. 代理混淆的另一种办理情势基于代表请求所采取的行动
  
• 4.4.6.1. 数据隐藏(data hiding)是一种基本的设计模式
  
• 4.4.7. 在信任界限，我们肯定要谨慎地处置惩罚低可靠性的数据和低权限的调用，不要让它们最终发展成混淆代理攻击
  

4.5. 信任回流

• 4.5.1. 只要低可靠性的组件控制了高可靠性的组件，就会出现信任回流的情况
  
• 4.5.2. 最紧张的不是你对组件有多么信任，而是这些组件有多么值得你去信任
  
• 4.5.3. 威胁建模可以通过明确查看信任界限来揭示这类潜在题目
  

4.6. 第三方Hook

• 4.6.1. 另一种情势的信任回流反模式是系统组件中的Hook为第三方提供了不正当的访问
  
• 4.6.2. 如果Hook实现了自动更新机制，它只能下载和安装新版本的软件，那么只要它的信任级别达到了这个水准，利用它就不会有太大的题目
  

4.7. 组件不可修补

• 4.7.1. 对于任何流行的组件，从来都不存在人们会不会发现其中毛病的题目，而是人们什么时候会发现毛病
  
• 4.7.2. 一旦人们都知道了它的毛病，除非它与全部攻击面都彻底断开，否则我们必须给它打上补丁
  
• 4.7.3. 系统中任何不能打补丁的组件最终都会成为这个系统永远的痛
  
• 4.7.4. 主流的利用系统提供商一般都会为自己的产物提供一段时期的支持和升级，接下来它们就不会再给自己的产物发布补丁了
  
• 4.7.5. 如果软件开发商不能及时地发布更新，那么纵然这类软件可以更新，恐怕也好不到哪里去
  
• 4.7.5.1. 如果你自己都没有把握能及时得到更新，就最好不要去碰运气
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。