burp suite Scanner模块详解
分两个阶段，第一个阶段是crawl阶段，第二个阶段audit阶段
这篇文章暂不设计操作层面。
Crawling(爬行)阶段
该阶段的主要任务就是尽可能绘制完整正确的应用“地图”。其中包含浏览应用程序，追踪链接，提交表单和在必要的地方登录等众多子任务，以达到绘制该网络应用程序内容和其中导航路径的目录。
核心方法
在默认情况下，burp的crawler（爬虫，以下称为burp crawler）使用内置浏览器，点击链接且在可能的地方提交输入来浏览目标应用程序。然后以有向表的形式绘制整个web网络程序的内容和功能，既表现了应用程序不同的位置也体现了他们之间的联系。
burp的crawler并不是对目标应用程序的url结构进行猜测。不同模块的位置是根据他们的内容确定的（并且会在之后再次确定），而不是根据到达该板块的url来确定。这确保crawler能可靠地处理当前流行地应用程序中会在url中放置暂时地数据，如CSRF tokens或cache bosters，这样即使每一个链接的url时不时就会改变，burp crawler也会绘制出正确的应用“地图”
该方法同样允许burp crawler使用相同的URL来到达不同的位置，该位置基于程序的状态亦或是用户跟该程序的交互。
当burp crawler围绕整个应用为导向，并建立目标应用程序的覆盖时，burp crawler会跟踪“应用地图”中尚未完成的边，也就是应用中已被监测到但还未访问的链接。但是burp crawler从不会不依据上下文，跳转到一个待定的链接并且访问它。相反，burp crawler要么直接以当前地址为导向进入与之相联系的页面，要么返回最开始的位置，从头开始。总之就是尽可能还原一个真正的用户访问各式各样的网址的操作。
不做假设操作会让burp crawler高效处理当前流行应用程序，但是可能会导致看到过多的内容。现代应用程序常常包含大量多余的导航路径，意味着每一条路径都彼此相联系。burp crawler采取大量技术处理这一问题包括
-
给已经访问过的位置建立链接指纹避免重复访问；
-
以广度优先的原则爬行（内容），即以发现新的内容为优先
-
具有可配置的爬行范围的限制。
session handling（会话处理）
当burp crawler 使用内置浏览器在目标应用程序中‘畅游’时，它几乎可以应付任何会话处理机制这跟当前实际使用的浏览器一样的。这就没有必要录制宏指令或是安装会话处理机制规则来获取一个会话或是验证当前会话是否可用。
burp crawler采用多个crawler 客户端并行化工作。每一个客户端代表一个独立的用户正在浏览各自的浏览器。每一个客户端也都有其独立的cookie盒子，这个cookie盒子会随着应用程序每一次颁发给客户端而更新。当一个客户端从最初的位置重新开始爬行，cookie盒子会被清空，用以模拟一个全新的浏览器会话。
其请求（request）消息也动态地基于应用程序之前的回复（response），所以csrf tokens也是自动使用的。
Detecting changes in application state（检测应用状态变化）
Burp的爬虫能够检测到应用程序状态的变化，这些变化是由于它在爬行过程中执行的动作引起的。
Application login
burp crawler从一个未经验证的阶段开始，在这个阶段中没有提交任何凭据。当这一阶段完成，burp crawler 会发现应用程序中任何登录或是自注册功能。
如果该应用程序支持自注册，burp suite会尝试注册一个用户。我们同样可以给crawler配置一个或多个已有的用户。
Crawling volatile content（爬行易变的页面内容）
Burp的爬虫能够识别许多不稳定内容的实例，并在不同的访问中正确地重新识别相同的位置，尽管响应不同。这允许爬虫将注意力集中在一组应用程序响应中的“核心”元素上，就发现应用程序内容和功能的关键导航路径而言，这可能是最重要的。
Auditing for vulnerabilities（审计漏洞）
审计阶段包括解析该应用程序的流量和行为来识别安全漏洞和其他问题。burp scanner采用各式各样的方法对被扫描的应用程序进行高覆盖率、非常准确的审计。
审计阶段
-
被动阶段
-
主动阶段
-
JavaScript解析阶段
在多个区域执行的每个阶段burp scanner都有如下任务：
-
有效查找和利用需要存储和返回用户输入的功能
-
通过处理经常发生的问题和找到最佳的注入点避免重复
-
并行执行适用的工作，以最有效地利用系统资源
漏洞和其他问题类型
-
被动型：这些问题可以通过检查应用程序的正常请求和响应来检测。
如HTTP消息中的序列化对象。
-
微主动型：这些问题可以通过发出少量良性的附加请求来检测。
如跨源资源分享cross-origin resource sharing （CORS），这一漏洞相信任意的来源。
-
中等主动型：这些问题可以通过发出应用程序可能认为是恶意的请求来检测。
如操作系统命令注入（OS command injection）
-
侵入主动型：这些问题可以通过发出具有破坏应用程序或其数据较高风险的请求来检测。
如SQL注入
-
JavaScript解析型：这些问题可以通过分析应用程序在客户端执行的JavaScript来检测。
如DOM型跨站脚本（DOM XSS）
问题也可以根据发现的级别分为不同的类型
-
主机级别（Host level）：这些问题是主机应用程序正在运行的HTTP服务中出现的。
如被允许的flash跨域策略
-
请求级别（Request level）：这些问题出现在单个请求的级别上。
如跨站请求伪造（CSRF cross-site request forgery）
-
注入点级别（Insertion point level）：这些问题出现在请求中的插入点级别。
如文件路径遍历
浙公网安备 33010602011771号