Posts List

gobuster源码阅读--终篇

在搞完 gobuster 系列源码阅读的第一篇以及dir篇之后,对于 gobuster 的实现思路已经比较熟悉。本文就对剩下的模块进行一个讲解,由于一些公共模块在前面的两篇文章中已经提过,所以本文主要专注于每个模块所独有的部分。 在前面的文章中提到过,gobuster 中的各个模块中的核心功能都是基于 libgobuster/interfaces.go 中接口的实现。而 PreRun 以及 Run 函数则是每个模块实现的核心所在,所以关注其它模块这两个函数的实现的即可。 dns 对于 dns 模块中的 PreRun,其内部也有一个 ErrWildcard 的实现。其实现过程也有一点类似于 dir 模块。通过将 uid 和 domain 进行拼接,理论上这个域名应该不存在,会报一个 no such host 的报错。如果不存在这个报错,则表明对于任意域名都会解析成同一个 IP。如果没有报错,则表明这里可能存在 ErrWildcard。 wildcardIps, err := d.dnsLookup(ctx, fmt.Sprintf("%s.%s", guid, d.options.Domain)) if err == nil { d.isWildcard = true d.wildcardIps.AddRange(wildcardIps) if !d.options.WildcardForced { return &ErrWildcard{wildcardIps: d.wildcardIps} } } 在通过 PreRun 函数之后,即是 Run 函数的实现,这个函数的实现基本上逻辑非常简单,就是解析出域名对应的 IP 即可。 s3 s3 模块主要用于亚马逊云存储桶的包括,里面的实现逻辑比较简单,主要是基于 https://%s.

gobuster源码阅读--入口篇

