一、漏洞挖掘的前期–信息收集
虽然是前期，但是却是我认为最重要的一部分；
很多人挖洞的时候说不知道如何入手，其实挖洞就是信息收集+常规owasp top 10+逻辑漏洞（重要的可能就是思路猥琐一点），这些漏洞的测试方法本身不是特别复杂，一般混迹在安全圈子的人都能复现漏洞
。接下来我就着重说一下我在信息收集方面的心得。
1、域名信息收集
src一般都只收对应的漏洞，很多src的公告里面就会明确范围；然后我们就需要根据这些范围来确定域名。
如果src上面没有给出范围，那么需要我们去搜集，你需要知道哪些domain是该公司的，主要通过手工来查看：
网站的关于页面／网站地图whois反查一些网站里面的跳转请求（也可以关注一下app）还有就是百度，有些会在title 和 copyright信息里面出现该公司的信息网站html源码：主要就是一些图片、js、css等，也会出现一些域名apk反编译源码里面…………还需要你们来补充
2、子域名信息收集
工具：
其他的还有很多，比如kali下的等等，不写那么多免得看着蛋疼；
但是只要是工具就会有误报，建议大家对获取的子域名写个脚本处理一下；判断哪些是可以访问的，哪些是不可以访问的，哪些访问是测试页面的。可以节约不少时间。
手工：其实也是可以工具化（爬虫思维，不过爬虫不是很准确）
利用google hacking 搜索，大家一定不要只用google 搜索，这样是不全面的，还有 bing（不用翻墙）、百度、360等等，因为很多国内的网站利用google去搜索是搜不到的。这里就不说语法了，贴几条常用的就行了。
搜集域名和mail地址：
搜集敏感文件：site:xxx.com filetype:doc
搜集管理后台：site:xxx.com 管理／site:xxx.com admin／site:xxx.com login
搜集mail：site:xxx.com intext:@xxx.com／intext:@xxx.com
搜集敏感web路径：site:xxx.com intitle:登录／site:xxx.com inurl:sql.php
3、敏感信息收集
这一块是比较大的一块，我这里举一些：
-
github源代码：网上有工具（https://github.com/repoog/GitPrey）
-
svn信息泄漏：这个只能用扫描器了
-
敏感文件：比如数据库配置文件啦（有案例的）、网站源码啊、数据库备份文件等等
-
敏感目录：网站后台目录／一些登录地址／一些接口目录
-
email：邮箱命名规则、公司是否具有邮箱默认密码（这个可以采取社工，毕竟我司默认密码就很弱鸡）。
-
员工号：很多oa、um、sso系统都是采用员工号登录的，所以知道员工号的规则很多时候能帮助我们进行撞库。
-
商家信息：如果是一些具有商家系统的，能收集到一些商家账户（自己搞去，可以注册，注册资料请百度）就可以进入很多系统来测试了。
4、小结一下
其实很多时候，我们通过信息收集能得到不少的漏洞了，我这里举几个简单的案例：
-
通过搜索引擎获取系统管理页面，直接越权访问；（说好的没有详细）
-
通过github直接找到管理后台账号密码；
-
通过目录／文件扫描直接得到系统信息（ip、管理员账号密码）连入服务器；
-
当然也有很多通过信息收集得到一些东西结合其他手段；
二、漏洞挖掘的中期–信息处理
1、信息整理
对于第三节提到的那些信息收集技术，我们不能收集完了就完了，一定好好整理，会对后期渗透有很大的帮助。这里说一下具体怎么整理。
利用word或excel或txt 都行，我建议word 和excel 因为txt毕竟太简单了。分类：
-
哪些网站功能类似；
-
哪些网站可能使用的同一模版；
-
哪些网站有waf（这个一般在url中标明就好）；
-
哪些网站能登录（注册的账号也一定要记住，最好可以准备两个手机号，两个邮箱方便注册）；
-
哪些网站暴露过哪些类型的漏洞（这个只能去乌云上面找）；
-
网站目前有哪些功能（这个稍微关注一下网站公告，看最近是否会有业务更迭）；
2、漏洞整理
我们辛苦的挖洞一定要对我们挖掘出来对漏洞有一个记录，记录的可以稍微详细一些，一是可以方便自己以后回顾，还有就是以后说不定有些地方出现了跟以前一样的功能，这样就方便我们更快的找到漏洞。这里建议doc文档，图片可以贴的详细一些。
第二个就是通过漏洞得到的一些数据：
为什么我们要整理这些数据，因为我们要根据这些数据来设计我们的字典。爆破完好了，一样的6。
三、漏洞挖掘的后期–漏洞挖掘
有了前两步，这里我会写的少一点，毕竟漏洞的类型就那么些，像前文说过就是owasp top 10、逻辑，对于挖掘这些漏洞，我觉得没什么特别好的办法，就是抓包分析逻辑（这里说的不包括对软件客户端的挖掘、app的挖掘）；
首先我们需要对一个网站／app有一个
了解要知道它的功
能点有哪些（后期我会更新一个checklist介绍一下哪些功能会对应什么样的漏洞）。
其次我们要分析这个网站／app里面的请求哪些是我们可以控制的参数，这些地方就是漏洞经常出没的点。
最后就是分析逻辑，这一类别的漏洞主要还是涉及一套流程，这里举个例子：
例：”我们买东西”
-
筛选涉及查询（是否可以SQL注入）
-
加入购物车：商品数量是否可以为负
-
跳转客服系统，跳转url中是否含有用户参数
-
xss打客服cookie
-
钓鱼+社工
-
填地址，涉及插入（注入）、xss
-
修改单价
-
修改总额（这里说明一下修改总额：情况1，就是我们可能会遇到可以使用优惠卷的情况，比如我们买了100的东西只能使用5块的优惠价，但是我有一张50的优惠卷是否可以使用；情况2，打折我们是否可以修改打折的折扣；情况3，我们是否可以修改运费，将运费改为负数；情况n）
-
备注：xss，sql注入
-
会写抬头
-
传输过程中是否可以修改，如果是扫描二维码支付，我们可以分析一下二维码中的请求url看是否可以修改以后重新生成二维码（这里不讨论具体的支付了，因为微信和支付宝都很安全）
-
是否可以遍历订单
-
注入、上传图片、xss
大家可以无限延伸，这里只是抛砖引玉。
其实这方面的文章很少，几个原因：
大家会觉得就是经验，玩多了就自然会了，教不了什么；这种分享经验特别不好写，到现在也不知道我写了什么，其实都是一个思路点；懒，不愿意……肯定都有一定的原因；
建议：
src慢慢的挖多了系统更新不快，业务不多自然就很难挖了，所以一定要有坚持精神，深入挖掘意识，因为挖洞没有想象中的那么简单；不要想一步登天，多去看看一些案例分析一下别人的挖掘思路，然后跟着学。
四、安全漏洞相关的概念
安全漏洞的定义
我们经常听到漏洞这个概念，可什么是安全漏洞？
想给它一个清晰完整的定义其实是非常困难的。如果你去搜索一下对于漏洞的定义，基本上会发现高大上的学术界和讲求实用的工业界各有各的说法，漏洞相关的各种角色，比如研究者、厂商、用户，对漏洞的认识也是非常不一致的。
从业多年，我至今都找不到一个满意的定义，于是我自己定义一个：安全漏洞是信息系统在生命周期的各个阶段（设计、实现、运维等过程）中产生的某类问题，这些问题会对系统的安全（机密性、完整性、可用性）产生影响。
这是一个从研究者角度的偏狭义的定义，影
响的主体范围限定在了信息系统中，以尽量不把我们所不熟悉的对象扯进来。
漏洞之所以被描述为某种“问题”，是因为我发现无法简单地用脆弱性、缺陷和Bug 等概念来涵盖它，而更象是这些概念的一个超集。漏洞会在系统生命周期内的各个阶段被引入进来，比如设计阶段引入的一个设计得非常容易被破解的加密算法，实现阶段引入的一个代码缓冲区溢出问题，运维阶段的一个错误的安全配置，这些都有可能最终成为漏洞。
定义对安全的影响也只涉及狭义信息安全的三方面：机密性、完整性和可用性。漏洞造成的敏感信息泄露导致机密性的破坏；造成数据库中的信息被非法篡改导致完整性的破坏；造成服务器进程的崩溃导致可用性的丧失。漏洞也可能同时导致多个安全属性的破坏。
安全漏洞与Bug的关系
漏洞与Bug 并不等同，他们之间的关系基本可以描述为：大部分的Bug 影响功能性，并不涉及安全性，也就不构成漏洞；大部分的漏洞来源于Bug，但并不是全部，它们之间只是有一个很大的交集。可以用如下这个图来展示它们的关系：
已知漏洞的数量
各个漏洞数据库和索引收录了大量已知的安全漏洞，下表是一个主流漏洞库的数量的大致估计，漏洞一般最早从20 世纪90 年代开始：
事实上，即便把未知的漏洞排除在外，只要订了若干漏洞相关的邮件列表就会知道：并不是所有漏洞数据库都会收录，就算把上面的所列的数据库中的所有条目加起来去重以后也只是收录了一部分的已知漏洞而已，实际的已知漏洞数比总收录的要高得多。
安全漏洞的分类
和其他事物一样，安全漏洞具有多方面的属性，也就可以从多个维度对其进行分类，重点关注基于技术的维度。注意，下面提到的所有分类并不是在数学意义上严格的，也就是说并不保证同一抽象层次、穷举和互斥，而是极其简化的出于实用为目的分类。
基于利用位置的分类
本地漏洞
需要操作系统级的有效帐号登录到本地才能利用的漏洞，主要构成为权限提升类漏洞，即把自身的执行权限从普通用户级别提升到管理员级别。
实例：
Linux Kernel 2.6 udev Netlink 消息验证本地权限提升漏洞（ CVE-2009-1185 ）攻击者需要以普通用户登录到系统上，通过利用漏洞把自己的权限提升到 root 用户，获取对系统的完全控制。
远程漏洞
无需系统级的帐号验证即可通过网络访问目标进行利用，这里强调的是系统级帐号，如果漏洞利用需要诸如FTP 用户这样应用级的帐号要求也算是远程漏洞。
实例：
Microsoft Windows DCOM RPC 接口长主机名远程缓冲区溢出漏洞（MS03-026 ）（CVE-2003-0352）攻击者可以远程通过访问目标服务器的 RPC 服务端口无需用户验证就能利用漏洞，以系统权限执行任意指令，实现对系统的
完全控制。
基于威胁类型的分类
获取控制
可以导致劫持程序执行流程，转向执行攻击者指定的任意指令或命令，控制应用系统或操作系统。威胁最大，同时影响系统的机密性、完整性，甚至在需要的时候可以影响可用性。主要来源：内存破坏类、CGI 类漏洞
获取信息
可以导致劫持程序访问预期外的资源并泄露给攻击者，影响系统的机密性。
主要来源：输入验证类、配置错误类漏洞
拒绝服务
可以导致目标应用或系统暂时或永远性地失去响应正常服务的能力，影响系统的可用性。
主要来源：内存破坏类、意外处理错误处理类漏洞。
基于技术类型的分类
基于漏洞成因技术的分类相比上述的两种维度要复杂得多，对于目前我所见过的漏洞大致归纳为以下几类：
-
内存破坏类
-
逻辑错误类
-
输入验证类
-
设计错误类
-
配置错误类
以下是对这几类漏洞的描述和实例分析。
内存破坏类
此类漏洞的共同特征是由于某种形式的非预期的内存越界访问（读、写或兼而有之），可控程度较好的情况下可执行攻击者指定的任意指令，其他的大多数情况下会导致拒绝服务或信息泄露。对内存破坏类漏洞再细分下来源，可以分出如下这些子类型：
-
栈缓冲区溢出
-
堆缓冲区溢出
-
静态数据区溢出
-
格式串问题
-
越界内存访问
-
释放后重用
-
二次释放
栈缓冲区溢出
最古老的内存破坏类型。发生在堆栈中的缓冲区溢出，由于利用起来非常稳定，大多可以导致执行任意指令，威胁很大。此类漏洞历史非常悠久， 1988 年著名的Morris 蠕虫传播手段之一就是利用了finger 服务的一个栈缓冲区溢出漏洞。在2008 年之前的几乎所有影响面巨大的网络蠕虫也基本利用此类漏洞，汇总情况可以见下表：
上面表格里列出的蠕虫即使经过多年，在当前的互联网上还经常被捕捉到。栈溢出漏洞是相对比较容易发现的漏洞，静态动态分析的方法对于此漏洞的挖掘已经相当成熟，因此这类漏洞，特别是服务端程序中，目前基本处于日渐消亡的状态。
实例：
长度检查不充分的串连接操作。
无长度检查的*printf 调用。
