备注XSs（备注老公的昵称）

如何通过修改burp suite 中的raw 信息进行渗透测试

刚接触web安全的时候，非常想找到一款集成型的渗透测试工具，找来找去，最终选择了Burp Suite，除了它功能强大之外，还有就是好用，易于上手。于是就从网上下载了一个破解版的来用，记得那时候好像是1.2版本，功能也没有现在这么强大。在使用的过程中，慢慢发现，网上系统全量的介绍BurpSuite的书籍太少了，大多是零星、片段的讲解，不成体系。后来慢慢地出现了不少介绍BurpSuite的视频，现状也变得越来越好。但每每遇到不知道的问题时，还是不得不搜寻BurpSuite的官方文档和英文网页来解决问题，也正是这些问题，慢慢让我觉得有必要整理一套全面的BurpSuite中文教程，算是为web安全界做尽自己的一份微薄之力，也才有了你们现在看到的这一系列文章。

我给这些文章取了IT行业图书比较通用的名称: 《BurpSuite实战指南》，您可以称我为中文编写者，文章中的内容主要源于BurpSuite官方文档和多位国外安全大牛的经验总结，我只是在他们的基础上，结合我的经验、理解和实践，编写成现在的中文教程。本书我也没有出版成纸质图书的计划，本着IT人互联分享的精神，放在github，做免费的电子书。于业界，算一份小小的贡献；于自己，算一次总结和锻炼。

以上，是为小记。

感谢您阅读此书，阅读过程中，如果发现错误的地方，欢迎发送邮件到 t0data@hotmail.com,感谢您的批评指正。

本书包含以下章节内容：

之一部分 Burp Suite 基础

Burp Suite 安装和环境配置

Burp Suite *** 和浏览器设置

如何使用Burp Suite ***

SSL和Proxy高级选项

如何使用Burp Target

如何使用Burp Spider

如何使用Burp Scanner

如何使用Burp Intruder

如何使用Burp Repeater

如何使用Burp Sequencer

如何使用Burp Decoder

如何使用Burp Comparer

第二部分 Burp Suite 高级

数据查找和拓展功能的使用

BurpSuite全局参数设置和使用

Burp Suite应用商店插件的使用

如何编写自己的Burp Suite插件

第三部分 Burp Suite 综合使用

使用Burp Suite测试Web Services服务

使用Burp, Sqlmap进行自动化SQL注入渗透测试

使用Burp、Phantom *** 进行XSS检测

使用Burp 、Radamsa进行浏览器fuzzing

使用Burp 、Android Killer进行安卓app渗透测试

之一章 Burp Suite 安装和环境配置

Burp Suite是一个集成化的渗透测试工具，它 *** 了多种渗透测试组件，使我们自动化地或手工地能更好的完成对web应用的渗透测试和攻击。在渗透测试中，我们使用Burp Suite将使得测试工作变得更加容易和方便，即使在不需要娴熟的技巧的情况下，只有我们熟悉Burp Suite的使用，也使得渗透测试工作变得轻松和高效。

Burp Suite是由Java语言编写而成，而Java自身的跨平台性，使得软件的学习和使用更加方便。Burp Suite不像其他的自动化测试工具，它需要你手工的去配置一些参数，触发一些自动化流程，然后它才会开始工作。

Burp Suite可执行程序是java文件类型的jar文件，免费版的可以从免费版下载地址进行下载。免费版的BurpSuite会有许多限制，很多的高级工具无法使用，如果您想使用更多的高级功能，需要付费购买专业版。专业版与免费版的主要区别有

Burp Scanner

工作空间的保存和恢复

拓展工具，如Target Analyzer, Content Discovery和 Task Scheduler

本章主要讲述Burp Suite的基本配置，包含如下内容：

如何从命令行启动Burp Suite/br

如何设置JVM内存 大小/br

IPv6问题调试

如何从命令行启动Burp Suite

Burp Suite是一个无需安装软件，下载完成后，直接从命令行启用即可。但Burp Suite是用Java语言开发的，运行时依赖于JRE，需要提前Java可运行环境。

如果没有配置Java环境或者不知道如何配置的童鞋请参考win7电脑上的Java环境配置 配置完Java环境之后，首先验证Java配置是否正确，如果输入java -version 出现下图的结果，证明配置正确且已完成。

这时，你只要在cmd里执行java -jar /your_burpsuite_path/burpSuite.jar即可启动Burp Suite,或者，你将Burp Suite的jar放入class_path目录下，直接执行java -jar burpSuite.jar也可以启动。

