OWASP安全测试指南解读 – 作者:nobodyshome-安全小百科

OWASP 测试项目简介

OWASP 测试项目已经发展了许多年。通过这个项目，我们希望帮助人们了解自己的 Web 应用程序，什么是测试，为什么要测试，什么时间，在哪里以及如何测试 WEB 应用程序。这个项目是发布一个完整的测试框架，而不是仅仅提供一个简单的漏洞检查列表或者问题的简单药方。人们可以根据需要建立自己的或符合其它进程的测试程序。测试指南详细的介绍了一般测试框架以及实践中该框架的实施技术。

创作这份测试指南是一项艰巨的任务。要获取大家的一致认可同时发展内容是一个极具挑战的任务。这不仅需要使人们接受这里所描述的概念，同时使他们能够真正将这些概念应用于自己的环境和文化中。同时，这也是对将目前 Web 应用测试重点，将渗透测试转变为测试集成于软件开发生命周期过程中的挑战。

然而，我们已经达到非常满意的结果。许多业内专家和世界上一些大型公司的软件安全负责人共同验证了这个测试框架。这个测试框架帮助各类组织能够有效针对 Web 应用程序进行测试以便建立安全可靠软件，而不是简单地强调脆弱点。虽然后者无疑是许多 OWASP 指南和清单的一个副产品。因此，对于某些测试方法和技术，我们作出了艰难的选择，因为我们都明白并这些方法和技术并不是适用于每一个人。然而，随着时间的推移，OWASP 能够在丰富的经验和协商一致的基础上通过宣传和教育达到更高的层次并进行文化变革。[2]

OWASP 安全测试指南 v4.0 简介

首先我想说的是学习没有捷径，只有花心思和时间去积累，才会有收获。

这本书讲了什么

这本书结构化的介绍了该如何执行 Web 渗透测试，描述了 Web 渗透测试的方法论。

如果你去面试渗透岗位，或者领导让你去执行某个站点的渗透测试，那么这么书可以很好的指导你。全面掌握本书后，你能很清楚自己在做什么，该怎么做，成果该怎么展示，结论该怎么写。

谁适合读这本书

零基础

如果你对 Web 安全是零基础，那我不推荐你一开始就精读本书，虽然本书内容中对漏洞有解释和描述，但毕竟篇幅有限，无法以生动，更易理解的方式解释漏洞。在这种情况下，你看这本书会很迷惑，通篇读过后，却不知道文章讲了什么。

建议你可以泛读本书，了解有哪些漏洞类型，有不懂的，或者感兴趣的漏洞，再去找其他文章看看，理解了以后再回来精读本书。

有基础，但不系统

如果你已经有了一些基础，那这本书非常适合你，很多人可能很不屑，觉得自己经验丰富，SQL 注入信手拈来，但是有个毛病就是容易漏测，同样一个系统这次漏洞 1，2，3，下次漏洞 2，3，4 好像每次测试都有新漏洞发现。

为什么会出现漏测的现象呢？很简单，要么就是定义的测试范围不一样，导致每次发现的漏洞是不一样的。要么是不知道该怎么系统性，结构化的测试，完全凭借头脑的灵感。这两种漏测是完全不一样的，可以说第一种情况并不是漏测，因为测试范围导致漏洞不一样是可以解释的。第二种就是典型的漏测，而且很危险。换句话说，第二种情况你提交给甲方的报告是零漏洞，甲方会认为自己的产品真的很安全吗？还是会认为这个渗透测试人员不靠谱？

借用大佬 Gary McGraw 的一句话来说

“If you fail a penetration test you know you have a very bad problem indeed. If you pass a penetration test you do not know that you don’t have a very bad problem”.

本书的重点就是这一类的人

有基础，成系统

如果你已经在这个阶段，至少已经是高级渗透测试人员了，那么本书说不定可以给你一个好的参考，对比你已掌握的测试框架和该书介绍的框架有何差异，取长补短。

应该怎么读这本书

书很厚，一头就扎进去读好像不符合这个快节奏的社会，所以我写这篇文章更像是一篇导读，在一头扎进去之前，看看我这篇文章也许能更有效的吸收书里的知识。但是导读归导读，书还是要慢慢看的。

在接下来的章节，我将以总分的结构来讲述本书内容。

OWASP 安全测试指南 v4.0 总章

从老板给你一个测试任务到你交付测试报告，这个过程你应该怎么做。

我们来看一下测试指南教我们怎么做

