安全世界观
讲安全，需要关注攻击的技术原理，也需要关注防御的思路和实现的技术。
安全是什么？什么情况下才会产生安全问题？如何看待安全问题？这些是安全的基本问题，需要搞清楚，才能明白一切防御技术的出发点。这也是一个道跟术的问题。
安全的本质是信任问题。安全方案的设计是建立在信任关系上，比如说要保管重要的文件，我们可以把它锁在抽屉里物理的一把锁，要保证锁的 工匠，品牌是值得信任的，没有私自保留额外的钥匙，没有给锁留后门。且锁的钥匙也要在一个不会出问题的地方，或者钥匙交给值得信任的人来保管。如果工匠，品牌不可信任或者钥匙的保管不够安全。我们的决策依据被打破，安全的前提就不再存在。
安全是一个持续的过程，不能一劳永逸地解决安全问题。任何一种防御技术都不可能永远有效。防御技术在不断的发展，攻击的技术也在动态的发展，二者是相互促进的辩证关系。黑客在不断地研究寻找新的攻击技术，作为防御这也需要不断地跟进，增加对于新的攻击方式的检测与防御方案。
设计安全方案
安全三要素(作为设计安全方案的出发点)
- 机密性。保护数据不能泄露。常见的手段是加密。比如放在加了锁的抽屉里。
- 完整性。保护数据内容完整，没有被篡改。常见的技术手段是数字签名，比如 github 可以对每个 commit 进行签名。
- 可用性。保护资源在需要的时候都能获得。 典型的破获可用性的例子是 DDOS，服务端拒绝攻击，把可用的端口都占满了，导致无法再提供服务。
安全评估
-
目标是什么，要保护什么
-
核心问题是数据安全问题。根据业务内容不同，划分的侧重点也不同，有的公司关心员工的资料信息，有的公司关注客户数据，设计安全方案，需要了解最重要的数据是什么，以及不同数据的重要程度。
最简单的划分信任域和信任边界，从网络逻辑上进行划分。
威胁分析
要把所有的威胁都找出来，一般比较难找，可以采取头脑风暴的形式。也可以采用比较科学的方法，比如使用一个模型帮助我们去想到底有哪些方面可能存在威胁。
微软提出的威胁建模的方法，我们可以从六个方面去考虑。当然可能存在的威胁有很多，一个威胁到底能造成多大的危害，该怎么衡量，则需要进行风险分析。
风险 = 发生的可能性 * 破坏潜力（造成的损失大小）
可以根据风险衡量模型来计算一个威胁的具体风险大小。
白帽子兵法（防御思路）
-
黑名单，白名单原则
白名单比黑名单安全。但白名单也不是一定安全的。基于白名单的安全方案，也是信任白名单是好的，是安全的，若信任基础不存在，也就谈不上安全。比如浏览器在加载跨域资源的时候，设计的跨域资源共享机制就是通过白名单的思想。设置允许访问的域，允许的请求方法等。
-
最小权限原则。
只授予必要的权限，而不要过度授权，可以有效减少出错的机会。比如在 Linux 系统中，比较好的操作习惯是用 普通用户操作，只在必要的时候使用 sudo 命令而不是一开始就使用 root 账户，可以最大化降低误操作的风险，在账户被盗用时，造成的影响也会比较低。
-
纵深防御原则
需要全面防御。在不同的层面，不同的角度对系统做整体的解决方案，将风险分散到系统的各个方面。
-
数据与代码分离的原则。广泛适用于各种由于注入引发的安全问题，原因是混淆了数据与代码的边界。
-
不可预测性原则，攻击方式具有不可预测性。通常利用加密算法，随机数算法等来实现这一条原则。比如防御 CSRF 的时候，通常使用 token 的方式。是因为 token 是足够复杂而且是随机的，无法提前预知。
浏览器安全
-
浏览器具有同源策略。 ----浏览器的安全功能最核心一点。 CORS
限制跨域的资源，跨域的脚本。跨域：协议，域名，端口。
CORS 机制（Cross Origin Resource Sharing） 浏览器控制允许访问的资源，通过 HTTP 头来实现。这个跨域访问方案的安全基础是信任“JavaScript 无法控制相应的 http 头”，而只是来自目标域设置的。
-
其他机制：
浏览器沙箱，以及现代浏览器的多进程架构。浏览器进程，渲染进程，插件进程，扩展进程等。将浏览器的各个功能模块分隔开，各个 tab 页也分隔开，这样其中一个进程崩溃时也不会影响其他的进程。
恶意网址拦截。比如钓鱼网站，挂马网站，有专门提供恶意网址的组织。
-
XSS
跨站脚本攻击。通常指通过 HTML 注入 篡改网页，插入恶意的脚本，从而控制浏览器的行为。破坏力强大，场景复杂。
- 反射型 用户输入的脚本反射给浏览器，非持久型的 XSS。
- 存储型 顾名思义，把用户输入的数据存储在服务器端，XSS 具有很强的稳定性，持久性 XSS。
- DOM based XSS 属于反射型 XSS 的特例，修改页面 DOM 节点形成的 XSS。
-
CSRF
浏览器在用户不知情的情况下进行恶意操作。
防御：
-
验证码是最简洁有效的。但一定程度上牺牲了用户体验。
-
token 根据不可预测性的原则。token 的生成要足够随机的安全函数生成。
-
Referrer Check 。检查源是否合法。缺陷在于服务点并不是在所有时候都可以获取到 Referrer。
-
点击劫持
视觉上的欺骗手段。 透明的或者不可见的 iframe 覆盖。用户在不知情的情况下点击透明的 iframe。
防御：
- 禁止 iframe 。iframe 安全性无法保证。
-
HTML5 安全
-
SQL 注入攻击
服务器安全
注入攻击
- sql 注入
- XML 注入等
文件上传漏洞
用户上传了可执行脚本，并通过此脚本获得了执行服务器命令的能力。
比如 上传了 web 脚本或者上传了 钓鱼图片，或者图片上包含脚本等
防御：
- 文件上传目录设置为不可执行。
- 判断文件类型（MIME Type 和后缀检查），推荐使用白名单的方式放行
- 单独设置文件服务器的域名
认证与会话管理
认证 & 授权 认证是识别用户是谁，授权是为了决定用户能够有执行哪些操作
认证
- 认证 - 实际就是验证凭证的过程。通过凭证数量可以分为单因素认证以及多因素认证。使用多因素认证可以提高攻击的门槛。
session
-
用户登录之后，服务端创建的会话，保存用户的状态和相关信息。
-
产生 session 保持攻击等问题。
- 利用服务端对于活动的 session 不销毁的特点。攻击者不停发起访问请求，让这个 session 一直存货，成为永久的后门。
访问控制
垂直权限管理，用户与权限之间的对应关系。 常常使用的 RBAC 基于角色的访问控制。比如 linux 文件系统中的权限管理，针对不同的角色分别设置不用的读写权限。
水平权限管理，基于数据的访问控制，需要控制数据是否属于当前用户
加密算法与随机数
在系统中对数据进行加密的加密算法和随机数算法的安全性和健壮性关乎整个系统的安全性。
DDOS 分布式拒绝服务
本质是利用合理的请求造成资源 过载，导致服务不可用。
网络层 DDOS
- 利用 TCP/IP 协议的特征，大量发包。
- 有 SYN flood ,UDP flood, ICMP flood 等。
- 易于拦截，价值不大。
应用层 DDOS
-
大量高频的合法请求，一般是通过代理服务器或者僵尸网络发送，也达到了快速消耗目标主机资源，造成网络堵塞，服务不可用的问题。
-
DNS flood,HTTP 慢连接攻击，CC 攻击等
-
请求合法，很难识别和过滤
防御：
- 常见的对抗手段：限制每个 IP 的请求频率。
web 服务器安全
应用部署时的运行环境安全。主要关注自身是否安全，以及是否提供了可使用的安全功能。
安全开发流程
- SDL Security Development Lifecycle
瀑布流开发模型中的安全开发生命周期。但国内的公司一般采用敏捷开发，快速迭代出产品的模式，这套 SDL 模型则显得有些厚重。按照产品的开发周期，分别介绍常用的 SDL 实施方法。
需求分析与设计阶段
-
在需求分析阶段，需要了解产品的背景以及需要应对的场景，才能给出相应的建议。
-
需要了解项目中是否包含一些第三方软件，评估第三方软件的安全问题，很多时候入侵是从第三方软件开始的。
开发阶段
- 安全是为业务服务。
- 力求实现代码上的安全，分析可能出现的漏洞，并在代码上提供可行的解决方案。
- 采用代码安全审计工具，将代码审计工作前置，放入代码开发规范中从而减少问题。
测试阶段
-
安全测试。独立于代码审计，对于逻辑相对复杂的代码，难以通过代码审计发现。
-
自动化测试和手动测试。
自动化测试工具，覆盖性的测试，对项目或产品进行漏洞扫描。
手动测试。部分设计系统或业务的逻辑无法通过自动化测试完成。以及自动化测试的结果也需要再次确认，因为自动化测试可能存在误报或漏报的问题。
-