安全攻防技能30讲 何为舟

原文： 05 访问控制 如何选取一个合适的数据保护方案

访问控制


DAC 自主访问控制

由客体的所有者定义访问控制规则。

  • 灵活
  • 成本低
  • 安全性取决于用户意识

role-BAC 基于角色的访问控制

将主体分为不同角色，对每个角色的权限进行定义。

rule-BAC 基于规则的访问控制

制定某种规则，针对请求本身制定的访问控制策略。

MAC 强制访问控制

基于安全级别标签的访问控制策略。即保证机密性（不能低级别读取高级别的数据，高级别写入低级别的数据）与完整性（高级别读取低级别的数据，低级别写入高级别的数据）。
普通公司一般不会采用mac.

威胁评估

  1. 识别数据

识别数据的最终目的是，当发生攻击，某一份数据的CIA受到影响时，会对公司造成多大的损失。这也是我们衡量安全投入高低的一个主要指标。

  1. 识别攻击
    明确黑客会采取哪些方式进行攻击。
  2. 识别漏洞
    确认可能存在的漏洞。业内将常见的攻击和漏洞进行了总结，比如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

黑客将恶意代码提交到数据库 - 其他用户打开后网站浏览器解析执行恶意代码
常见攻击： 论坛发帖，商品评论，用户私信等

黑客能做什么？

  1. 获取cookie
  2. 未授权操作
  3. 按键记录和钓鱼
  • 获取用户操作
  • 获取用户名和密码

如何进行XSS防护？

  • 验证输入 or 验证输出？
    不确定 内容 输出到哪里，因此验证输入可能导致用户正常提交内容乱码/有误；
    如果确定 内容 输出到哪里，确定内容的类型（电话，邮箱，数字等），可以进行输入过滤；
  1. 预防持久型和反射型XSS
  • 改为纯前端渲染，代码和数据分隔开。
    明确告诉浏览器，那些是文本，哪些是属性，哪些是样式。但 需要避免DOM型XSS漏洞。
  • 对HTML充分转义

不同的上下文，如 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等，所需要的转义规则不一致。
可利用模板引擎，如google提出的Automatic Context-Aware Escaping

  1. 预防DOM型XSS攻击

  2. 其他预防方法

  • CSP 白名单策略
    详见阮一峰Content Security Policy 入门教程
  • 输入内容长度控制
  • HTTP-only Cookie: 禁止JS读取Cookie
  • 验证码： 防止脚本冒充用户提交危险操作
  • X-Xss-Protection header

如何检测是否存在XSS？

  1. 使用通用XSS攻击字符检测
    如 Unleashing an Ultimate XSS Polyglot，
  2. 使用扫描工具自动检测
    Arachni
    w3af

由于美团技术文章第二节前端安全系列（二）如何防止CSRF攻击讲的是CSRF，因此跳过第7章，先看第8章
原文： 08 CSRF SSRF 为什么避免了XSS，还是“被发送”了一条微博

CSRF 跨站请求伪造

攻击

黑客通过J脚本获取你保存在网站的身份信息（cookie），通过仿冒你，让你的浏览器发起伪造的请求。
A CSRF attack works because browser requests automatically include all cookies including session cookies.

由于先通读文章，产生了一个疑问：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

  1. 检查你的框架是否内置CSRF防护机制并且使用它，如果没有的话为所有改变状态的请求添加csrf token并且验证token.
  2. 总是为session级别cookie设置SameSite属性
  3. 使用自定义请求头/验证origin请求头/使用双重cookie认证
  4. 考虑为敏感操作添加用户交互（如验证码，双重密码）
  5. 预防XSS攻击
  6. 不要使用GET请求改变状态的操作

同源检测

  • 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方式

缺点：
前端需要给每一个页面都写入token,无法使用纯静态页面；后端需要对每一个接口都校验，保证页面token和请求token一致。

chrome 80默认samesite属性为Lax
可能值：Strict,Lax,None
Strict: 禁止所有跨站请求。包括正常的外部链接
Lax： 仅支持导航到目标网站的GET请求(链接/预加载请求/GET表单)发送cookie

双重cookie认证

作为请求参数和url参数 向后端 发送随机值，服务器验证通过后则接受请求；
此时子域名可以修改cookie，为了加强安全我们使用加密后的cookie，这样子域名即使知道cookie也没法重写cookie(因为不知道加密密钥).
也可以为cookie添加 __Host- prefix属性，如 Set-Cookie: __Host-token=RANDOM; path=/; Secure
__Host- prefix作用： 子域名无法修改；必须包含path=/;必须标记为Secure;

自定义请求头

默认情况，浏览器不允许js使用自定义请求头的跨站请求。
同时CORS配置应该是强壮的。

扩展阅读

owasp 文档
Cross-Site Request Forgery Prevention Cheat Sheet

安全攻防技能30讲系列文章

安全攻防技能30讲 何为舟 - 笔记(1)

  • 摘要：CIA三元组；安全解决方案；密码学；身份认证；单点登录；JWT;

安全攻防技能30讲 何为舟 - 笔记(2)

  • 摘要：访问控制；XSS攻击了解；CSRF攻击了解；

说明 : 文章基于个人理解进行再整理，每篇原文我都通读两遍以上。

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/Tester_Dolores/p/14336307.html