==注意：your_burpsuite_path为你Burp Suite所在路径，burpSuite.jar文件名必须跟你下载的jar文件名称一致==

如何设置JVM内存 大小

如果Java可运行环境配置正确的话，当你双击burpSuite.jar即可启动软件，这时，Burp Suite自己会自动分配更大的可用内存，具体实际分配了多少内存，默认一般为64M。当我们在渗透测试过程，如果有成千上万个请求通过Burp Suite，这时就可能会导致Burp Suite因内存不足而崩溃，从而会丢失渗透测试过程中的相关数据，这是我们不希望看到的。因此，当我们启动Burp Suite时，通常会指定它使用的内存大小。 一般来说，我们通常会分配2G的内存供Burp Suite使用，如果你的电脑内存足够，可以分配4G；如果你的电脑内存足够小，你也可以分配128M。当你给Burp Suite分配足够多的内存时，它能做的工作也会更多。指定Burp Suite占用内存大小的具体配置 *** 是在启动脚本里添加如下命令行参数： 假设启动脚本的名称为burp_suite_start.bat，则该bat脚本的内容为

java -jar -Xmx2048M /your_burpsuite_path/burpsuite.jar

其中参数-Xmx指定JVM可用的更大内存，单位可以是M，也可以是G，如果是G为单位的话，则脚本内容为：

java -jar -Xmx2G /your_burpsuite_path/burpsuite.jar

更多关于JVM性能调优的知识请阅读 Oracle JVM Tuning

IPv6问题调试

Burp Suite是不支持IPv6地址进行数据通信的，这时在cmd控制台里就会抛出如下异常

java.net.SocketException: Permission denied

同时，浏览器访问时，也会出现异常

Burp proxy error: Permission denied: connect

当出现如上问题时，我们需要修改启动脚本，添加对IPv4的指定后，重启Burp Suite即可。

java -jar -Xmx2048M -Djava.net.preferIPv4Stack=true /your_burpsuite_path/burpsuite.jar

通过 -Djava.net.preferIPv4Stack=true参数的设置，告诉Java运行环境，使用IPv4协议栈进行数据通信，IPv6协议将会被禁止使用。 这个错误最常见于64位的windows操作系统上，使用了32位的JDK

第二章 Burp Suite *** 和浏览器设置

Burp Suite *** 工具是以拦截 *** 的方式，拦截所有通过 *** 的 *** 流量，如客户端的请求数据、服务器端的返回信息等。Burp Suite主要拦截http和https协议的流量，通过拦截，Burp Suite以中间人的方式，可以对客户端请求数据、服务端返回做各种处理，以达到安全评估测试的目的。

在日常工作中，我们最常用的web客户端就是的web浏览器，我们可以通过 *** 的设置，做到对web浏览器的流量拦截，并对经过Burp Suite *** 的流量数据进行处理。

下面我们就分别看看IE、Firefox、Google Chrome下是如何配置Burp Suite *** 的。

IE设置

当Burp Suite 启动之后，默认分配的 *** 地址和端口是127.0.0.1 ：8080,我们可以从Burp Suite的proxy选项卡的options上查看。如图：

现在，我们通过如下步骤的设置即可完成IE通过Burp Suite *** 的相关配置。

启动IE浏览器

点击【工具】菜单，选择【Internet】选项

打开【连接】选项卡，点击【局域网设置】，进行 *** 设置。

在 *** 服务器设置的地址输入框中填写127.0.0.1,端口填写8080，点击【确定】，完成 *** 服务器的设置。

这时，IE的设置已经完成，你可以访问 将会看到Burp Suite的欢迎界面。

FireFox设置

与IE的设置类似，在FireFox中，我们也要进行一些参数设置，才能将FireFox浏览器的通信流量，通过BurpSuite *** 进行传输。详细的步骤如下：

启动FireFox浏览器，点击【工具】菜单，点击【选项】。

在新打开的about:preferences#advanced窗口中，依次点击【高级】-【 *** 】，我们将会看到FireFox连接 *** 的设置选项。

点击【设置】，在弹出的【连接设置】对话框中，找到“http *** ”，填写127.0.0.1，端口填写8080，最后点击【确认】保存参数设置，完成FireFox的 *** 配置。

当然，FireFox浏览器中，可以添加FireFox的扩展组件，对 *** 服务器进行管理。例如FireX Proxy、Proxy Swither都是很好用的组件，感兴趣的读者可以自己下载试用一下。

Google Chrome设置

Google Chrome使用Burp Suite作为 *** 服务器的配置步骤如下：

