实习Day37

最新推荐文章于 2022-03-21 12:12:10 发布

Fu-hacker-ture

最新推荐文章于 2022-03-21 12:12:10 发布

阅读量220

点赞数

分类专栏：实习

本文链接：https://blog.csdn.net/gw_csdn/article/details/99659028

版权

实习专栏收录该内容

39 篇文章 0 订阅

订阅专栏

2019.8.15

实习第三十七天

继续写OWASP TOP10 防御思路总结

仔细了解了一下DOM-XSS

校验了两条新签名

⑨ 验证应用程序或框架是否使用强大的随机数（抵御CSRF令牌）或具有其他事务处理保护机制。
⑩ 验证系统能抵御对安全功能、资源或数据的持续访问。例如，考虑使用资源治理器来限制每小时编辑的数量，或阻止整个数据库被单个用户独占。
⑪ 验证应用程序是否具有针对较低价值系统的额外授权（例如，升级或自适应认证）或高价值应用程序的职责隔离，以根据应用程序和过去欺诈的风险执行反欺诈控制。
⑫ 验证应用程序是否正确强制执行了上下文相关的授权，以进制通过参数篡改进行未授权的操作。
-----------------个人防御思路分类总结------------------

A6:2017 – 安全配置错误
安全配置错误是最常见的安全问题，这通常是由于不安全的默认配置、不完整的临时配置、开源云存储、错误的 HTTP 标头配置以及包含敏感信息的详细错误信息所造成的。因此，我们不仅需要对所有的操作系统、框架、库和应用程序进行安全配置，而且必须及时修补和升级它们。

防御思路：
--------------官方文档防御思路总述---------------
应实施安全的安装过程，包括：
》一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且，在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费。
》搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。
》检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分，（参见A9：2017-使用含有已知漏洞的组件）。在检查过程中，应特别注意云存储权限（如：S3桶权限）。
》一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括：分段、容器化和云安全组。
》向客户端发送安全指令，如：安全标头。
》在所有环境中能够进行正确安全配置和设置的自动化过程
--------------官方文档防御思路总述---------------

-----------------个人防御思路分类总结------------------
① 设计一个易于快速部署且可重复的加固过程，所有的开发环境都进行相同的配置，但是使用不同的密码，环境配置应该是自动化的
② 搭建所需要的最小平台，这个平台不包括任何多余的功能，组件，文档等任何其他东西
③ 定期检查，修复安全配置项，及时查看各种安全说明，打上补丁
④ 做好组件，平台与用户的隔离，限制横向移动
-----------------个人防御思路分类总结------------------
A7:2017 – 跨站脚本（XSS）
当应用程序的新网页中包含不受信任的、未经恰当验证或转义的数据时，或者使用可以创建 HTML或 JavaScript 的浏览器 API 更新现有的网页时，就会出现 XSS 缺陷。XSS 让攻击者能够在受害者的浏览器中执行脚本，并劫持用户会话、破坏网站或将用户重定向到恶意站点。

防御思路：
--------------官方文档防御思路总述---------------
防止XSS需要将不可信数据与动态的浏览器内容区分开。这可以
通过如下步骤实现：
》使用设计上就会自动编码来解决XSS问题的框架，如：Ruby 3.0或 React JS。了解每个框架的XSS保护的局限性，并适当地处理未覆盖的用例。
》为了避免反射式或存储式的XSS漏洞，最好的办法是根据HTML输出的上下文（包括：主体、属性、JavaScript、CSS或URL）对所有不可信的HTTP请求数据进行恰当的转义。
》更多关于数据转义技术的信息见：《OWASP Cheat Sheet ‘XSS Prevention’》在客户端修改浏览器文档时，为了避免DOM XSS攻击，最好的选择是实施上下文敏感数据编码。如果这种情况不能避免，可以采用《OWASP Cheat Sheet ‘DOM based XSS Prevention’》描述的类似上下文敏感的转义技术应用于浏览器API。
》使用内容安全策略（CSP）是对抗XSS的深度防御策略。如果不存在可以通过本地文件放置恶意代码的其他漏洞（例如：路径遍历覆盖和允许在网络中传输的易受攻击的库），则该策略是有效的。
--------------官方文档防御思路总述---------------

