原文： 05 访问控制 如何选取一个合适的数据保护方案
访问控制
DAC 自主访问控制
由客体的所有者定义访问控制规则。
- 灵活
- 成本低
- 安全性取决于用户意识
role-BAC 基于角色的访问控制
将主体分为不同角色，对每个角色的权限进行定义。
rule-BAC 基于规则的访问控制
制定某种规则，针对请求本身制定的访问控制策略。
MAC 强制访问控制
基于安全级别标签的访问控制策略。即保证机密性（不能低级别读取高级别的数据，高级别写入低级别的数据）与完整性（高级别读取低级别的数据，低级别写入高级别的数据）。
普通公司一般不会采用mac.
威胁评估
- 识别数据
识别数据的最终目的是，当发生攻击，某一份数据的CIA受到影响时，会对公司造成多大的损失。这也是我们衡量安全投入高低的一个主要指标。
- 识别攻击
明确黑客会采取哪些方式进行攻击。 - 识别漏洞
确认可能存在的漏洞。业内将常见的攻击和漏洞进行了总结，比如ATTACK框架。
原文： 06 XSS 当你“被发送”了一条微博，发生了什么
XSS 攻击
推荐阅读：
前端安全系列（一）如何防止XSS攻击
通过给定异常的输入，黑客可以在你的浏览器中插入一段恶意的JS脚本。从而窃取隐私或仿冒你进行操作。
可能的攻击来源：
- 来自用户的UGC信息
- 来自第三方的链接
- URL参数
- POST参数
- Referer(不可信来源)
- Cookie（其他子域）
类型 存储区(恶意代码存放位置) 插入点 存储型 XSS 后端数据库 HTML 反射型 XSS URL HTML DOM 型 XSS 后端数据库/前端存储/URL 前端 JavaScript
反射型XSS
黑客构造URL - 用户打开后浏览器响应执行 - 后端取出恶意代码并执行返回给浏览器 - 浏览器执行恶意代码
基于DOM的XSS
黑客构造URL - 用户打开后浏览器响应执行 - 前端JS取出恶意代码并执行
持久型XSS
黑客将恶意代码提交到数据库 - 其他用户打开后网站浏览器解析执行恶意代码
常见攻击： 论坛发帖，商品评论，用户私信等
黑客能做什么？
- 获取cookie
- 未授权操作
- 按键记录和钓鱼
- 获取用户操作
- 获取用户名和密码
如何进行XSS防护？
- 验证输入 or 验证输出？
不确定 内容 输出到哪里，因此验证输入可能导致用户正常提交内容乱码/有误；
如果确定 内容 输出到哪里，确定内容的类型（电话，邮箱，数字等），可以进行输入过滤；
- 预防持久型和反射型XSS
- 改为纯前端渲染，代码和数据分隔开。
明确告诉浏览器，那些是文本，哪些是属性，哪些是样式。但 需要避免DOM型XSS漏洞。 - 对HTML充分转义
不同的上下文，如 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等，所需要的转义规则不一致。
可利用模板引擎，如google提出的Automatic Context-Aware Escaping
-
预防DOM型XSS攻击
-
其他预防方法
- CSP 白名单策略
详见阮一峰Content Security Policy 入门教程 - 输入内容长度控制
- HTTP-only Cookie: 禁止JS读取Cookie
- 验证码： 防止脚本冒充用户提交危险操作
- X-Xss-Protection header
如何检测是否存在XSS？
- 使用通用XSS攻击字符检测
如 Unleashing an Ultimate XSS Polyglot， - 使用扫描工具自动检测
Arachni
w3af
由于美团技术文章第二节前端安全系列（二）如何防止CSRF攻击讲的是CSRF，因此跳过第7章，先看第8章
原文： 08 CSRF SSRF 为什么避免了XSS，还是“被发送”了一条微博
CSRF 跨站请求伪造
攻击
黑客通过J脚本获取你保存在网站的身份信息（cookie），通过仿冒你，让你的浏览器发起伪造的请求。
由于先通读文章，产生了一个疑问：XSS和CSRF有什么区别？
事实证明，我并没有认真阅读文章....引用原文：
和XSS一样，CSRF也可以仿冒用户去进行一些功能操作的请求，比如修改密码、转账等等，相当于绕过身份认证，进行未授权的操作。
值得一提的是，尽管黑客通过CSRF能进行的操作没有XSS丰富，但CSRF在传播和攻击成本上都低于XSS。这也就是说，即使你的网页中没有任何注入漏洞，但只要接口配置不当，就能够被CSRF利用。而黑客也只需要在自己的域名中，搭建一个诱导性的网页，就可以让任何访问网页的用户都遭受到CSRF攻击。而且，用户每天需要访问大量的网页，根本没有办法确认每一个网页的合法性。而从严格意义上来说，用户根本没有办法防止CSRF攻击。因此，我们只能从应用本身入手去加强防护。
GET类型的CSRF
在这里我们可以看下这篇文章里的例子：让我们来谈谈CSRF
删除文章使用GET请求： https://small-min.blog.com/delete?id=3
于是，黑客可以通过诱导用户点击如下链接 删除用户的文章：
- 使用跳转，用户可以感知
<a href='https://small-min.blog.com/delete?id=3'>開始測驗</a> - 使用图片自发请求，用户无法感知
<img src='https://small-min.blog.com/delete?id=3' width='0' height='0' />
<a href='/test'>開始測驗</a>
POST类型的CSRF
在这里我们同样可以看下这篇文章里的例子：让我们来谈谈CSRF
使用form标签提交表单（e...实在不太熟浏览器对html标签的响应...试验了一下...）
- 点击“提交测验”提交表单后会发生跳转
<form action="https://small-min.blog.com/delete" method="POST">
<input type="hidden" name="id" value="3"/>
<input type="submit" value="開始測驗"/>
</form>
- 无需点击，自动提交表单，且不发生跳转
<iframe style="display:none" name="csrf-frame"></iframe>
<form method='POST' action='https://small-min.blog.com/delete' target="csrf-frame" id="csrf-form">
<input type='hidden' name='id' value='3'>
<input type='submit' value='submit'>
</form>
<script>document.getElementById("csrf-form").submit()</script>
链接类型的CSRF
需要用户点击链接才会触发，通常为论坛发布的图片嵌入恶意链接或广告。
<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">
重磅消息！！
<a/>
可能的攻击来源
- 第三方网站
- 图片URL,超链接，CORS,Form提交
又又又出现一个新名词：CORS 扩展阅读：CORS & CSRF
简单说就是CSRF是违法的跨域请求，CORS是允许合法的跨域请求，且CORS定义了简单请求和非简单请求，简单请求可以理解为白名单（白名单外的都是非简单请求）。 - 第三方论坛，文章
如何防御CSRF
同源检测
- Origin Header(IE11 没有，302重定向也没有)
- Referer Header(缺点： 在某些情况下攻击者可以隐藏/修改Referer header)
没有Rederer的情况：
IE6、7下使用window.location.href=url进行界面的跳转，会丢失Referer。
IE6、7下使用window.open，也会缺失Referer。
HTTPS页面跳转到HTTP页面，所有浏览器Referer都丢失。
点击Flash上到达另外一个网站的时候，Referer的情况就比较杂乱，不太可信。
直接阻止未知不可信的第三方域名？ -- 不可行，来源搜索引擎的链接会被误认为CSRF攻击
CSRF Token
客户端： token不能存在cookie,一般存在 session storage.
分布式集群csrf token 一般存在redis之类公共存储空间，采用[Encrypted Token Pattern]（https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html）方式
说明 : 文章基于个人理解进行再整理，每篇原文我都通读两遍以上。