启动Google Chrome浏览器，在地址栏输入chrome://settings/，回车后即显示Google Chrome浏览器的配置界面

点击底部的【显示高级设置】，将显示Google Chrome浏览器的高级设置。

当然，你也可以直接在搜索框中输入“ *** ”，回车后将自动定位到 *** 服务器设置功能。

点击【更改 *** 服务器设置】，windows系统下将会弹出IE浏览器的 *** 设置，此时，按照IE浏览器的设置步骤，完成 *** 服务器的配置即可。

除了上述的三种常用的浏览器外，还有Safari浏览器也有不少的用户在使用，其 *** 配置请点击阅读进行查看。

第三章 如何使用Burp Suite ***

Burp Proxy 是Burp Suite以用户驱动测试流程功能的核心，通过 *** 模式，可以让我们拦截、查看、修改所有在客户端和服务端之间传输的数据。

本章主要讲述以下内容：

Burp Proxy基本使用

数据拦截与控制

可选项配置Options

历史记录History

Burp Proxy基本使用

通过上一章的学习，我们对Burp Suite *** 模式和浏览器 *** 设置有了基本的了解。Burp Proxy的使用是一个循序渐进的过程，刚开始使用时，可能并不能很快就获取你所期望的结果，慢慢地当你熟悉了它的功能和使用 *** ，你就可以用它很好地对一个产品系统做安全能力评估。 一般使用Burp Proxy时，大体涉及环节如下：

首先，确认JRE已经安装好，Burp Suite可以启动并正常运行，且已经完成浏览器的 *** 服务器配置。

打开Proxy功能中的Intercept选项卡，确认拦截功能为“Interception is on”状态，如果显示为“Intercept is off”则点击它，打开拦截功能。

打开浏览器，输入你需要访问的URL（以为例）并回车，这时你将会看到数据流量经过Burp Proxy并暂停，直到你点击【Forward】，才会继续传输下去。如果你点击了【Drop】，则这次通过的数据将会被丢失，不再继续处理。

当我们点击【Forward】之后，我们将看到这次请求返回的所有数据。

当Burp Suite拦截的客户端和服务器交互之后，我们可以在Burp Suite的消息分析选项卡中查看这次请求的实体内容、消息头、请求参数等信息。消息分析选项视图主要包括以下四项：

Raw 这是视图主要显示web请求的raw格式，包含请求地址、http协议版本、主机头、浏览器信息、Accept可接受的内容类型、字符集、编码方式、cookie等。你可以通过手工修改这些信息，对服务器端进行渗透测试。

params 这个视图主要显示客户端请求的参数信息、包括GET或者POST请求的参数、Cookie参数。渗透人员可以通过修改这些请求参数来完成对服务器端的渗透测试。

headers 这个视图显示的信息和Raw的信息类似，只不过在这个视图中，展示得更直观、友好。

Hex 这个视图显示Raw的二进制内容，你可以通过hex编辑器对请求的内容进行修改。

默认情况下，Burp Proxy只拦截请求的消息，普通文件请求如css、js、图片是不会被拦截的，你可以修改默认的拦截选项来拦截这些静态文件，当然，你也可以通过修改拦截的作用域、参数或者服务器端返回的关键字来控制Burp Proxy的消息拦截，这些在后面的章节中我们会进一步的学习。 所有流经Burp Proxy的消息，都会在http history记录下来，我们可以通过历史选项卡，查看传输的数据内容，对交互的数据进行测试和验证。同时，对于拦截到的消息和历史消息，都可以通过右击弹出菜单，发送到Burp的其他组件，如Spider、Scanner、Repeater、Intruder、Sequencer、Decoder、Comparer、Extender，进行进一步的测试。如下图所示：

数据拦截与控制

Burp Proxy的拦截功能主要由Intercept选项卡中的Forward、Drop、Interception is on/off、Action、Comment 以及Highlight构成，它们的功能分别是： Forward的功能是当你查看过消息或者重新编辑过消息之后，点击此按钮，将发送消息至服务器端。 Drop的功能是你想丢失当前拦截的消息，不再forward到服务器端。Interception is on表示拦截功能打开，拦截所有通过Burp Proxy的请求数据；Interception is off表示拦截功能关闭，不再拦截通过Burp Proxy的所有请求数据。 Action的功能是除了将当前请求的消息传递到Spider、Scanner、Repeater、Intruder、Sequencer、Decoder、Comparer组件外，还可以做一些请求消息的修改，如改变GET或者POST请求方式、改变请求body的编码，同时也可以改变请求消息的拦截设置，如不再拦截此主机的消息、不再拦截此IP地址的消息、不再拦截此种文件类型的消息、不再拦截此目录的消息，也可以指定针对此消息拦截它的服务器端返回消息。

