Spaghetti扫描器源码分析之发现模块
2017-10-28 18:50
381 查看
首先,看下modules下源码结构:
![](https://img-blog.csdn.net/20171028185044781)
从源码的目录结构可以看到,在modules下面有两个部分。fingerprints我们在之前已经分析过了,这篇主要分析一下discovery目录下面各部分的源码。
这里先看一下util下面的manager.py源码。这里基本就是按照discovery每个子目录构建一个初始化函数。
![](https://img-blog.csdn.net/20171028185045904)
先来分析attack子目录的实现过程。下面是attack子目录下面的检测脚本,检测脚本比较少,其实算是比较单薄的。
![](https://img-blog.csdn.net/20171028185046614)
attack.py脚本定义了一个Attack类,类中对各攻击脚本先做了参数初始化,然后调用各攻击脚本的run方法执行特定漏洞验证。
![](https://img-blog.csdn.net/20171028185047488)
分析sql.py脚本看下实现方式。思路都是一贯的:用payload替换掉输入点的参数值,然后提交判断返回值是否含有特定字符串。
sql注入的测试很简单,看着data下面sql.txt给的几个payload很简单,比如没有延迟注入。可以预见这个sql注入脚本也只是简单验证性质的。其实,sql注入这块可以把sqlmap接进去。后续我会相信分析sqlmap源码。
util下params.py下实现payload的替换操作,函数如下:
![](https://img-blog.csdn.net/20171028185048484)
替换之后,在sql.py中就是提交替换好的url,然后判断是否存在特定字符串。判断的函数如下所示:
![](https://img-blog.csdn.net/20171028185050701)
整个sql.py的核心函数如下所示:(这里有对单个参数和多个参数的注入验证)
![](https://img-blog.csdn.net/20171028185052310)
基本上这个sql注入的检测就分析完了。
接下来,看看brute子目录下的实现细节。首先看一下data下面的文件列表:
![](https://img-blog.csdn.net/20171028185053015)
这个主要是各种payload的文件集合,payload比较少,所以只能触发各种漏洞的部分情况。
看下file.py文件的源码,关键部分的代码在下面:
![](https://img-blog.csdn.net/20171028185053887)
思路很简单,从payload文件选取文件名与url组合成新的url,然后提交访问一下,看是否返回状态码200。有没有发现,其实自己很好写利用代码,这个框架相关利用脚本都是遵循统一的编写格式。
继续看下面的disclosure目录。这里主要对网站返回值进行ip、email、credit_cards格式正则匹配,获取相关信息。
util目录下parser.py下获取ip、email、credit_cards的函数如下:
![](https://img-blog.csdn.net/20171028185054823)
后面的other也类似,就不继续分析了。
看下vulns目录下,对部分漏洞的验证。看shellshock.py的源码:
![](https://img-blog.csdn.net/20171028185055742)
这里包含了payload,后续验证的代码如下:
![](https://img-blog.csdn.net/20171028185056606)
仔细看看其实代码编写格式都是一致的。discovery这一块大致分析都到这里。
从源码的目录结构可以看到,在modules下面有两个部分。fingerprints我们在之前已经分析过了,这篇主要分析一下discovery目录下面各部分的源码。
这里先看一下util下面的manager.py源码。这里基本就是按照discovery每个子目录构建一个初始化函数。
先来分析attack子目录的实现过程。下面是attack子目录下面的检测脚本,检测脚本比较少,其实算是比较单薄的。
attack.py脚本定义了一个Attack类,类中对各攻击脚本先做了参数初始化,然后调用各攻击脚本的run方法执行特定漏洞验证。
分析sql.py脚本看下实现方式。思路都是一贯的:用payload替换掉输入点的参数值,然后提交判断返回值是否含有特定字符串。
sql注入的测试很简单,看着data下面sql.txt给的几个payload很简单,比如没有延迟注入。可以预见这个sql注入脚本也只是简单验证性质的。其实,sql注入这块可以把sqlmap接进去。后续我会相信分析sqlmap源码。
util下params.py下实现payload的替换操作,函数如下:
替换之后,在sql.py中就是提交替换好的url,然后判断是否存在特定字符串。判断的函数如下所示:
整个sql.py的核心函数如下所示:(这里有对单个参数和多个参数的注入验证)
基本上这个sql注入的检测就分析完了。
接下来,看看brute子目录下的实现细节。首先看一下data下面的文件列表:
这个主要是各种payload的文件集合,payload比较少,所以只能触发各种漏洞的部分情况。
看下file.py文件的源码,关键部分的代码在下面:
思路很简单,从payload文件选取文件名与url组合成新的url,然后提交访问一下,看是否返回状态码200。有没有发现,其实自己很好写利用代码,这个框架相关利用脚本都是遵循统一的编写格式。
继续看下面的disclosure目录。这里主要对网站返回值进行ip、email、credit_cards格式正则匹配,获取相关信息。
util目录下parser.py下获取ip、email、credit_cards的函数如下:
后面的other也类似,就不继续分析了。
看下vulns目录下,对部分漏洞的验证。看shellshock.py的源码:
这里包含了payload,后续验证的代码如下:
仔细看看其实代码编写格式都是一致的。discovery这一块大致分析都到这里。
相关文章推荐
- Spaghetti扫描器源码分析之爬虫模块
- XUtils 源码分析(三)--数据库操作模块
- Nginx 源码分析-- 浅谈对模块module 的基本认知
- 哎,学一半发现难以绕过著名数据分析模块
- ceph-deploy源码分析(四)——osd模块 <转>
- Nginx 源码分析-- 模块module 解析执行 nginx.conf 配置文件流程分析 二
- Nginx源码分析-核心模块剖析及常见问题
- Spark Scheduler模块源码分析之DAGScheduler
- Glusterfs之rpc模块源码分析(中)之Glusterfs的rpc模块实现(3)
- nginx源码分析—模块及其初始化
- nginx源码分析——事件模块
- 跟我一起读postgresql源码(二)——Parser(查询分析模块)
- Backbone.js源码分析系列之Collection模块
- Kubernetes之scheduler模块源码分析
- Flume NG源码分析(一)基于静态properties文件的配置模块
- Flume NG源码分析(二)支持运行时动态修改配置的配置模块
- jQuery 1.8源码分析 core.js核心模块 jQuery对象的构造分析
- XUtils 源码分析(一)--网络操作模块