Bambda这个东西，它本质上就是一种可以直接在Burp Suite界面里面跑的Java脚本，用来按照你自己的测试习惯，去扩展过滤、匹配、展示还有处理的逻辑，它比较适合用在像HTTP历史记录的筛选、WebSocket记录的筛选、自定义列，还有匹配替换规则这一类的场景里面。

　　一、Bambda规则该怎么写

　　在动手去写一条Bambda规则之前，要先把它将来要跑在哪个地方给弄清楚，因为不同的地方，它能拿来用的输入对象，是不一样的，像HTTP历史记录的过滤、WebSocket的过滤、自定义的列，还有匹配替换的规则，这几个地方可不能随随便便地就混着用同一段代码。

　　1、先把要用在哪个位置给选好

　　要是想筛选请求的记录，那就进到代理功能的HTTP历史记录里面，去把过滤器里那个脚本的选项给打开；要是想做匹配替换，那就得进到代理功能的匹配替换规则那里去；要是想集中管理自己写的这些脚本，就可以去扩展功能的Bambda库里面找，根据官方文档的说明，这个库是可以用来创建不同类型的脚本的，而且，也可以从一个内置的模板开始写起。

　　2、优先从一个模板开始创建

　　去点一下新建的按钮，然后选择从模板创建，挑一个跟自己当前要干的场景比较接近的模板，再点一下用这个模板来创建的按钮，对于新手来说，最好不要直接从一张白纸开始写起，因为不同类型的脚本，它需要返回的结果是不一样的，像过滤那一类的脚本，它通常就是返回一个真或者假；而自定义列那一类的脚本，它返回的，就是你想要显示出来的那个内容。

　　3、用那种清楚的判断条件来写规则

　　比如说，要筛选出状态码是五百的响应、筛选那些请求头里包含某个特定字段的请求、筛选出路径里带着管理字样地址、或者是筛选出返回的数据包里，包含了某个JSON字段的接口，这些都可以被写成一条条很明确的条件判断，一条规则，不要一上来就写得太复杂了，先让一个单一的条件能跑通了，然后再一步一步地，往里面去增加像方法、路径、状态码、内容类型这些条件。

　　4、去点一下应用，来检查一下语法

　　写完了之后，去点一下应用的按钮，这个时候，Burp就会去编译并且测试一下这段脚本，要是语法上有什么问题，它就会在编辑器里面用红色给标出来，或者是会在编译错误的那个面板里面，把错误给显示出来，官方的文档里也提到过，在工具自带的那个脚本编辑器里，点了应用之后，就可以去查看编译的错误；在Bambda库里面，点了保存，也同样会把对应的错误给显示出来。

　　二、Bambda的执行结果要怎么查看

　　Bambda执行出来的结果，得看它被用在了什么地方，过滤脚本的结果，会体现在记录的列表是不是被筛了出来；自定义列脚本的结果，会体现在表格里多出来的那一列上；而匹配替换脚本的结果，则会体现在代理转发的请求，或者是响应发生的变化上。

　　1、过滤那一类的结果，就去看列表的变化

　　在HTTP的历史记录里面，应用了Bambda过滤之后，那个列表里，就会只显示符合你设定条件的那些记录了，要是一条记录都没有显示出来，先别着急就认定是这个规则失效了，可以先把一部分的条件给清掉，只留下一个非常简单的判断去测一下看看，比如说，就只去判断请求的方法，或者是状态码。

　　2、自定义的那一列，就去看表格里的字段

　　要是Bambda是被用来添加一个自定义列的，那么在把它保存并且启用了之后，就要回到对应那个历史记录的表格里面，去看一看新出来的那一列，它的内容到底对不对，如果那一列是空着的，那通常就说明，是脚本没有取到对应的那个字段，或者是目标的那条记录本身，它就没有那个请求头、参数，或者是响应的内容。

　　3、匹配替换的那一类，就去看请求发生的变化

　　那种用来做匹配替换的Bambda，是要等到代理的流量经过了Burp的时候，才会体现出来的，这个时候，可以打开HTTP的历史记录，去对比一下，在修改之前和修改之后，请求头、请求体，或者是响应体里面的内容，到底有什么不一样，如果有必要的话，还可以把那条请求，发送到重放器里面去，用一种更稳定的方式，去反复地验证一下。

　　4、出了错的结果，就去看编译和运行的提示

　　编译时候的错误，通常就是Java的语法、对象的类型，或者是返回值的类型，写的不对；而运行时候的异常，则有可能是某些请求，它压根儿就没有响应体、某个字段的值是空的、或者是字符的编码，跟你心里想的不一样，在排查的时候，可以先加上对空值的判断，然后再一步一步地把那些复杂的逻辑，给恢复回来。

　　三、Bambda的规则该怎么整理

　　当Bambda的规则写多了以后，就要去注意一下命名和分类的问题了，不然的话，到了后期，这些东西就会变成一堆根本看不懂的小脚本了，尤其是在那种好几个人一起合作，或者是周期很长的项目里面，对规则的管理，要比临时能让它跑通，要重要得多。

　　1、按照它的用途来起名字

　　给脚本起名字的时候，最好是能把它的用途给写清楚了，就比如，是用来筛选出五百响应的、提取某个字段的、标记JSON接口的、或者是修改测试用的请求头的，可千万不要只给它起一个像测试、过滤一、新建规则这样的名字，不然到了后面，就很难去判断，这条规则到底能不能被再拿来用一次。

　　2、保存到Bambda库里面去

　　那些经常会被用到的规则，就可以去点一下那个保存到库的按钮，把它们给存起来，这样，后面再开别的项目，或者是进到别的兼容工具里的时候，还可以继续去加载它们，官方的文档里也提到过，脚本是可以被保存到Bambda库里面去的，并且在Burp里面，不同的兼容工具，也都可以去用它。

　　3、从外面导入规则的时候，要小心一点

　　在从一个外部的文件，把它给导入进来之前，一定要先确认清楚，这个来源是不是可靠的，官方的导入文档里也提醒过，Bambda脚本是有可能去执行任意的代码的，所以，可千万不要随随便便地就去运行一个，还没有被验证过来源的脚本。

　　4、那种很复杂的逻辑，要及时地把它给拆开

　　要是在一个Bambda脚本里面，又让它去判断路径，又让它去解析参数，又要去修改请求头，还要去提取响应，那么等它一出错，再想去定位问题，就会非常困难了，一种更加稳妥的做法，是按照不同的用途，把它给拆成好几个小规则，要是以后真的需要更复杂的能力，那个时候，再考虑去写一个完整的Burp扩展。

　　总结

　　关于BurpSuite的Bambda规则要怎么去写，还有写完了以后，执行的结果又要去哪里看，这里面很关键的一点，就是要先把使用的那个位置给选对了，然后再从一个模板开始，去写一小段范围比较小的判断，写完了以后，去点一下应用，看看编译出来的结果是什么，而执行的效果呢，是要回到它对应的那个功能里面去观察的，过滤的规则，就去看列表的变化；自定义的列，就去看表格里多出来的那一列；匹配替换的规则，就去看代理流量发生的变化，等规则稳定下来了以后，就把它给保存到Bambda库里面去，并且，按照它的用途来命好名、分好类，这样，后面再想去找回来用，或者是排查问题的时候，就会省下很多的时间了。