上图罗列来从开始到结束的流程。我先不对每个过程展开介绍，我倒更想说说为什么要这么排列，这还是蛮有趣的。

首先接到测试任务，有可能是黑盒测试 / 灰盒测试 / 白盒测试，假设是资源最少的黑盒测试，给你一个域名/ip，你应该怎么测呢？

第一步：信息收集

通过 OSINT 收集信息，收集子域名，收集应用程序入口，识别 web 服务器，识别应用程序框架，总之就是收集尽可能多的信息。信息收集看似简单，实际上非常关键。

第二步：配置以及部署管理测试

我们知道整个 web 环境涉及到操作系统，web 服务器，web 容器，开发框架，编程语言等

在管理员配置这些环境时，就有很多测试点，比如是否使用存在漏洞的组件，操作系统是否及时打补丁，先把配置/环境的问题测试了，再进行 web 应用的测试

接下来你面临的是不是登陆的问题，有些产品不登陆就一个 login 页面，能力再强也无能为力。说到登陆，就一定要提到登陆三件套，身份，认证，授权

我记得我准备 Security+认证考试的时候，就有一题模拟题是这样的

Which of the following is the proper order for logging a user into a system from the first step to the last step?A. Identification,authentication,authorization

Identification,authentication,authorization 也就是身份，认证，授权

题外话

认证方式有多种

- something you know (你知道什么，比如密码，PIN 码)
- something you have （你有什么，比如工卡，智能卡，钥匙）
- something you are （你是什么，比如指纹，虹膜）
- something you do （你做什么，比如签名，步态）

授权方式也有多种

- DAC （自主访问控制）
- MAC （强制访问控制）
- RBAC （基于角色的访问控制）
- ABAC （基于属性的访问控制）

所以，接下来分别是

第三步身份鉴别管理测试

第四步认证测试

第五步授权测试

认证完了以后，授权应该是以会话为中心的，所以进入下一步会话管理。

第六步会话管理测试

主要测试 CSRF，会话固定，会话退出，会话超时等等会话相关的项目

第七步输入验证测试

登陆进去了，能输入的点就多了起来，此时做输入验证测试正合适

第八步错误处理测试

输入异常是不是就会出错，正好在这时做错误处理测试，一般来说报错时不能泄露敏感信息，告知客户异常即可，提示应该模糊化。

接下来，密码学测试，业务逻辑测试，客户端测试相对来说较独立，可以独立测试。

以上就是我对本书总体结构的认识，我比较喜欢这种系统性的知识，因为这个结构化知识给你一种大局观，不会局限在某个小范围。如前文引用的，这个结构也是普遍被大家所认可的

许多业内专家和世界上一些大型公司的软件安全负责人共同验证了这个测试框架。这个测试框架帮助各类组织能够有效针对 Web 应用程序进行测试以便建立安全可靠软件，而不是简单地强调脆弱点。

下面我们将分章节讲解每一个测试项的细节

第一章信息收集

解读.信息收集

了解各类搜索引擎，及对应的搜索技巧，搜索引擎比如 google，bing，shodan，fofa，zoomeye，搜索技巧比如 inurl, site (可以了解以下 google hacking)
探测 Web 服务器指纹，常见 Web 服务器有 Apache2，nginx，IIS 等，尽量探测出服务器及对应版本-
搜索 Meta 文件（元文件），像 robots.txt，页面 HTML 源代码都属于元文件，这些数据可能会泄露一些敏感信息
枚举 Web 服务器上的应用，可能是 ssh，rtsp 等非 Web 应用，也可能是非标准端口（非 80，443）的 Web 应用，也可能是同一域名，不同路径下的不同应用
和第三点类似，查看页面源码及 js 代码，查找 meta 标签，以及代码注释等，这些地方都可能泄漏敏感信息
识别应用入口，这很关键，比如你找到一个 8443 端口，但是访问这个端口显示空白页面，有可能就是没找到入口地址，可能你需要访问 ip:8443/entry 才会有数据展示，这步要做的，就是找到 entry
所谓执行路径，比如我们访问一个页面 ip:port/entry/a/b/c/d/x 这里的 entry/a/b/c/d/x 就是一条路径，测试人员应该尽可能多的搜集路径，了解站点结构，可以使用爬虫等工具
Web 应用框架有很多，比如 ThinkPHP，CodeIgniter，jQuery，vue， django，Spring，Struts2，Hibernate，这些框架实现了基础的架构，类似与房屋骨架，应用开发者在骨架上添砖加瓦。搜索出框架及版本有可能可以利用，像 struts2 有一段时间就经常被爆出存在漏洞
前面提到框架，就是房屋骨架，在这个基础上，有现成的待修缮的房屋，类似于 wordpress，phpBB 等，房屋已基本完成，开发者只需在已有房屋基础上做一些小调整即可。搜索这个信息也是很重要的，因为 web 应用也可能存在已知漏洞。
定位应用架构，这就要求比较高了。你需要了解整个 Web 应用的架构，包括编程语言，是否部署 WAF，反向代理，负载均衡，后端数据库等等。尽可能的把应用的架构拓扑图画出来，这样对后续的测试工作是非常有利的。