Comment的功能是指对拦截的消息添加备注，在一次渗透测试中，你通常会遇到一连串的请求消息，为了便于区分，在某个关键的请求消息上，你可以添加备注信息。

Highlight的功能与Comment功能有点类似，即对当前拦截的消息设置高亮，以便于其他的请求消息相区分。

除了Intercept中可以对通过Proxy的消息进行控制外，在可选项设置选项卡Options中也有很多的功能设置也可以对流经的消息进行控制和处理。

可选项配置Options

当我们打开可选项设置选项卡Options，从界面显示来看，主要包括以下几大板块（涉及https的功能不包含在本章内容里，后面会一章专门叙述）：

客户端请求消息拦截

服务器端返回消息拦截

服务器返回消息修改

正则表达式配置

其他配置项

客户端请求消息拦截

客户端请求消息拦截是指拦截客户端发送到服务器端消息的相关配置选项，其界面如下：

主要包含拦截规则配置、错误消息自动修复、自动更新Content-Length消息头三个部分。

如果intercept request based on the follow rules的checkbox被选中，则拦截所有符合勾选按钮下方列表中的请求规则的消息都将被拦截，拦截时，对规则的过滤是自上而下进行的。当然，我们可以根据自己的需求，通过【Up】和【Down】按钮，调节规则所在位置和排序。同时，我们可以点击【Add】添加一条规则，也可以选中一条规则，通过点击【Edit】进行编辑、点击【Remove】进行删除。当我们点击【Add】按钮时，会弹出规则添加的输入对话框，如下图：

拦截规则添加时，共包含4个输入项。Boolean opertor表示当前的规则与其他规则是与的方式（And）还是或的方式（Or）共存；Match type表示匹配类型，此处匹配类型可以基于域名、IP地址、协议、请求 *** 、URL、文件类型、参数, cookies, 头部或者内容, 状态码, MIME类型, HTML页面的title等。Match relationship表示此条规则是匹配还是不匹配Match condition输入的关键字。当我们输入这些信息，点击【OK】按钮，则规则即被保存。

如果Automatically fix missing的checkbox被选中，则表示在一次消息传输中，Burp Suite会自动修复丢失或多余的新行。比如说，一条被修改过的请求消息，如果丢失了头部结束的空行，Burp Suite会自动添加上；如果一次请求的消息体中，URl编码参数中包含任何新的换行，Burp Suite将会移除。此项功能在手工修改请求消息时，为了防止错误，有很好的保护效果。

如果Automatically update Content-Length的checkbox被选中，则当请求的消息被修改后，Content-Length消息头部也会自动被修改，替换为与之相对应的值。

*** 安全系统学习要几个月呀？

*** 安全是比较大型的专业，系统学习需要学习很多方面，基本上学透彻的话需要6个月时间左右。

elasticsearch，solr对比各自有哪些优缺点

从两个方面对ElasticSearch和Solr进行对比，从关系型数据库中的导入速度和模糊查询的速度。

单机对比

1. Solr 发布了4.0-alpha，试了一下，发现需要自己修改schema，好处是它自带一个data importer。在自己的计算机上测试了一下，导入的性能大概是：14分钟导入 3092730 条记录，约合 3682条/秒。

2. 3百万条记录的情况下，模糊查询和排序基本都在1秒内返回

3. 刚才的测试，是每个field单独存储，现在修改了一下配置文件，增加了一个copyField，所有的field都拷贝一份到text这个field里面去，导入的性能大概是：19分钟导入了3092730 条记录，约合 2713条/秒

4. 3百万条记录的情况下，针对text的模糊查询基本在1秒内返回，但是针对所有记录的排序，大概要2~3秒

5. 使用 elasticsearch 0.19.8，缺省配置，用单任务导入，导入性能是：20分钟导入了3092730 条记录，约合2577条/秒

6. 3百万条记录的情况下，查询基本上在1秒内返回，但是模糊查询比较慢，之一次要10秒，后来大概要1~3秒。加上排序大概需要5秒，整体排序基本100ms

查询及排序的指令：

{

"query": {

"query_string": {

"query": "*999*"

}

},

"sort": [

{

"TIME_UP": {

"order": "asc"

}

}

]

}

7. Es0.19.8，用两个任务导入，导入性能是：13分钟导入了3092730 条记录，约合3965条/秒

8. Solr全部建好索引后，占用磁盘空间是1.2G，es占用磁盘空间是4G