gobuster 作为一款信息收集工具,深受安全业界的欢迎。希望通过阅读优秀工具的源码,能够了解其工作的具体细节,为自己日后造轮子也做好准备工作。 入口 得益于 Golang 的跨平台属性,其编译过程极其简单,编译的结果直接为二进制程序,可以直接使用,这也是越来越多安全工具选择 Golang 的原因之一。对于每一个 Golang 项目,其根目录下都有一个 main.go 的文件,gobuster 也不例外。 func main() { cmd.Execute() } 这里即是作为程序的入口来展开这次代码之旅。Execute 其实主要是接受程序中断的信号做相应的处理操作,里面的主要涉及的知识点为 context 以及 Signal,前者主要是为了方便程序的取消、退出,后者则是捕获系统中断的信号。Notify 函数负责将 signal 一直传送到管道 c,这个函数可以一直调用。直到调用 sinal.Stop 的时候,signalChan 中的 sinal 则会被清空。这一段代码里面的内容主要是 signal 这一块的内容,可以参考 Golang 的官方文档,里面讲的非常的详细。 func Execute() { var cancel context.CancelFunc mainContext, cancel = context.WithCancel(context.Background()) defer cancel() signalChan := make(chan os.Signal, 1) signal.Notify(signalChan, os.Interrupt) defer func() { signal.Stop(signalChan) cancel() }() go func() { select { case <-signalChan: fmt.

gobuster源码阅读--dir篇

在本系列的第一篇中,主要阅读了 gobuster 入口的这一部分。后续主要是阅读各个模块工作的细节,本文主要讲解 dir 模块。dir 模块主要是实现目录爆破的功能,其主要命令行配置项包括以下内容: Usage: gobuster dir [flags] Flags: -f, --add-slash Append / to each request -c, --cookies string Cookies to use for the requests -e, --expanded Expanded mode, print full URLs -x, --extensions string File extension(s) to search for -r, --follow-redirect Follow redirects -H, --headers stringArray Specify HTTP headers, -H 'Header1: val1' -H 'Header2: val2' -h, --help help for dir -l, --include-length Include the length of the body in the output -k, --no-tls-validation Skip TLS certificate verification -n, --no-status Don't print status codes -P, --password string Password for Basic Auth -p, --proxy string Proxy to use for requests [http(s)://host:port] -s, --status-codes string Positive status codes (will be overwritten with status-codes-blacklist if set) (default "200,204,301,302,307,401,403") -b, --status-codes-blacklist string Negative status codes (will override status-codes if set) --timeout duration HTTP Timeout (default 10s) -u, --url string The target URL -a, --useragent string Set the User-Agent string (default "gobuster/3.

SAST 测试中要测量的三个参数

原文:3 parameters to measure SAST testing 译者:madneal welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 在我们之前的博客中,为什么你不能仅使用列表、测试套件和基准测试来比较 SAST 工具,我们探索了当今常用来评估和比较 SAST 测试工具的各种工具和指标。我们还研究了为什么这些工具可能会产生不一致的结果并且对于评估 SAST 测试工具可能根本不可靠的一些原因。 相反,在评估 SAST 测试工具时,你需要考虑 3 个参数: 准确性 完整性 任意其它独特价值 在本文中,我们将探索这些参数并研究测量它们的方法。在评估 SAST 测试工具时,有两种相关类型的测量 - 定量(意味着结果的数量与“误报”)和定性(特别是语言深度和支持)。 定量方面 以下对准确性和完整性的定义起初有点复杂,因为它们实际上是同一枚硬币的两面。数学上不可能(根据赖斯定理)进行完美的静态程序分析。人们可能会认为增加建议的数量会发现所有可能的问题。可悲的是,这也会将误报 (FPs) 的数量达到干扰让结果无法处理的级别。SAST 测试供应商可以使用一些技巧来改进结果,但在数学上完美是不可能的。 准确性 在 SAST 测试的上下文中,准确性被松散地定义为具有最高数量的 TP(真正类,即实际问题的发现),同时保持最少数量的 FPs(误报,因此是错误的)。 准确性尤其重要。高准确率意味着我们可以获得更有价值的结果,以及更少的“噪音”(不相关的、无法操作的报告)。“噪音”也是阻碍开发者使用 SAST 测试产品的第一大因素,这就是为什么准确性越高,整体开发者体验就越令人满意的原因。 为了计算准确性,你首先需要对结果进行分类。那么公式就是 TP*100/(TP+FP)。这将产生一个介于 1 到 100 之间的数字。数字越大,准确度越高。例如,找到 140 个 TP 和 40 个 FP 的工具的准确率为 77.

hey,我能看到你的源码哎

最近偶然间有看到某家的一个站点中的网站中的前端代码的“泄露”。此处的泄露为什么打引号,因为一般来说网站的前端代码都是可以通过浏览器即可访问。但是一般生产环境中的 JavsScript 代码都是经过压缩和混淆的,所以可读性大大降低,这也提升了从前端的角度挖取更多信息的门槛。这里的泄露指的是在 Chrome 浏览器的 Sources 面板中可以看到完整的以及原始的前端代码。 通过这样的源码,可以非常清晰地了解应用的前端业务,包括接口信息,如果前端包含加解密的逻辑的话,这样也非常有利于攻击者进行破解。 目前市面上绝大多数应用都是前后端分离,基本上绝大多数是基于 Vue 或者 React 这样的前端框架。而大多数应用配套的构建工具则是 Webpack。而这种源码的泄露真是因为 sourceMap 而导致的,但是这种配置在前端开发环境中是必不可少的,因为如果缺少了 sourceMap 那么前端开发者就无法进行前端代码的调试,sourceMap 正是帮助开发者进行前端代码的调试。通常通过 devtool 的配置即可开启 sourceMap,Webpack 会为相应的 js 文件生成对应的 map 文件,在 js 文件的最后一行会有 sourceMap 的申明,表示 map 文件的地址。 module.exports = { ... devtool: 'source-map', ... } 市面上的绝大多数浏览器都是支持 sourceMap 的,Chrome 浏览器默认支持。打开浏览器的开发者工具,在 Sources 面板中的设置可以看到相应的配置项,勾选后即可在面板中看到对应解析的源码。 不过大家可能有一个疑惑,在 Chrome 的 Network 面板中看不到 map 文件的网络请求。但是如果直接使用抓包工具去抓包的话,是可以看到对应的 map 文件的请求的。通过 chrome://net-export 可以捕获请求,通过 https://netlog-viewer.appspot.com/#events 即可查看捕获的日志文件,可以看到对应的 map 文件的请求记录。 毫无疑问,sourceMap 如果在生产环境开启的话,必然具有一定的安全风险,因为从很大程度上帮助攻击者了解应用,获取应用的更多信息。那么,我们是不是可以写一个 Chrome 插件来检测这种问题并且来直接进行源码的下载呢。实现这样的插件不是件很困难的,检测 js 文件请求,然后尝试请求对应的 map 文件。有不少开源库能够进行 sourceMap 的解析,Mozilla 的 source-map 即是一个能够解析 sourceMap 的 js 库,亦可以通过这个库生成 js 的对应的 sourceMap。