第二章配置以及部署管理测试

解读.配置以及部署管理测试

对网络和基础设施的配置测试。假设你是运维人员，你负责整个站点的运维工作，是不是应该有个加固清单，mysql 不能对外开发，ftp 应该设置强密码并定期更新，等等。这些同时也是测试人员需要审核的。这些配置审核，更建议从白盒角度出发，你和运维人员一起审核评估。在此之前，测试人员应该熟悉所有的 web 应用架构，各个组件的安全配置，对加固方案都非常熟悉，才能很好的完成本项测试。这个测试项更强调网络架构的配置测试，如第一章最后一点提到的。
相比于网络架构的配置，本项目更强调 Web 服务器本身的配置测试，不同的服务器比如 apache，IIS 可能有不同的安全加固点，一些基本思路，比如只使能必要的模块，自定义错误页面，最低权限允许服务器软件，合理记录日志等
与文件扩展名相关的，我想到的是文件上传以及路径暴破，你要文件上传，首先了解服务器是用什么技术，asp，jsp，php 等，上传上去后，还要判断那个目录下的文件会被服务器解析执行。另外在做路径暴破的时候，会尝试比如 zip，tar，java，txt，doc，bak，old 等这些后缀，可能可以意外的下载到敏感文件。
旧文件，备份文件，未引用的文件。有些以. 开头的隐藏文件，有些以～结束的临时文件，以及 old，bak 等特殊后缀的文件都可能包含敏感信息，比如 login.jsp.old, 这些文件可能可以直接下载，泄漏了敏感信息。
网站一般而言有普通用户入口，有管理员入口，本测试就是枚举管理员入口，比如/adimin, /administrator, /management 等等
枚举 http 方法，用 OPTIONS 可以枚举出 HTTP 支持的方法，建议也是只支持必要的方法，不必要的就裁剪掉，避免引入额外的漏洞。
强制执行使用 https，检测服务器返回信息中 http header 是否有 Strict-Transport-Security 字段，这个测试点好像不是很被关注。
分析跨域测试，比如 crossdomain.xml, clientaccesspolicy.xml, 如果是 <allow-access-from domain="*" secure="false"/><site-control permitted-cross-domain-policies="all"/>就有存在安全隐患的

第三章身份鉴别管理测试

解读.身份鉴别管理测试

了解角色，比如普通用户，管理员用户，管理员又分为超级管理员和普通管理员等，角色的定义是为了方便做权限控制，有一种访问控制方法就是基于角色的访问控制（RBAC）
测试注册流程，普通用户注册流程，管理员新增流程
用户角色分配处理流程是怎么样的，谁有权限分配角色
用户名枚举，猜测
弱用户名策略，有些用户名是很容易被猜到的。比如管理员叫 Joe Bloggs，用户名可能是 jbloggs
检测是否有 guest 用户，或者匿名用户，测试这些账户有哪些权限
账户的暂停和恢复。有些站点对用户注册是敏感的，不对外开发，比如首页没有明显的注册入口，这种情况，应该对注册入口及机制做测试，检测是否存在问题。

书中是没有对最后两条进行展开描述的，这个只在 Checklist 中存在，Checklist 可查看参考文献[7]

身份是一种标识，意思是这个标识能代表你。这样就衍生出一个问题，如何避免别人仿冒你的身份？

没错，这就是下一章认证要说的，怎么证明你的身份是真实的。也就是怎么证实你是你。

第四章认证测试

解读.认证测试