单机对比2

在一台Intel i7，32G内存的机器上，重新跑这两个的对比。不过有个重大的区别在于，Solr是在这台性能很好的机器上跑，而es的导入进程则是在一台Intel 四核 2.5G，4G内存的机器上跑的，也许会有性能的差异。ES版本0.19.8，Solr版本4.0-ALPHA。

1. Solr的导入性能：3400万条记录，用时62分钟，平均9140条/秒，占用空间12.75G

2. 使用 *999* 这样的模糊查询，3秒以内返回，稍长一点的查询条件 *00100014*，也是2~3秒返回

3. Es的导入性能（设置Xmx为10G）：3400万条记录，用时40分钟，平均14167条/秒，占用空间33.26G，客户端采用4个并发。

4. 使用 *999* 这样的模糊查询，9秒返回，稍长一点的查询条件 *00100014*，11.8秒返回

5. 如果不是针对所有字段查询，而是针对某个特定字段，比如 SAM_CODE: *00100014*，那么也是1秒以内返回。

6. 结论：es的查询效率也可以很高，只是我们还不会用。

7. 结论2：es有个设置是把所有字段放一块的那个，缺省是放一起，但是不知道为什么没起到应有的作用。

备注：

1. Solr之一次的那个内存使用的是缺省设置，这次改为10G，结果导入性能反而变差了，400万条记录，用了8分钟，平均8333条/秒，不知道为什么。

2. 改回缺省的内存配置，导入速度仍然慢。

3. 重启Linux，用10G的内存配置，再导入，5030万条记录，用时92分，约9112条/秒，说明导入速度和内存配置没有大差别

4. 在10G配置的情况下，检索速度也差别不大。

5. 为了搞清楚lucene4.0和solr4.0的进步有多大，下载了solr3.6.1，所幸的是4.0的配置文件在3.6.1上也可以用，所以很快就搭起来进行测试，导入性能为：3400万条记录，用时55分钟，约10303条/秒，占用空间13.85G。查询性能：*999*之一次11.6s，*00100014* 27.3s，相比4.0ALPHA的结果（5000万结果当中，*999*之一次2.6s，*00100014*之一次2.5s）来说，慢了很多，与es的性能差不多，因此，也许lucene4.0真的对性能有大幅提升？

集群对比：

采用4台同样配置（Intel i7，32G内存）的Centos 6.3组成的集群，进行对比。

1. 首先是es，很方便的就组成了一个Cluster，等上一个3400万条的Index全部均衡负载之后进行测试，导入到另外一个Index当中。

2. 导入性能：8500万条记录，用时72分钟，约为19676条/秒。在前5千万条记录导入时的速度在2万/条以上，初始的速度在2.2万/条。占用空间78.6G（由于有冗余，实际占用空间为157.2G）

3. 查询性能：

*999*之一次13.5秒，第二次19.5秒，第三次7.4秒，第四次7.1秒，第五次7.1秒

*00100014*之一次17.2秒，第二次16.6秒，第三次17.9秒，第四次16.7秒，第五次17.1秒

SAM_CODE:*999*，0.8s，1.3s，0.02s，0.02s，0.02s

SAM_CODE: *00100014*，0.1s，0.1s，0.02s，0.03s，0.05s

4. Solr4.0-ALPHA，SolrCloud的配置还算简单，启动一个ZooKeeper，然后其他三台机器访问这个地址，就可以组成一个Cloud：

机器1： nohup java -Xms10G -Xmx10G -Xss256k -Djetty.port=8983 -Dsolr.solr.home="./example-DIH/solr/" -Dbootstrap_confdir=./example-DIH/solr/db/conf/ -Dcollection.configName=xabconf3 -DzkRun -DnumShards=4 -jar start.jar

其他机器：nohup java -Xms10G -Xmx10G -Dsolr.solr.home="./example-DIH/solr/" -DzkHost=192.168.2.11:9983 -jar start.jar

但是在执行 data import 的时候，频繁出现 OutOfMemoryError: unable to create new native thread。查了很多资料，把Linux的ulimit当中的nproc改成10240，把Xss改成256K，都解决不了问题。暂时没有办法进行。

结论

1. 导入性能，es更强

2. 查询性能，solr 4.0更好，es与solr 3.6持平，可以乐观的认为，等es采用了lucene4之后，性能会有质的提升

3. Es采用SAM_CODE这样的查询性能很好，但是用_all性能就很差，而且差别非常大，因此，个人认为在目前的es情况下，仍然有性能提升的空间，只是现在还没找到 *** 。