你写的api接口代码真是_SQLMAPAPI一个被遗忘的API接口第二章：从代码层面去分析API接口的强大...-CSDN博客

本文链接：https://blog.csdn.net/weixin_39901439/article/details/111673883

文章前言：

“

在上篇文章中我们通过应用层的这一块去知道了我们SQLMAP API的使用方法以及他强大的功能。在本文中我们将会以代码层面的方式去分析我们的SQLMAP API的一个运作方式。同时在这里感谢团队里的大佬们的一个对代码分析这一块的指导，让本文更加的精彩。(P.S. 本文很多不是特专业的一些术语，如果有指向错误还请大佬们批评指出！)

”

文章目录：

1.API核心代码的分析

2.API调用方式的分析

3.API对多任务的实现

在上一篇文章中，我们来说了在命令执行的一块去操作的方式，但是对于代码这一块，国内貌似没有这么多人去关注我们的核心代码信息。我们将从核心代码，调用方式，和对多任务的实现这几个方面去进行分析。

—

API核心代码的分析

我们首先先来看代码的包含这一块。在代码的这几行我们发现在sqlmapapi.py当中包含了比较核心的几个库。在api库里面Client端和Server是在我们最后两行去进行包含的。我们的主要分析还是在Client端和Server端。

首先开头调用了这两个函数

dirtyPatches()resolveCrossReferences()

这两个函数分别对SQLMAP这个大的一个框架进行了一个错误修正的过程。在这里各大论坛都有着详细的介绍。在本文就不多加赘述了。

然后在这下面，在这里的话我们可以看到他的一个调用方式去直接调用了server和client的这个函数来进行API的一个开启或者连接到API。这个都是在我们sqlmap\lib\utils里面的，下面我们继续跟进我们的API里面的东西。

跟进后我们第一步来看这个包含的一些使用库。我们可以发现他用了SQLITE3来进行数据的一些临时保存和管理，想必我们的主要的TASKID和我们的注入数据都是通过SQLITE3来进行存放的了。其他的一些库都是平时比较常见的库，在本文就不多加再去进行说明了。

在下面的这些库中呢我们发现都是我们SQLMAP常见和一些常用的库。那么我们怎么去理解他在命令行中的API接口怎么又来去调用我们的任务这些呢？

在上文中我们说到过，我们的SQLMAP API的命令行中的请求，都是以我们的HTTP的请求去进行传输的。每一步的请求都是在去调用了我们的这个WEB接口。这个WEB接口在上文中我们提到。他使用bottle 框架的wsgiref标准接口。

也就是我们在第三方文件夹中的这个bottle的这个框架。

我们在继续跟进一下这个框架的东西

唯一在文件里面和SQLMAP API相关的就是我们的DEBUG这里了

其他的都是属于我们bottle这个框架的东西了。如果有兴趣的小伙伴们可以自己去学习一下bottle，我个人感觉这个对于一些小型的WEB应用是一个可以快速进行开发的一个框架。

以上呢就是我们这一套比较核心的代码的一个分析了。可能分析的比较散，希望各位大佬多多包涵，下面呢我们即将从我们的调用角度来进行一个分析。

—

API调用方式的分析

我们现在回到我们的A PI. py这个主文件来看。

我们的SQLMAP API一共是有这几个类

Database()#操作数据库的类Task()#任务操作相关的类StDbOut()#调用输出我们任务的相关信息的类LogRecorder()#日志记录的类别

这几个类就是我们SQLMAP API比较主要的几个类了。

下面我们来主要跟进一下Task()这个类里面的东西，其他的类呢我们作为次要的一个类别来进行分析。

但是在此之前我们先来看Database类里面的操作

在初始化阶段我们的SQLMAP API 就创建了我们的这些表单在这里面。分别记录了我们的TASKID,注入的信息以及我们的的一些错误。

随后我们我们再来跟进我们的Task()

这里初始化了一些参数，避免我们在开启多个任务的时候出现问题。

小提示： AttribDict 是 SQLmap 自己继承了一个 Dict 完成了对原来 Dict 的一些改进，可以简单就当成一个 Dict 来看就可以了。

在调用任务，初始化完成后这里会返回一个Taskid等等。在我们的http的调用方式里我们的调用分为两步，首先第一步我们必须要开启一个“伪”任务，然后再任务里面去投递我们的一些扫描参数等等(P.S. 也就是分了一个任务和引擎调用的两步)。在我们的命令行模式当中只是我们的程序去帮忙完成了这两步。

也就是这两个过程。

如果在我们去进行引擎开始调用的时候，我们的扫描引擎开启的方式：

我们这里居然神奇的发现，它还是去调用了我们的SQLMAP。用了sqlmap.py –api -c加上一些配置项去进行了操作。最终还是离不开我们的SQLMAP，但是这里在我们的SQLMAP帮助中我们可以发现是没有—api这个参数的。

那么我们待会儿再来仔细分析一下api这个参数在我们SQLMAP里面的操作。

这里解释一下当中我们的-c的这个参数，它是去读取一些我们的配置文件。比如提前设置好参数这些例如地址或者是我们的一些注入等级，线程设置，User-Agent等这种类似的参数。

然后我们再来跟进一下SQLMAP API调用的SQLMAP –api的这个参数的内容。

在我们的api这个参数里面就是主要扫描的一些记录全部放到了我们的IPC database里，这样的话就就让我们的SQLMAP“静默“的去运行了。默默地把问题和测试数据全部放到了我们的Database里，然后我们只需要去调用数据库里面的东西就行了。他的反馈全部放到了我们的数据库里。

那么这个就是我们扫描开始的一个完整过程了。

其实分析到这里，我们不难发现我们的sqlmap api并不是一个独立开的一个个体，我们的sqlmap api就是一个简化我们调用sqlmap过程的一个东西。他把一切都已经给你接口化了，而我们要做的就是去调用它而已。但是我们这里就要注意一个点了，我们的SQLMAP在注入的一些过程中，可能会有一些线程假死的一个方案，导致成为了一个幽灵线程。这里各位可以注意一下。

以上就是我们对SQLMAP API调用方式的一个比较细化的分析。接下来我们再来分析一下多任务的一个实现过程。

—

API对多任务的实现

在开始之前我们必须要搞清楚一个东西，那就是我们的SQLMAP每一个任务都是对应一个ID的，当我们测试完成后这个ID就是一个死亡的ID了。就是他不会在调用引擎就进行扫描，即使你在调用http接口中的task//start，也不会进行扫描，对于sqlmap来说这个任务已经完成。所以我们下发我们的新任务必须要创建一个新的任务ID才可以正常的去进行扫描测试。

搞清楚这个问题后，我们就来看一下SQLMAP API对”多线程“的一个处理。