本文原創(chuàng)作者：VillanCh，本文屬FreeBuf原創(chuàng)獎勵計(jì)劃，未經(jīng)許可禁止轉(zhuǎn)載
在最近忙活的一些事情中，體會到：如果你寫的不是一個腳本，那么作為一個有命令行交互的工具，整個工具的結(jié)構(gòu)和可拓展性就應(yīng)該稱為一個非常重要的部分。本文就帶大家來探討一下這個問題。當(dāng)然前提是讀者能寫得出這個工具，本文理論比較多，實(shí)踐部分讀者可以期待以后的文章。
000 背景介紹
其實(shí)就我自己來說，我是非常喜歡 SQLmap 的架構(gòu)。當(dāng)然不得不承認(rèn)，SQLmap 源碼也是非常優(yōu)雅。當(dāng)然網(wǎng)上也有了關(guān)于 SQLmap 源碼分析的文章，兩篇比較好的文章都算是虎頭蛇尾。我的這篇文章不會只以 SQLmap 為例子。同樣還有我自己上個月完成的一個很有趣的匿名代理收集工具。
在一開始我在想怎么樣把構(gòu)造一個工具的每一個步驟都給大家呈現(xiàn)出來這個問題上，傷了不少腦筋，因?yàn)樾枰婕暗姆矫孢€是非常的多的。僅僅是整體大致來講，非常的抽象而且，肯定難免劃水吧。
于是我們還是以解決具體問題的視角來討論這個工具應(yīng)該怎么樣完成吧！
001 交互控制
關(guān)于交互控制，我們大致能想到的就是三種方式：
1. 直接命令行交互
2. shell 交互
3. 提供 API
這三種交互方式如果都能提供最好，如果工具簡單，功能單一，結(jié)構(gòu)也不打算設(shè)計(jì)多么復(fù)雜。一般來說，只需要提供一個命令行交互就可以了，但是我個人推薦至少還是需要提供 API， 單獨(dú)把 API 抽離出來，這樣讓你的功能腳本（核心層）有更大的自由度去完成一些事情。不需要為了命令行的問題去妥協(xié)，不斷修改功能腳本。只需要在 API 構(gòu)造的時候完成對核心功能腳本的適應(yīng)。
與此同時，你在構(gòu)造 shell 或構(gòu)造命令行解析器的時候，可以無后顧之憂的調(diào)用 API，不必牽一發(fā)而動全身。
那么我們?nèi)绾瓮瓿捎脩艚换サ臉?gòu)造呢？既然我們選擇 Python 作為工具開發(fā)語言，Python 強(qiáng)大的模塊肯定幫的上我們的忙。
cmd
optparser
cmd是一個構(gòu)造 shell 的一個簡易框架，通過繼承 cmd 中的 Cmd 類，添加相應(yīng)方法可以構(gòu)造出一個自己的 shell 用于實(shí)時與用戶交互。
如果大家有過 Python 使用經(jīng)驗(yàn)的話，應(yīng)該對 optparser 比較熟悉吧，這是一個非常優(yōu)秀的構(gòu)造命令行交互的框架，方便解析命令行。
那么在 SQLmap 中，三種交互方式都是存在的，可能大家用的更多的是直接命令行交互，而很少用 SQLmap 的 shell 交互。
但是值得一提的是 SQLmap 的 API 并不是我提到的 API 概念一樣。 使用過 SQLmap API 的朋友們肯定都知道 SQLmap 的 API 是要設(shè)定服務(wù)器的，通過本地 RESTful 風(fēng)格的 API 調(diào)用來使用 SQLmap 完成功能。而我這里所說的 API 是介于核心功能層與交互層之間的層，提供交互與核心功能腳本的隔離。
002 配置問題
我私以為這是非常有必要重視的一個地方，在我剛開始接觸這玩意的時候，經(jīng)常性的改動了一個地方的數(shù)據(jù)，還要手動翻到別的腳本中去改相應(yīng)的配置。道理大家都懂，但實(shí)際動手的時候，自己仍然是犯蠢了。那么這里其實(shí)很好解決。你可以設(shè)置配置的全局的變量都放在一個 yourdata.py 中，然后當(dāng)需要的時候
from yourdata import XXXXXX
或者
from data.yourdata import XXXXXX
雖然可能在大家看來這是很小的事情，也并不用提到臺面上，但是作為吃過虧的人來講，我還是樂意帶大家看看 SQLmap 是怎么解決這個問題的。
下圖是 SQLmap 的部分目錄結(jié)構(gòu)：
這個 data.py 中：
#!/usr/bin/env python
from lib.core.datatype import AttribDict
from lib.core.log import LOGGER
# sqlmap paths
paths = AttribDict()
# object to store original command line options
cmdLineOptions = AttribDict()
# object to store merged options (command line, configuration file and default options)
mergedOptions = AttribDict()
# object to share within function and classes command
# line options and settings
conf = AttribDict()
# object to share within function and classes results
kb = AttribDict()
# object with each database management system specific queries
queries = {}
# logger
logger = LOGGER
注意： AttribDict 是 SQLmap 自己繼承了一個 Dict 完成了對原來 Dict 的一些改進(jìn)，可以簡單就當(dāng)成一個 Dict 來看就可以了。
然后 SQLmap 在測試 SQL 注入的過程中，使用的配置文件事先全部被加載到了 conf 和 kb 中了，因此，在程序執(zhí)行的過程中，凡是需要用到配置文件的地方，只需要 import 進(jìn) conf 與 kb 就可以很方便完成任務(wù)了。 同時默認(rèn)配置在同目錄下的 defaults.py 中，各種數(shù)據(jù)（比如重要的枚舉類型，重要的 dicts）都在 core 這個包中，當(dāng) SQLmap 需要的時候只需要 import 進(jìn)實(shí)現(xiàn)設(shè)定好的數(shù)據(jù)就可以了。
可能有些讀者還是覺得，這并沒有什么了不起，或者并沒有體會到這樣做的便捷性（我直接寫在功能腳本里快得很，而且從來不管你所謂的架構(gòu)，我的程序照樣跑啊。），如果這樣想的話，大概這樣可能程序的擴(kuò)展性也健壯性都會受到很大的影響。
下面是我認(rèn)為比較優(yōu)化的一個結(jié)構(gòu)
同樣對比我們看一下比較糟糕的結(jié)構(gòu)
問題還是相當(dāng)明顯的：配置1，配置2，配置3很有可能有交集，當(dāng)你需要改動交集中的某項(xiàng)配置的時候，你需要改動三個功能腳本，這是非常難受的一件事情。
003 I/O 控制
所謂的 I/O 控制并不是說像操作系統(tǒng) I/O 那樣的概念，我們要討論的是程序的 I/O 問題：
1. 用戶輸入與呈現(xiàn)給用戶(交互與輸出)
2. 網(wǎng)絡(luò) I/O (訪問網(wǎng)絡(luò))
3. 文件與數(shù)據(jù) I/O (數(shù)據(jù)庫與 csv, xml, json 等類型文件讀取與導(dǎo)出)
4. 日志
問題：網(wǎng)絡(luò) I/O ?
讀者肯定要問，網(wǎng)絡(luò) I/O 也需要我們專門注意么？
肯定需要！在大家使用一個滲透工具的時候，肯定多多少少注意隱匿自己的身份，當(dāng)然事先布置好 Tor 或者 VPN 或者 使用 HTTP 代理，當(dāng)然，在國內(nèi)的我們可能會花了好大的力氣配置 Tor 的上游服務(wù)器，會花錢購買 VPN（當(dāng)然會被告知禁止使用 VPN 做非法的勾當(dāng)），或者說上公共代理網(wǎng)站上尋找一些公共的代理拿來用。（當(dāng)然，我也經(jīng)常干這些事情。所以寫了一個公共代理收集過濾的工具）。所謂的網(wǎng)絡(luò) I/O 控制就是說控制你連接網(wǎng)絡(luò)的某些方式，比如 SQLmap 提供了使用 Tor 的接口，也提供了 HTTP 代理的接口（–proxy）這些功能都是在網(wǎng)絡(luò) I/O 控制實(shí)現(xiàn)的。
可能有朋友就會說，Python 中有 requests 還不夠么？自己重新寫一個是什么鬼啊？
那么我們就具體來看一下 SQLmap 中的網(wǎng)絡(luò)控制，大家一切都明了了。
對代理的細(xì)節(jié)處理顯然不是其他的自帶的模塊所有的，這里的對 Tor 和 http 代理的處理就數(shù)據(jù)網(wǎng)絡(luò) I/O 的控制。
當(dāng)然這里可能看不到對 Tor 處理的細(xì)節(jié)，但是打開 connReadProxy
那么對于網(wǎng)絡(luò) I/O 我們就不談更多了。
在用戶輸入與展現(xiàn)給用戶的輸出上，還是有話要說的。因?yàn)椋绻茈S意的直接 print 出去的話非常的尷尬，我們可以單獨(dú)控制一個輸出函數(shù)，程序中所有的輸出都調(diào)用某個函數(shù)或者以同一種方式輸出，而不是到處都存在的調(diào)試專用 print 。 其實(shí)這樣做非常的合理，當(dāng)輸出可控時，你可以控制輸出的等級，比如 Debug 級別，在 Debug 開啟的時候，所有的信息都會輸出。 Error 級別， 還有 Info, Warning, Critical 在輸入的時候，你決定這條信息展示在用戶面前的級別，一般來說，如果 Info 級別的信息優(yōu)先級要低于 Critical， 你（或者）可以選擇 Info 級別的輸出要不要用戶看到，只展示 Error 或者只展示 Critical 以上的信息。
同樣的對于日志來說也一樣，如果大家有使用過 logging 模塊應(yīng)該會熟悉這個非常好用的日志模塊，替我們剩下了很大的力氣，不用自己去寫日志的輸出格式什么了。
哎，數(shù)據(jù)庫讀寫，核心功能腳本執(zhí)行的結(jié)果要支持不同數(shù)據(jù)類型的導(dǎo)出，這些也應(yīng)該是要具備的，因?yàn)閷?dǎo)出的易用的數(shù)據(jù)文件，可以很容易的被其他工具使用，可以以更好的方式被加載，使用，而不是手動的再次輸入結(jié)果，這樣很蠢的。
在 SQLmap 中就使用了很多專門處理各種特定文件類型的腳本來完成這樣的基礎(chǔ)性的工作。
004 差錯控制
編寫滲透測試工具的人員一般不是專業(yè)的程序員，那么差錯控制肯定也是一個值得注意的問題。并不推崇一個 try 一個 except 捕捉所有的錯誤，這樣真的出事的時候會讓人一頭霧水的。那么正確的做法應(yīng)該是什么呢？編寫你自己的異常，靈活使用 Python 提供的例如 ValueError IndexError 和鍵盤中斷等，然后讓出問題的部分了屬于胸。
可能我在這里說這個，懂得編程的讀者會覺得可笑，說實(shí)話我也覺得這非常的班門弄斧，但是我相信點(diǎn)開這篇文章的大多數(shù)還是一個滲透測試的愛好者或者從業(yè)者，在進(jìn)行滲透測試的時候經(jīng)常會需要寫腳本，完成自己的目的。到一定程度以后，希望把自己的腳本整合起來，做一個更好的工具。自己使用或者是留給別人用。畢竟寫腳本和寫程序做工具還是完全不同的兩個概念，作為一個寫得出腳本的滲透測試者，還是需要多少有一些編程的經(jīng)驗(yàn)。
005 我心中的理想架構(gòu)
上面講了這么多，可能有些人會有所收獲，有些人會一頭霧水，至少我覺得，結(jié)合我自己這段時間的體會，和幾個具體的例子，一個 Python 工具該有的架構(gòu)，該有的內(nèi)容，我還算是比較了解的。
那么我就專門做了一個 Python 工具的架構(gòu)圖給大家看，當(dāng)然這是我心目中比較不錯的結(jié)構(gòu)了。如果有興趣的話，大家可以實(shí)現(xiàn)一下，開發(fā)一個更高效更好用的工具。
上圖的工具比較適合腳本集類型的工具開發(fā)，功能可以比較分散，在具體的功能上可以不要求太大的連續(xù)性，但是交互性更加強(qiáng)，建議使用 shell 做交互以便不同功能隨意切換而且不需要重新加載程序。
這第二種架構(gòu)就是 SQLmap 所使用的架構(gòu)的‘改變’版本（SQLmap 沒有提供功能開放的 API， 但是我還是希望這樣來讓所有的 API 更加好找易于二次開發(fā)）。特別適合流程類的工具開發(fā)。比如 SQL 注入檢測就是一個可以抽象出流程的測試過程。
006 結(jié)語
一款牛B的工具的誕生，絕對不是簡單的功能拼湊，而是不斷重構(gòu)，思考，注意細(xì)節(jié)。
顯然我們足夠幸運(yùn)，可以使用 Python， 很多細(xì)節(jié)的工作，前人已經(jīng)替我們完成了，站在巨人的肩膀上，風(fēng)景顯然更加的壯觀。
那么，如果大家還是不太名如何完成一個工具的話，如果感興趣的人多的話，我就繼續(xù)講非常具體的細(xì)節(jié)吧，很樂意和大家分享我微薄的經(jīng)驗(yàn)。
*本文原創(chuàng)作者：VillanCh，本文屬FreeBuf原創(chuàng)獎勵計(jì)劃，未經(jīng)許可禁止轉(zhuǎn)載
京公網(wǎng)安備 11010502049343號