读书笔记之 WEB之困-现代WEB应用安全指南

最新推荐文章于 2023-04-25 15:14:26 发布

Hyo_yew

最新推荐文章于 2023-04-25 15:14:26 发布

阅读量1k

点赞数

分类专栏：读书笔记

本文链接：https://blog.csdn.net/Hyo555/article/details/80504746

版权

读书笔记专栏收录该内容

2 篇文章 0 订阅

订阅专栏

前言

最近信息安全课结束了，考核内容是写一份课程报告，任课老师为了拓展我们的视野，让模仿（或者说拜读研究后压缩）一篇硕士或博士论文的报告（题目任选，科因目相关就好），我选了WEB应用安全评测相关的题目，因为这个有机会拜读了两本有关web安全评测方面的书，看完后决定将书中的一些实用观点与技术记录下来，以备查用。

作者的引言和对web安全的思考与介绍

Web安全的定义从未被明确过，学界至今仍未给出明确的标准。

风险管理：

由于缺乏正式的保障，也没有什么证明可用的方法，而商业社会极度依赖的关键性软件又让人心惊肉跳的存在着大量的安全问题，所以业界开始争先恐后地引入了一个抓人眼球的概念：风险管理----- 风险=出现问题的可能性*最大损失

根据所谓风险管理的精神，主要投资应该花在运行关键性任务的主要设备上，进行隔离，加固和监控，根据目标安排优先级自是理所当然的，但是：

1. 在互联网的系统里，损失是没有上限的，范围也不会只固定在单个设备上。

2. 现有的数据对日后的风险也许完全没有意义

3. 基于统计数据的预测对独立事件来说并不靠谱。

两种学界的研究思路

由分类学角度得到启发研究者认为可以把安全分解成若干可计算的目标以此得到一套统一的安全体系理论或者一套能接受的风险管理模型。

偏向自然科学研究的角度的研究者通过收集足够多的实验数据进行底层抽象，不断观察，重组，和记录，以期得到安全运算的统一模型。

两种方式都得到了支持：

由美国国土安全局支持饿CWE（常见漏洞列表）项目，目标是创建一套漏洞理论，但是这套体系的漏洞分类复杂的令人眼花缭乱

由商业机构支持的CVSS项目，目标是用一套只有机器能读懂的基本参数，精确量化已知的安全问题，具体是：通过14项评估因子，根据不同的用例场景，严谨的对潜在的漏洞的重要程度打分，得到一个数字分值，可以完全无需主观因素来判断安全漏洞的严重程度

作者对这两个项目表示了嘲笑和实用性方面很大的怀疑

作者认为唯一还算管用法子是那些老方法：

1. 从失败（最好是别人的失败）中学习

2. 开发一些工具来检查和纠正问题---创建各种安全质量保障工具来验证程序的实现是否正确

3. 先做最坏的打算

引入恰当的组件隔离，访问控制，数据冗余，监控和响应流程，使服务的人员可以在事件还未从小事故演变成大灾难前做出及时的响应。

然后作者嘲讽了业界各种包装的抓人眼球的闪亮词语，鄙视了那些不过是把安全业界叫人无比沮丧的失败涂脂抹粉的各种方法学

。。。。

作者认为无论如何，信息安全人员需要具备足够的耐心，创造力和深厚的技术积累。学会安全的使用相关工具，理解Web容易被误解的地方，学会在出问题时控制连带的损失更重要。

web历史渊源

Http和HTML的低门槛使web迅速流行

浏览器大战：微软和NetScape，导致浏览器标准混乱

W3C标准建设逐渐跟上

2004年后Web2.0和第二次浏览器大战，FireFox，Safari,和Opera浏览器

作者总结的Web领域里一些最具影响力的风险要素有：

1. 用户作为安全风险的一个环节

事实上，只有对计算机技术和公开秘钥体系这样的术语相当了解的人，才有可能安全的使用浏览器，但是web的使用门槛很低，绝大多数用户是电脑小白。

2. 难以隔离的Web运行环境

传统电脑中应用的隔离做的很好，但在浏览器的世界里，文档和代码交织在同一个HTML 文件里，完全无关的应用之间最多只能算部分隔离，实际上所有网站使用的是同一个javascript运行环境

3. 缺乏统一的格局

在浏览器领域里，“同源策略机制”可以说是核心安全范式了，但是像这样的许多零零碎碎的调整，都无法担起浏览器安全的大任。

4. 跨浏览器交互：失败的协同

5. 客户端和服务端界限的日益模糊

First 基本介绍

下面是web浏览器的基本组成部分面临的安全问题，以及作者给出的防范策略

URL

1. 解析的标准不一样，导致不同厂商的浏览器可能无法兼容

出现了本地化域名即IDNA标准，但是引发了假冒域名和阻碍国际化域名的应用

2. 相对URL的解析

大众容易认为相对链接只能指向同一个服务器上的资源，但实际上，有很容易混淆的URL变型是可以被利用的

譬如：

有协议名称，但没有授权信息

没有协议名称，但有授权信息

没有协议名称，没有授权信息，但有路径

没有协议名，没有授权信息，没有路径，但有查询字符串

只有片段ID

HTTP协议

超文本传输协议，是Web的核心传输机制，也是服务器与客户端之间交换URL引用文档的首选方式。

HTTP请求里可以包含Referer（来源)头域。这个头域里包含的是哪个URL地址触发了对当前页面的访问。Referer头域对某些纠错处理颇有帮助，还可以通过这个头域，强化网页之间的引用关系，有助于Web的发展壮大。

这个头域经常在安全控制或策略强制时被错误使用，但实际上它承担不了这种重任。主要是因为我们没办法主动区分以下几种缺乏Referer头域的情况：

客户端根据用户的隐私策略设置，直接就没有发出这个头域；用户的浏览行为确实没有涉及这个头域；该请求的来源是恶意站点，它刻意屏蔽了这项信息。

正常来说，这个头域在大部分HTTP请求里都会出现（在HTtP级别的跳转里也会保

留下来），但以下情况除外：

口刻意在地址栏里直接输入一个新的URL或从书签里打开网页
口浏览的动作是由一个伪URL文档，如data:或javascript；触发的
口当前请求来自Refresh.响应头（并非基于Location的重定向方式））m
口当来源站点是加密站点面请求的是非加密页面时。根据RFC2616的15.1.2节规定，这是出于隐私保护的考虑，但这样做其实没太大意义。当用户从加密的域名浏览到另一个无关的加密网站时，Referer信息还是会泄漏给第三方，所以加密也并不等于安全啊。
口用户可以通过调整浏览器设置或安装隐私保护插件，选择不发送或干脆伪造一个来源页面。

很明显，以上5种情况里有4种情况都可能是恶意站点蓄意诱发的。