若希望从更早前了解BurpSuite的介绍，请访问第三篇（渗透测试之BurpSuite工具的使用介绍（三））：https://www.cnblogs.com/zhaoyunxiang/p/16000725.html
七、Burp Repeater（重放）介绍：
使用 Burp Repeater(Using Burp Repeater)，Burp Repeater是一个手动修改并补发个别 HTTP请求，并分析他们的响应的工具。它最大的用途就是和其他 Burp Suite工具结合起来。你可以从目标站点地图，从 Burp Proxy浏览记录，或者从 Burp Intruder攻击结果上的请求，发送到 Repeater上，并手动调整这个请求来微调对漏洞的探测或攻击。
当你从其他工具上发送请求到 Repeater上时，这些请求会得到它自己的选项。每个选项有自己的请求和响应窗口，以及自己的记录。面板的上半部允许你配置目标的主机和端口，以及请求的细节。你可以手动地完成这些信息，然而当你从其他 Burp Suite工具上发送一个请求时，相关的细节都会为你完成了：
当你配置好一个请求，单击”go”按钮发送它到服务器。响应会在显示窗口的下半部显示出来。对请求和响应二者，许多消息视图是可用的：
raw —这显示纯文本格式的消息。在文本面板的底部有一个搜索和加亮的功能，可以用来快速地定位出消息里的感兴趣的字符串，如出错消息。搜索栏左边的弹出项让你能控制状况的灵敏度，以及是否使用简单文本或者十六进制搜索。
params—对于包含参数(URL查询字符串，cookie头，或者消息体)的请求，这个选项把这些参数分析为名字/值的格式，这就可以简单地随他们进行查看和修改了。
headers—这里是以名字/值的格式来显示 HTTP的消息头，并且也以原始格式显示了消息体。
hex —这里允许你直接编辑由原始二进制数据组成的消息。如果在文本编辑器修改，某种类型的传输(如，MIME编码的浏览器请求)包含了可能损坏的二进制内容。为了修改这类消息，应该使用十六进制编辑器。
HTML/XML —对于包含了这些格式内容的响应，这里提供了一个消息体的颜色语法格式视图。
render—对于包含 HTML或者图像内容的响应，这里会以可见的形式显示出这些内容，就像显示在你浏览器那样。
AMF—对于 Action Message Format格式的请求和响应，显示了一个编码消息的视图树。如果可编辑，你可以双击视图树上的单个节点来修改它们的值。
viewstate—对于包含 ASP.NET ViewState参数的请求，这会把 ViewState中的内容进行反序列化，使你能够查看任何敏感项包含的数据。也指示了 ViewState MAC项是否可用(也就是 ViewState MAC是否可修改)。
在任何请求和响应上，右击它们就会产生一个上下文菜单，来进行下面的操作：
send to—你可以发送任何消息，或者选中的部分消息到其他 Burp Suite工具上，来执行进一步操作或分析。
find references— [仅限专业版]你可以使用这个功能在所有的 Burp工具上来搜索连接到当前项的 HTTP响应。
discover content— [仅限专业版]你可以使用这个功能来发现那些不是连接到由浏览或网络爬虫发现的内容的内容和功能。
schedule task— [仅限专业版]你可以使用这个功能来创建一些在定义的时间和间隔内自动运行的任务。
change request mothod—针对请求，你可以在 POST和 GET之间自动地切换请求方法，并使用相关的请求参数稳定地加载这些请求。这个选项可以用来以潜在的恶意请求来快速地测试到应用程序的极限参数的位置。
change body encoding—针对请求，你可以在应用程序/X—www—form URL编码和multipart/form-data之间进行切换任意消息体的编码方式。
copy URL—这个功能是把当前的完整 URL复制到粘贴板上。
copy to file —这个功能允许你选择一个文件，然后把消息的内容复制到这个文件里。这对二进制内容很方便，然而通过粘贴板会产生一些问题。在选中的文本上进行复制操作，如果什么也没选中，则复制整个消息。
paste from file—这个功能允许你选择一个文件，然后把文件里的内容粘贴到消息里。这对二进制内容很方便，然而通过粘贴板会产生一些问题。粘贴会替换选中的文本，如果什么也没选中，则在光标的位置插入。
save item—这个功能让你指定一个文件用来保存 XML格式的选中的请求和响应，这里包含了所有相关的元数据，如响应长度，HTTP状态码和 MIME类型。
convert selection —这些功能让你能够以各种方案快速地对选中的文本进行编码解码。URL-encode as you type—如果这个选项被打开，则像&和=这样的字符会被你输入的相等的 URL编码替换。
你可以使用<和>按钮来后退和前进浏览当前选项的请求记录，如果需要，可以修改任何请求。
1.选项：
“repeater”菜单控制 Burp Repeater的各方面的行为。你可以创建一个新的空白项，删除一个现有项，或者恢复一个选项的标题来帮助你继续你的工作。如果” update Content-Length header”框被选中，Burp Repeater使用一个特殊请求的 HTTP主体长度的正确值，来更新每个请求的消息头(如果需要可以添加消息头)的内容长度。这个功能在手动修改 HTTP主体时是很有用的，这可能会改变它的长度。HTTP规范和大多数的web服务器都需要使用消息头的内容长度指定HTTP主体长度的正确值。如果没指定正确值，则目标服务器就会返回一个错误，也可能返回一个未完成的请求，或者无限期地等待接收请求的下一数据。
如果” unpack gzip / deflate”框被选中，Burp Repeater在显示之前会把 gzip / deflate格式压缩的内容解压。重定向设置控制着 Burp Repeater是否会跟踪 HTTP重定向(那些有 3XX状态码的和包含新 URL的本机消息头)。
下面的选项是可用的：
1.Nerver— Repeater不会跟踪任何重定向。
2.On-site-only— Repeater只会跟踪同一 web站点的重定向。如，在本地请求中使用的有相同的主机，端口，协议 URL。
3.In-scope only— Repeater会只跟踪那些在 Suite-wide目标范围(定义在目标选项卡)内的 URL。
4.Always— Repeater会跟踪任意 URL。你应该小心地使用这个选项— web应用程序
偶尔会以重定向的方式转发你的请求参数到第三方 web站点，于是通过跟踪这个重定向你不经意间的就攻击了一个不打算攻击的应用程序。当 Repeater接收到一个配置来跟踪的重定向时，它会请求这个重定向(如果需要，最多跟踪 10个重定向，不再多了，这样为了避免无限地循环)。在一个重定向面板上显示了从重定向 URL得到的响应。消息的状态指示出是否跟踪了一个重定向，以及有多少重定向。当应用程序对多种输入都返回一个 3XX响应时，这个跟踪重定向的选项就有用了，因为当请求重定向目标时，会返回应用程序处理你请求的许多感兴趣的特征。例如，当探测常规漏洞时，应用程序会频繁地返回指向错误页面的重定向—这个页面会包含错误本质的有用信息，这可被用来诊断像 SQL注入的问题。如果选中” process cookies in redirects”选项，如果跟踪了一个到相同域名的重定向，则要重新提交任何设置有 3XX响应的 cookie。
注意当 Burp Repeater接收到一个不是配置为自动跟踪的重定向响应，会在 Repeater接口的顶部显示一个” follow redirect”按钮。这允许你查看后，手动跟踪这个重定向。这个功能是用来穿过重定向序列里的每个请求和响应。如果这些选项被设置在上面的”process cookies”配置里，则用这些手动的重定向来处理这些新 cookie。
“action”子菜单包含了和右击请求或响应面板的可用的一样的项。
八、Burp 的Session Handler介绍
会话处理的挑战(Session handling challenges)，当对应用程序进行模糊测试或扫描时，会常常遇到一些问题：
1.应用程序会因为防守或其它原因终止了进行测试的会话，并且其余的测试连续也是无效的了。
2.有些应用程序改变每个请求必须提供的节点(例如，来阻止请求欺骗攻击)。
3.有些功能在测试这个请求之前，需要一系列的请求，才能让应用程序进入一个接收测试。
1.试请求的合适状态：
当你进行手动测试时，所有的这些问题都能产生，并且手动解决这些问题常常显得无聊，这会降低你对下面测试的欲望。
Burp包含了一系列的功能来帮你解决这些情况，让你继续你的手动的和自动的测试，Burp会在后台为照看这些问题。所有的会话相关的配置都可以在主选项卡里的会话选项卡里找到。
Burp的 cookie容器(Burp's cookie jar)
Burp保存了一个追踪 cookie的 cookie容器，这个容器可以用在许多应用程序会话中。这个 cookie容器被所有的 Burp工具共享。响应中设置的 cookie会存储在 cookie容器中，这些 cookie会被自动地添加到即将发送的请求里。
所有的这些都是可配置的，例如，你可以为 Proxy和 Spider接收到的 cookie来更新 cookie容器，以及 Burp会自动地把 cookie添加到 Scanner和 Repeater发送的请求里。在主选项卡里的会话选项卡显示了 cookie容器的配置：
如上面显示的，默认的 cookie容器是依靠 Proxy和 Spider的传输进行更新的。你可以查看 cookie容器的内容并按照自己的意愿来手动编辑 cookie：
除了 Proxy其他的所有工具，都要检查 HTTP响应以确认新 cookie。除了 Proxy，从浏览器进入的请求也被检查。当有个应用程序设置了一个永久 cookie，这个 cookie出现你的浏览器里，并且还需要这个 cookie来适当处理你的会话时，这个会有用了。Burp依据通过代理的请求来更新它的 cookie容器，这就意味着，即使在你访问时应用程序不更新 cookie的值，所有需要的 cookie都会被添加到 cookie容器里。
Burp的 cookie容器遵循 cookie的域范围，用一种方式来模仿 Internet Explorer的解释cookie的处理规范。不需遵循路径范围。
2.会话处理规则：
Burp让你定义了一个会话处理规则列表，这让能完全控制着 Burp是怎样来处理应用程序的会话处理机制和相关的功能。在主选项卡里的会话选项卡来配置这些规则：
每个规则包含了一个范围(规则应用的对象)和操作(规则做什么)。对于 Burp要发送的每一个请求，它决定要使用哪一个规则来处理请求，并且按顺序执行每个规则的动作 (除非条件检查操作确定该请求不需要进一步的处理)。
每个规则定义的范围，是根据处理请求的以下特征而设定的：
1.处理请求的 Burp工具。
2.请求的 URL。
3.请求里的参数名。
每个规则执行的一个或多个动作。实施以下动作：
1.添加会话处理 cookie容器中的 cookie。
2.设置一个特定的 cookie或参数值。
3.检查当前会话是否可用，并有条件地在结果上执行一些子操作。
4.为恢复浏览器的会话提示用户。
5.运行一个宏。
6.运行一个 POST请求宏(这来处理当前请求，并执行下一个宏)。
所有的这些操作都是高度可配置的，可以以任意的方式结合起来处理任何会话处理机制。能运行任意宏(定义在请求队列的)，并能更新结果上的指定 cookie和参数值，允许你通过部分自动扫描或 Intruder攻击来自动重新登录到一个应用程序。恢复浏览器会话提示让你和登录机制一起工作，这些机制有输入物理令牌的一个数字或者解决一个 CAPTCHA类型的难题。
通过创建多个不同范围和操作的规则，你可以为 Burp应用到不同应用程序和功能的行为定义一个层次结构。例如，在一个特殊的测试上你可以定义一下规则：
1.对所有的请求，添加 Burp的 cookie容器里的 cookie。
2.对一个特定域的请求，验证那个应用程序的当前会话是否存活，如果不是，运行一个宏重新登录到应用程序，并且使用结果里的会话令牌更新 cookie容器。
3.对特定的包含__CSRF令牌参数 URL的请求，首先运行一个包含__CSRF令牌值的宏，然后在提出请求时使用。
怎样配置 Burp来完成这些的细节内容将在接下来的部分给大家介绍；
3.宏：
Burp的会话处理功能的关键部分就是运行宏的能力，和定义在会话处理的规则一样。宏是一个单个或多个请求的预定义序列。典型的使用宏的情况有：
1.获取一个检查当前会话是否存活的一个应用程序页面(如用户的主页面)。
2.执行一个包含新的存活会话的登录。
3.包含一个用在其他请求里的令牌或随机数。
4.当在多步处理过程扫描或模糊测试一个请求时，执行必须的先前请求，来让应用程序进入一个接收目标请求的状态。
5.在一个多步处理过程中，攻击请求发出后，完成剩下的处理步骤，以确认要执行的操作，或者从处理结果获取结果或出错信息。
使用浏览器记录下宏。当定义一个宏，Burp会显示一个 Proxy理论记录的视图，从这里你可以为宏来选择要使用的请求。你可以从先前产生的请求里选择，或者重新记录这个宏并且从历史记录选择这个项。
当你记录下这个宏，宏编辑器在宏里显示出这个项的细节，你可以预览，以及按照需要来配置：
和基础的请求序列一样，每个宏都包含了一些重要配置信息，怎样处理序列里的项，以及项之间的相互依存关系：
对于宏里的每个项，可进行以下配置：
1.是否应该把会话处理 cookie容器里的 cookie添加到请求里。
2.从响应里接收的 cookie是否应该被添加到会话处理的 cookie容器里。
3.对于请求里的每个参数，是否应该使用一个预设值，或者使用一个宏以前的响应里的派生值。
4.在更新的参数值里，关键字符是否进行 URL编码。
在一些多阶段处理过程中，从一个先前的响应派生一个参数值的能力通常是很有用的，并且在这种情况下，应用程序能更好地利用逆 CSRF令牌。当定义了一个新的宏，Burp会通过确认由先前响应决定值的参数(构造字段值，重定向目标，查询连接里的字符串，等等)，来自动尝试查找和这一类的关系。你可以在使用宏之前，简单地预览并编辑 Burp使用的宏配置。下面，可以隔离测试配置的宏，以及预览完整的请求 /响应序列，来检查是不是你需要的功能。
4.使用示例：
让我们观察一个只能通过认证会话使用的应用程序功能，以及使用后面的令牌来抵御CSRF攻击。你想测试那些基于输入像 XXS和 SQL注入的漏洞的功能。执行自动测试这个功能，会面临两个挑战：(a)确保使用的会话存活(b)获取每个请求里使用的可行令牌。Burp的会话处理功能能处理这两个挑战。
要做到这样，我要定义一些会话处理规则。这些规则将应用到我们要测试的功能发出的请求上，使用功能的工具是 Intruder,Scanner和 Repeater：
1.通过请求应用程序里的用户登录界面来检查当前会话是否有效，然后检查响应以确认用户是否登录进来。
2.如果没登录进来，重新登录以获得一个有效会话。
3.请求我们将要测试的包含提交的页面。这个格式在一个隐藏的模块里包含了我们需要的逆 CSRF令牌。
4.对我们使用逆 CSRF令牌的值来测试的功能，更新请求。
在大多数情况下，我们需要使用 Burp自己的会话处理的 cookie容器，所以在第一条规则里，我们就告诉 Burp把 cookie容器里的 cookie添加到每个请求里。这样，实际上，也就是 Scanner和 Spider工具的默认规则，于是我们就只修改 Intruder和 Repeater工具的默认规则即可。这规则执行一个操作，在下面显示：
规则的定义的范围来包含相关的工具，并对所有 URL适用：
下一步，我需要检查目标应用程序上的当前用户会话是否可用。假设我想要把这些规则应用到目标应用程序的所有请求上，我可以把它定义在整个应用程序域的范围内：
然后，我们添加一个合适的描述以及一个”check session is valid”类型的操作：
这里打开了这类型操作的编辑器，它里面包含了许多配置项：
选项的第一步设置是确定了 Burp使用哪一个请求来验证当前会话。这些选项是：
1.发送当前正在处理的实际请求。如果应用程序会对有常规响应签名的会话外请求作出回应，如一个登录重定向时，选上这个选项是明智的。
2.运行一个宏，来发送一个或多个请求。如果是为了确认会话是否有效，这就是一个理想的选项，你需要请求一些标准的项，如用户的主页。这个选项也会是最好，在需要使用进一步规则来修改当前处理的请求—例如(像在当前情况下)，更新请求里的逆 CSRF令牌。如果选项是为了运行一个选中的宏，你需要进一步选择是否要对每一个请求或者其中的 N个请求。如果应用程序对未预料的输入会积极地终止响应里的会话，建议你验证每次会话；否则你可以只定期验证会话来加快速度。在当前的实例中，我要运行一个宏来获取应用程序里的用户登录界面，以检测他们的会话是否有效。要这样做，我们需要单击上一截图里的”new”按钮，来定义自己的宏。这里打开了宏记录器，让我们来选择希望包含在宏里的请求。当前状况下，我们只需要选择用户登录页面里的 GET请求：
选项的第二部设置是”check session is valid”操作控制 Burp怎样检查宏里的响应来确定会话是否有效。许多选项是可用的，下面列出了当前情况下我们需要的配置：
在这里，我们使用 cookie容器里的 cookie配置了 Burp进行更新请求，并且在会话有效时，把用户重新登录到应用程序。为完成需要的配置，我们需要定义一个延伸规则来处理在我们要测试功能里逆 CSRF令牌。我们要测试请求像这样：
POST /auth/4/NewUserStep2.ashx HTTP/1.1 Content-Type: application/x-www-form-urlencoded Host: mdsec.net Content-Length: 137 Cookie: SessionId=39DD9F0CB979BFB431005524A4010244 realname=testuser&username=testuser&userrole=user&password=letmein1&confirmpasswor d=letmein1&nonce=938549246127349541173
为确保这个功能正确地处理了我们的请求，需要每个请求提供的随机数有效。在应用程序里的产生上面请求的格式的隐藏区域提供了这个随机数值。因此，我们需要运行一个宏来获取包含这个格式的页面，并使用随机参数值来更新当前请求。我们使用一个有”run macro”类型的操作来添加一个延伸规则，并像下面这样来配置它：
在上面的配置里，我们指定了 Burp应该运行一个新宏，来获取包含逆 CSRF令牌的格式，和从宏响应中获取随机参数，以及在请求里更新。另外，我们可以选择”update all parameters”选项，Burp会自动地尝试请求里的参数和在宏响应指定的值进行匹配。在规则范围内，明显地需要定义在比整个应用程序域更窄的范围。例如，我们可以把这个规则只定义在上面请求里 URL上。如果应用程序只能使用一些位置上的逆 CSRF令牌。然而，在一些应用程序上，许多功能都使用令牌，在这种情况下，令牌会获取到不止一种功能。我们可以定义一个使用所有域的规则，但仅限于包含一个指定参数名字的请求。在这种方法下，无论何时向应用程序提交的请求中都会包含一个逆 CSRF令牌，这个规则执行后，Burp会获取一个新的有效令牌来用在请求上。
这个配置，有它的 3个会话处理规则和 3个宏，在 Burp主界面里就像这样：
你可以通过在应用程序上注销，向 Burp Repeater发送已认证的有令牌保护的请求，来测试配置的运行状况以及确认它是否执行了需要的操作。这些请求可能会花费比平常长的时间才能返回，因为 Burp在幕后提交了许多其他请求，以验证你的会话，如果需要可以再次登录，并获取请求使用的令牌。
如果你发现你的规则不按你打算的方式工作，你可以使用 session handling tracer来解决这个问题。一旦你为会话处理规则正确地运行而感到高兴时，你就可以把这些请求发送到 Burp Intruder或者 Scanner，来以正常地方式执行你的自动化测试。
5.会话处理跟踪器
配置需要把 Burp的会话处理规则应用到现实世界里的应用程序功能上，这往往是很复杂的，并且很容易产生错误。Burp提供了一个跟踪功能，来排除会话处理配置的故障。当Burp把会话处理规则应用到一个请求上时，这里显示了执行的所有步骤，让你清楚地看到怎样来处理和更新请求的。你可以通过 options / sessions / view sessions tracer来打开会话处理跟踪器：
九、Burp工具的集成
关于会话处理功能对一些其他 Burp的功能影响，需要注意以下几点：
1.这里有一个默认的会话处理规则来更新那些由 Scanner和 Spider用 Burp的 cookie容器里 cookie产生的所有请求。这确保了所有 spidering和扫描的请求都是在会话里产生的，并且还使用你的浏览器来维持了一个有效的会话。这也意味着，在主动扫描队列里的项，是从一个稳定文件里加载过来的，并会在你当前的会话里扫描，而不是保存状态文件的那个激活的会话。如果这不是你想要的行为，在执行扫描之前，你应该使这个默认会话处理规则不可用。
2.如遇到会话处理规则在请求发送之前，就把它修改了(例如，更新一个 cookie或其它参数)，一些 Burp工具，为了清晰，会显示出最终更新的请求。这使用在 Intruder,Repeater和 Spider工具。在 Scanner报告里显示发送的请求的同时，还继续显示原来的请求，在需要的地方，就能方便清楚地和基础请求进行对比。为了观察一次扫描发出的最后一个请求，和会话处理器一样，你可以先把请求发送到 Burp Repeater，然后在发送它。
3.当 Scanner或者 Intruder提交一个请求，这请求操纵了一个由会话处理操作影响 cookie或参数时，这个操作不会应用到那个请求上，这是为了避免干扰正在进行的测试。例如，如果你正在使用 Intruder对请求里的所有参数进行模糊测试，并且你已经配置了一个会话处理规则来更新请求里的”sessid”cookie，当 Intruder对其他参数进行模糊测试时，这个”sessid”cookie就会被更新。当 Intruder对”sessid”cookie自身进行模糊测试时，Burp会把”sessid”的值作为 Intruder的有效载荷，并不会更新它，因为它是正常的。
文章来源: 博客园
- 还没有人评论，欢迎说说您的想法！
客服
