写在前面的话: 笔者菜鸟一枚，比较喜欢折腾，在尝试用BurpSuite暴力破解http basic认证的时候，碰到了，如下问题：

Authorization的Basic值域是Base64加密的，该值为 username:password  （注意“：”号） 经过base64加密的结果，但笔者手头没有这样的字典，而且凭我对BurpSuite（以下简称BP）有限的了解,BP的decoder，不能完全解决这个问题。

A格式的字典，可以通过设置encode ，转换为base64。

B 格式是user字典与pass字典的合集。两者分别encode，这样拼接起来的效果是不是和A一样呢，经实验，我想多了。关于问题的解决，这里给出笔者的解决方案，一定还有更好的方法，这里算是抛砖引玉吧。期待和大家交流。

这里的着眼点是生成user:pass组合的字典，既然最后Basic的值域是base64加密后的结果，那不如直接生成base64_encode(user:pass)后的结果字典，这是AuthTrans（Ruby写成）实现的功能。
功能界面：（中国式英语，请见谅…..）

现在手头的字典，为密码字典（pass.txt），用户名字典（user.txt），以及用户：密码字典（user-pass.txt），通过AuthTrans都可以转换为user:pass字典。
各个选项意思如下：

A:加载user.txt和pass.txt，生成base64加密的user-pass字典，遍历实现。
B:加载user：pass字典，输出base64加密的user-pass字典。
C:输入一个用户名，并加载pass.txt。
D：输入一个密码，并加载user.txt

现演示环境目录结构如下：

选择C选项后的运行结果，output文件夹为自动创建的输出目录。

文件输出位置，命名规则很容易就能看出来。

生成的root用户名和pass.txt 遍历后的 root-pass 字典

现在回到BP,加载刚才生成的字典。一轮遍历下来，全是401。郁闷了，看下包

原来我们的值被BurpSuite 给URL编码了，找到问题，取消自动编码。

再跑一次。这里面有200，不过，人工寻找，太累了。

学会使用过滤器，能节省好多时间。

其实过滤器还可以写成，200，但是这是在我们知道正确结果的返回情况后，所得出的结论。一般实际应用中，你是不知道正确的返回页面是怎样的，但是可以知道错误页面的特征，所以我们使用反向选择，更具实用性。
勾选negative（反向选择），匹配项，填写错误页面的特征。
感觉过滤器的选择是个大学问，可以写一篇很长的文章。
欢迎讨论。
2013-02-21 19:46:30
plusman