认证传输是否通过加密信道，通俗的讲就是是不是通过 https 进行认证
系统是否有默认凭证，比如 admin/admin, default/default 等，以及新帐户是否有默认密码
检测认证过程锁定机制，有些锁定是在客户端做的，可以直接绕过客户端向服务器请求，绕过伪锁定
检测认证绕过。这里就有很多可能，比如 sql 注入绕过，修复返回值绕过等
客户端支持记住密码功能，要小心密码是怎么被记住的，怎么被处理，怎么被存储都要格外仔细检测。
浏览器缓存弱点，浏览器有浏览历史，会缓存服务器的返回值，这些都可能被利用获取敏感信息
弱密码策略检测，密码是否有安全基线要求，是否可以被暴破
弱安全问题及答案，这里和密码找回机制相关。一方面弱的密码问题及答案可能被破解，另一方面密码找回机制可能有问题可被绕过
检测密码更改和重置功能。这两个功能也是很敏感，需要花时间搞清楚整个业务逻辑是怎样的
现在流行手机验证码认证，这些非客户端与服务器直接交互的认证方式，也可能存在问题

基本上我们上手测一个产品/站点，除了上述一些信息收集，配置管理，身份管理等铺垫工作，认证应该是第一个最重要的模块了。

认证的核心目的是证明你是你，证明你的身份是真实的。比如你知道密码，你有智能卡，你有指纹，你的签名字迹等等。这个认证的过程就可能有很多问题。比如别人虽然不知道你的密码，但知道你密码的 hash，可以通过 pass-the-hash 漏洞进行攻击。认证过程可能被重复攻击。密码找回机制绕过等等。

在首先进行认证测试之前，应该花时间了解认证机制。什么是认证机制？常见的有 PAP，CHAP，Digest 认证，PAP 是指 Password Authentication Protocol， CHAP 是指 Challenge Handshake Authentication Protocol

比较简单的描述就是 PAP 是直接传密码进行认证， Digest 是把密码进行 hash，后台比对 hash 进行认证。而 CHAP 就会每次认证生成一个挑战值，后台比对加入挑战值后的 hash很明显，前两种都无法放认证重放，而 CHAP 能较好的防重放。

第五章授权测试

解读.授权测试

测试目录遍历/文件包含比如你是一个用户，你只被授权查看自己的文件，你通过目录遍历能查看 /etc/passwd 算不算授权问题，文件包含也类似，你通过本地文件包含查看来 /etc/passwd 也是越权
绕过授权机制，首先你要了解授权机制是怎么操作的，举例来说，假设服务端通过 cookie 里的 privilege 来判断权限，为 0 就是最高权限，此时你把自己的 privilege 改为 0 即达到授权机制绕过
测试越权，越权分为水平越权和垂直越权，这两个概念都是基于角色的访问控制来说的。比如 admin 角色和 user 角色，admin 角色权限 > user 角色权限，那么 admin 就是高层，user 就是低层。如果 user 用户能越权执行 admin 才能执行的操作，那么就是垂直越权。同样是 user 角色，u1 和 u2 是两个不同的用户，如果 u1 能修改 u2 的电话号码，这就是水平越权。
IDOR，不安全的直接对象引用。首先你要知道什么是对象。在 OOP 里，有类的概念，类的实体就是一个对象。你作为用户 u1，很多对象是属于你的，很多是不属于你的，如果你能操作别人的对象，就是 IDOR。举例来说，这是一个博客系统，你是用户 u1，你的文章 id 是 1，2，3，用户 u2 的文章 id 是 4，5，6，每篇文章都是一个对象，1，2，3，4，5，6 就是对象的编号。修改文章内容是通过 POST，POST 数据是 i=1&content=xxx. 此时如果你把 id 改为 4，而且能成功，就是引用里不属于你的对象，把文章 4 的内容改了。这就是 IDOR。没错，在这个场景下，也是一个水平越权漏洞。

再回过头来捋一遍身份，认证，授权这三个概念

身份：能代表你的信息（用户名，智能卡，指纹等）
认证：验证你是你，提供用户名对应的密码，刷智能卡卡，刷指纹，等等，都是验证你是你的过程
授权：认证了你的身份之后，授予你权限，决定你你能做什么，不能做什么

第六章会话管理测试

解读.会话管理测试

会话机制绕过。会话 id 预测，暴破，劫持等都是常见的会话机制绕过漏洞
检测 cookie 是否有带 http only 和 secure 属性
会话固定，每次登陆会话都是一样的
会话 id 是否又被加密，是否通过 get 方式传输，这些都是会话 id 可能泄漏的途径。会话 id 泄漏可能导致被用户身份被仿冒
CSRF，利用浏览器的机制自动把 cookie 附带到请求中。
用户登出后，会话是否依旧有效。
会话时效性检测，超时后会话是否依旧有效
会话变量重载，就是一个会话有多个使用场景。阅读参考文献[3]，了解到是这样一种场景，你用 admin/admin 登陆用户，正常会给你一个 sessionid，你登出后，点击忘记密码，输入用户名 admin 进行下一步后，服务器已经给你一个合法的 sessionid，而且这个 sessionid 是 admin 权限的。可以正常请求数据可登陆。这样就绕过认证了。