-----------------个人防御思路分类总结------------------
一般XSS：
① 不要将不可信的数据插入到指定位置之外
不要放在<script>标签内，不要放在HTML注释内，不要放在属性名、标签名内，不要放在CSS中。不要执行任何不可信数据的JS代码。
② 将不可信数据插入HTML元素内容前进行HTML转义
插入到普通标签例如div, p, b, td等等
示例：& 转义为 &
< 转义为<
> 转义为>
" 转义为"
’ 转义为'
/ 转义为/
③ 将不可信数据插入HTML常规属性前将属性进行转义
插入到常见属性如width, name, value等等
除了字母以外，转义所有ASCII值小于256的字符为&#xHH; 形式（或者命名实体形式）来防止值逃逸出属性

④ 将不可信数据插入JavaScript数据值时对JavaScript转义
唯一安全的位置放置不可信数据是被引号包含的“数据值”（参考SQL参数化）

–注意有一些JavaScript函数永远不可能安全的使用不可信数据作为输入-即使JavaScript已经转义！如window.setInterval(‘…即使转义也会存在XSS…’)

–注意HTML解析器在JavaScript解析器前运行，不要二次转义造成“转义逃逸”
除了字母以外，转义所有ASCII值小于256的字符为\xHH的形式来防止数据值进入脚本内容或者其他属性

⑤ 将不可信数据插入HTML样式属性前对CSS进行转义和严格验证

–严格对结构进行验证
–除了字母以外，转义所有ASCII值小于256的字符为\HH形式

⑥ 将不可信数据插入HTML URL参数值前对URL进行转义
–除了字母以外，转义所有ASCII值小于256的字符为%HH形式

–如果不可信的数据是指被放置在href, src或其它基于URL的属性时，需要进行验证确保它不会被指向其它的协议，尤其是JavaScript链接

–只允许白名单内http和https

⑦ 使用专门设计的库来过滤HTML Markup

DOM-XSS：
注：HTML，HTML属性，URL，CSS上下文都视作HTML上下文
rule1: 在执行上下文中将不受信任的数据插入HTML子上下文之前，HTML转义然后JavaScript转义
rule2: 在执行上下文中将不受信任的数据插入HTML属性子上下文之前的JavaScript转义
rule3: 在将不受信任的数据插入执行上下文中的CSS属性子上下文之前的JavaScript转义
rule4: 在执行上下文中将不受信任的数据插入URL属性子上下文之前，URL转义然后JavaScript转义
rule5: 使用安全的JavaScript函数或属性填充DOM
rule6: 修复DOM跨站点脚本漏洞

可以参考OWASP 官方给出的DOM-XSS防御: https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html

其他方式：①使用HTTPOnly ②使用内容安全策略 ③使用Web框架提供的自动转义功能 ④使用X-XSS-Protection响应头

对于输出：
输出编码（与跨站脚本有关）的目的是在用户输入作为数据显示的时候，转换不可信的输入为安全形式，以避免被浏览器当做代码执行。下面的表格列出了阻止跨站脚本的关键输出编码方法。
编码类型编码规则
HTML实体转义转换 & 为 & 转换 < 为 < 转换 > 为 > 转换 ” 为 " 转换 ‘ 为 ' 转换 / 为 /
HTML属性编码除了字母，转换所有字符为&#xHH;形式，包括空格（HH = Hex数值）
URL编码标准的编码请参考http://www.w3schools.com/tags/ref_urlencode.asp。URL编码应该只用于参数部分，而不是整个URL或URL路径部分。
JavaScript编码除了字母，转换所有字符为\uXXXX的unicode转义形式（X=整数）
CSS Hex编码 CSS转义支持\XX和\XXXXXX的形式。如果下一个字符会继续转义序列，那使用两个字符的转义形式可能会出现问题。有两种解决办法（a）在CSS转义后添加一个空格（会被CSS解析器忽略）（b）使用0填充以实现完整的CSS转义格式。

XSS内容部分参考：https://www.freebuf.com/articles/web/156622.html