关于会话我暂时没有更多想补充的，不过我觉得有几个概念比较容易混淆，在此我以自己的理解说明一下

Cookie 是一种浏览器机制，服务器可以把一些信息通过 setcookie 让浏览器保存下来，再接下来的请求中，把这个信息带上。

Session 是会话，就像 tcp 的三次握手，在四次挥手之前，就是一次会话。而短连接的会话会抽象一些，就是两个人进行一次交谈，可能中间会被打断，但不影响谈话的开始和结束。会话是记录在服务器的，因为服务器是一对多的关系，它要维护和每一个客户端的会话。

SessionID，会话 id，就是上面谈到的会话的一个标记。就像 linux 中 open 一个文件，给你返回 fd 一样，sessionID 和 session 是绑定的

token，是令牌，现实生活中 token 可以理解为智能卡或者工卡类似的东西。在这里 token 就是一串字符串，token 有什么意义完全取决于服务器。

所以可能就会有这样的场景，客户端访问服务器，服务器生成一个会话，把会话 id 加密后设置在 token 中，最终 setcookie 到 cookie 中。最终客户端这边的 http 头部就会是Cookie: Token=asdf88…88xxyy

第七章输入验证测试

输入验证的内容太多了，xss，sql 注入，ldap 注入，xxe，命令注入，文件包含，缓冲区溢出，堆栈溢出，格式化字符串漏洞等等。这里不详细展开阐述（有机会另开一篇文章介绍）。

如果有读者对本章感兴趣，我建议可以阅读参考文献[4], 里面用生动的图文介绍了本章多个漏洞。

第八章错误处理测试

解读.错误处理测试

分析错误码。我们知道 http 的正常返回状态码是 200，测试人员应该尽量去检测服务器不同状态码返回时，是否存在信息泄漏，甚至服务器异常。
分析调用栈。什么是调用栈呢，我们知道代码里函数调用一般是一层一层的（递归不在讨论范围）。func1 –> func2 –> func3 我在测试过程经常会发现页面错误，java 的调用栈显示出来。这样就是没有做好错误管理。这个调用栈的信息可以给攻击者思路。了解服务器框架，调用流程等。

错误管理放在输入测试之后是因为，经常不确定的输出会出发错误提示。

想起以前一位朋友和我说的，所谓软件安全，就是对所有已知和未知的行为都做了合适的处理。

可能实际执行并没那么简单，但是我想思路应该是对的。

第九章密码学测试

解读.密码学测试

测试 https，了解 ssl 到 tls 的历史演变，了解最新的技术。搜集 openssl 的历史漏洞，例如Heartbleed，POODLE 等，了解密钥套件非对称加密，块加密，hash 等密码学知识
Padding Oracle，抱歉，这个我也不是很熟悉，就不多说
检测是否存在敏感信息不是通过加密通道传输的。简单的例子是认证时密码是通过 http 传输的

补充说一些密钥套件的知识

Cipher suites are named combinations of:

Key Exchange Algorithms (RSA, DH, ECDH, DHE, ECDHE, PSK)
Authentication/Digital Signature Algorithm (RSA, ECDSA, DSA)
Bulk Encryption Algorithms (AES, CHACHA20, Camellia, ARIA)
Message Authentication Code Algorithms (SHA-256, POLY1305)

一个密钥套件可以分成 4 部分，密钥交换算法，认证算法，块加密算法，哈希算法

比如一个套件是 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS 是指 tls 协议ECDHE 是密钥交换算法，EC 是椭圆曲线，DH 是 Diffie Hellman，E 是指 Exchange，基于椭圆曲线的 DH 密钥交换算法ECDSA 是认证算法，EC 是椭圆曲线，DSA 是 Digital Signature Algorithm, 基于椭圆曲线的数字签名算法AES_128_GCM，块加密算法采用 AES 128 比特，GCM 模式SHA256，哈希协议使用 SHA256

如果你对上述概念还是很模糊，建议再去查看一些资料。参考文献[5]写的还不错，建议读一读。