This guide is a large summary of the information security tool, FFUF. This is also paired with a video companion guide, shown below:

Understandably, putting this guide and the associated video content together has taken quite a long time (in the order of months, as it’s my first steps into video). Throughout that time some other great creators have put out other content, I heavily recommend watching. This content has inspired this project further, and I don’t think it would be what it is without their input. Notably, and a video I recommend watching in addition to my own for a more complete picture is Katie Paxton-Fear’s How to Use FFUF YouTube video.

关于FFUF你需要知道的一切| 编码 - 图1

Also, a shoutout to Jason Haddix, STÖK, hakluke, InsiderPHD, and Joohoi for helping answer my numerous questions and being a soundboard as I pulled this together.

This guide is a reference point for using a web application security tool, FFUF. If you have a passion for this space, but the guide seems daunting, that doesn’t mean you can’t do this, it just means there’s some prerequisites to dive into first.

A great starting point is:

Health Adams - Linux for Ethical Hackers which will help you to understand the fundamentals of what’s happening here in the terminal, which should allow you to then make use of this guide.

In addition I also recommend Heath’s other content, available on their YouTube channel and I also recommend InsiderPHD’s content as a very good starting point.

Other notable creators well worth watching on your hacking journey include (but certainly aren’t limited to):

  • Jason Haddix and his streams for more tooling insight.
  • LiveOverflow for amazing insights into just how deep this rabbit hole can go
  • Farah Hawa for a variety of hacking guides aimed at beginners
  • The XSS Rat for a range of content from CTF’s to thought process
  • STÖK for the best hacking community orientated content around, and by far the coolest / well centred creator to learn from.
  • TomNomNom because learning to quit vim is vital, and you may learn some other tricks along the way
  • Hakluke for direction on mindset, how to approach bug bounties, and industry insights.

And many more, that I’m sure to have missed, but not intentionally. I love you all.

Who

Being an open source project, FFUF is maintained by the community however notably, it’s founder and principal maintainer, joohoi puts countless hours into driving the project forward. If you FFUF useful, you can support the work here: https://github.com/sponsors/joohoi

What

Firstly, the “what” is quite important. FFUF, or “Fuzz Faster you Fool” is an open source web fuzzing tool, intended for discovering elements and content within web applications, or web servers. What do we mean by this? Often when you visit a website you will be presented with the content that the owner of the website wants to serve you with, this could be hosted at a page such as index.php. Within security, often the challenges in a website that need to be corrected exist outside of that. For example, the owner of the website may have content hosted at admin.php, that you both want to know about, and test. FFUF is a tool for uncovering those items, for your purusal.

Where

FFUF is maintained as public open source, and can be found at: https://github.com/ffuf/ffuf

This means anybody who wishes to contribute to FFUF, can, provided the maintainer (joohoi) accepts and “merges” the contributed changes back to the main project.

Why

Particularly in the bug bounty scene, a lot of people have gravitated towards FFUF since its release. Whilst a good majority of this shift is likely down to the following of the crowd, there is a definite portion of the community who have made the change due to FFUF’s speed, flexibility, and ability to quickly integrate into outside tooling. In addition, the maintenance of the project is top notch, especially when compared to compeitive offerings which although similar in features, lack the same passion and speed to market of new features that FFUF has consistenty shown. All of these things considered, FFUF is a mainstay in any toolkit, and this guide aims to emphasize why that should be, and will likely continue to be the case.

Command Line Driven Applications

FFUF is a command line driven application that runs in the Linux Terminal, or the Windows Command Prompt, meaning that it doesn’t contain an interactive GUI, and is instead powered by inputted command line flags. Whilst this may seem more limiting at first, this lends itself to a higher degree of flexibility as you can make full usage of the tool over remote servers, as well as “pipe” (pass to / from) into and out of FFUF with other command line driven tools. This may feel limiting at first, however I encourage you to follow through this guide to make the most of FFUF, and as you become a more advanced user, you will be able to make the most of this flexibility.

通常，您会听到 FFUF 与dirb或dirbuster 之类的工具进行比较，虽然这在一定程度上是正确的，但并不是一个非常公平的比较。虽然 FFUF 可用于执行目录暴力破解，但它的真正强大之处在于其灵活性，并且应该针对 Burp Suite Intruder 或 Turbo Intruder 之类的东西制作更好的 FFUF 比较工具。我们的目标是在本指南中进一步介绍这种灵活性。

从源安装

如果你想从mainffuf 项目的分支安装最新的稳定版本，你可以这样做：

  1. go get github.com/ffuf/ffuf

安装后，ffuf 将在~/go/bin/ffuf.

从源头升级

就像从源代码编译一样，从源代码升级并不复杂，唯一的变化是添加了-u标志。从源头升级应该通过以下方式完成：

  1. go get -u github.com/ffuf/ffuf

Kali Linux APT 存储库

如果您使用Kali Linux，您会在apt)存储库中找到 FFUF ，允许您通过运行安装sudo apt-get install ffuf，这将显示类似于以下内容的输出：

关于FFUF你需要知道的一切| 编码 - 图2

安装后，您可以使用以下命令验证安装的版本：

如果您还从源代码安装，您会注意到您运行的版本与$GOPATH( ~/go/bin) 中的版本不同。APT 构建通常较旧，但被认为是更稳定的应用程序构建，但因此功能不那么丰富。

其他位置 - Debian Unstable / SNAP 等

随着它的使用越来越广泛，安装 FFUF 的方法越来越多。FFUF 目前流入 Debian Unstable，此外还有一些使用这些源代码的 Ubuntu。它也可以在 Fedora 官方存储库中找到，并且 SNAP 集成目前也在进行中。

什么是目录暴力破解？

在其核心，人们使用 FFUF 的主要功能之一是目录暴力破解。考虑到这一点，让我们模糊一下！在不传递自定义值的情况下（本课程稍后将介绍），FFUF 会将 的值替换FUZZ为您的单词列表的值。

什么是词表？

什么是词表？词表本质上是文本文件中的项目列表，由行分隔，是围绕某个目的量身定制的。

最好的词表集合之一是SecLists。由 g0tm1lk、jhaddix 和 Daniel Miessler 策划的这个系列有一个适合各种场合的词表。

关于FFUF你需要知道的一切| 编码 - 图3

什么是 SecLists？

SecLists 在 Github 上进行管理，因此任何人都可以为这些列表做出贡献，并且拥有如此活跃且众所周知的存储库，这会带来一系列有益的贡献。迄今为止，已有 100 多人为 SecLists 做出了贡献，而且没有放缓的迹象。随着您进一步积累安全知识，如果您充分利用了 SecList，我建议您通过贡献或通过 Github 赞助商支持项目所有者 Daniel 来回馈：https://github。 com / 赞助商 / 丹尼尔米斯勒。

我应该从哪些词表开始？

如果您刚开始从事安全工作，并且不确定从哪里开始使用单词列表，那么 SecLists 中的发现单词列表就是一个好的 / 安全的列表集合，特别是：

随着您在旅程中的进步，请务必重新审视这一点，并研究工具和工作流程的变化，让您既可以为您正在接近的资产使用更量身定制的词表，也可以根据需要围绕目标构建自定义词表从中获取更多信息。

你的第一个目录蛮力

对于这个例子，让我们创建一个简单的词表。在这种情况下，我们会将以下项目放入其中：

将其保存在您打算从中运行 FFUF 的同一位置，作为wordlist.txt.

对于此示例，我们还将对本网站 codingo.io 进行暴力破解。FFUF 有两个我们需要在这里使用的基本参数，第一个-u是目标 URL（在本例中为 codingo.io）。第二个是-w，它是我们希望使用的单词列表文件的路径。如果需要，您可以在逗号分隔的列表中指定多个单词列表。我们还需要将单词FUZZ放在我们想要放置单词列表项的位置。在这种情况下，我们的目标是对新目录进行暴力破解，因此我们将其放在 URL 之后。

总而言之，我们第一个目录暴力的命令将是：

  1. ffuf -u https://codingo.io/FUZZ -w ./wordlist.txt

当我们运行它时，我们应该收到类似于以下内容：

关于FFUF你需要知道的一切| 编码 - 图4

请注意，从我们的三个结果中，有一个返回了结果。在这种情况下，它返回一个301响应代码，表示此处存在重定向。由于没有其他端点对此做出响应，而是选择404页面未找到响应（我们没有设置为匹配和显示），我们应该对此进行调查。这样做会显示以下内容：

关于FFUF你需要知道的一切| 编码 - 图5

恭喜！您刚刚暴力破解了一个网站，并发现了主页本身不存在的第一个端点。

递归本质上是再次执行相同的任务，但在这种情况下，是在另一层。例如，在我们上面的项目中，我们确定了一个管理面板，但是如果我们想在它下面进一步扫描怎么办？一种方法可能是再次扫描，但将我们的 URL 和模糊测试端点更改为以下内容：

  1. ffuf -u https://codingo.io/admin/FUZZ -w ./wordlist.txt

现在虽然这将实现我们的目标，但它不能很好地扩展。在寻找 bug 时，我们可能会发现 20、30 甚至 100 个目录，我们想在另一个层次上探索所有这些目录。

进入，递归。通过设置标志，recursion我们告诉 FFUF 进行扫描，并对其应用另一层。第二个标志，recursion-depth告诉 FFUF 执行此操作多少次（例如，如果我们在 admin 下找到另一层，我们应该继续执行另一层还是停止？）。但是，有一些警告。在 FFUF 中，您不能使用递归的客户模糊测试关键字，并且您只能使用FFUF. 虽然这对于大量应用程序来说无关紧要，但在使用干草叉扫描模式时会限制使用，我们将在后面介绍。然而，这不是一个重要的问题，只是需要注意以备将来参考。

当我们再次运行此命令时，但使用递归标志，我们可以看到以下内容：

  1. ffuf -u https://codingo.io/FUZZ -w ./wordlist -recursion

关于FFUF你需要知道的一切| 编码 - 图6

在这种情况下，发现了 “管理” 项和该 “面板” 下的子页面。

通常，当您找到一个目录时，您还会想要查找该目录的文件扩展名。当存在 zip 文件或同名备份文件时，这对于查找错误非常有用。

FFUF 中的扩展名是用e参数指定的，本质上是您的词表的后缀（因为并非所有扩展名都以 a 开头.）。例如，使用以下内容扩展我们的原始扫描：

  1. ffuf -u https://codingo.io/FUZZ -w ./wordlist -recursion -e .bak

这现在呈现新的热门！如下所示：

关于FFUF你需要知道的一切| 编码 - 图7

默认情况下，FFUF 将只查找单个位置进行 fuzz，按术语捐赠FUZZ。回顾我们的原始示例，这是对目录名称进行模糊处理的方法：

  1. ffuf -u https://codingo.io/FUZZ -w ./wordlist.txt

但是如果我们想对多个位置进行模糊测试呢？这可以通过使用词表定义模糊位置的能力以及使用多个词表来完成。

例如，在下面我们使用术语W1来模糊我们的位置，而不是FUZZ：

  1. ffuf -u https://codingo.io/W1 -w ./wordlist.txt:W1

这与我们之前的示例运行相同的扫描，除了W1现在我们的插入而不是FUZZ. 现在，让我们假设codingo.io我们不想同时检查多个网站。为此，我们可以创建一个包含我们想要测试的所有域的词表，并使用以下内容：

  1. ffuf -u https://W2/W1 -w ./wordlist.txt:W1,./domains.txt:W2

这将domains.txt使用来自 的 wordlist 扫描我们文件中的每个域wordlist.txt，允许我们大规模运行而无需使用外部脚本或应用程序。

单词列表的顺序控制发送请求的顺序。在 clusterbomb 模式（默认）下，ffuf 将遍历整个第一个单词列表，然后再移动到第二个单词列表中的第二个项目。

你想知道为什么这很重要？让我给你举个例子：

假设我们有一个包含 1000 个域的词表domains.txt和一个包含 1000 个目录的词表wordlist.txt。

如果我们运行：

  1. ffuf -u https://FUZZDOMAIN/FUZZDIR -w ./wordlist.txt:FUZZDIR,./domains.txt:FUZZDOMAIN

ffuf 将尝试第一个域的每个目录，然后是第二个域的每个目录。当使用多个线程运行时，这意味着在很短的时间内向同一台服务器发送 1000 个请求。这通常会导致速率受限或被禁止。

另一方面，如果我们交换单词列表的顺序并运行：

  1. ffuf -u https://FUZZDOMAIN/FUZZDIR -w ./domains.txt:FUZZDOMAIN,./wordlist.txt:FUZZDIR

ffuf 将在所有域上尝试第一个目录，然后再转到下一个目录并在所有域上尝试该目录。通过这种方式，您可以发送更多请求而不会使目标服务器过载。

词表参数错误

在旧版本的 FFUF 中，这里有一个错误，即w需要多次使用该标志才能按预期工作。如果您收到错误：

  1. Encountered error(s): 1 errors occurred.
  2. * Keyword W1, defined, but not found in headers, method, URL or POST data.

然后，您应该将 FFUF 升级到最新版本，或者w多次使用该标志，如下所示：

  1. ffuf -u https://W2/W1 -w ./wordlist.txt:W1 -w ./domains.txt:W2

更多信息可以在这里找到：https://github.com/ffuf/ffuf/issues/290

基于 Cookie 的身份验证

通常在执行扫描时，您会希望在身份验证点后面使用蛮力。为此，FFUFb为您提供了传递 cookie 数据的标志。这些不仅限于基于身份验证的 cookie，而且 cookie 的任何区域（从名称到值）也可以使用单词列表进行模糊测试以进行额外的发现。

如果应用程序的身份验证是通过基于 HTTP 标头的身份验证，H则应使用该标志。与b标志一样，这可用于传递或模糊任何标头，而不仅用于传递身份验证所需的元素。

In addition to authentication, or fuzzing points, the H flag can also be utilised in situations where you’re required to “call your shot” by specifying a custom header for a client, or Bug Bounty engagement, so the defensive teams of those organisations can identify your traffic.

More Complex Authentication Flows

Occasionally, you’ll come accross authentication flows or fuzzing situations Burp Suite can’t provide. In those cases, I suggest creating an additional interface in Burp Suite and making use of Burp Suite Macros to acomplish this. Instructions for doing so can be found further on within this guide.

By default FFUF will use 40 threads to execute. Essentially, this means that FFUF will start 40 seperate processes to execute the commands that you’ve provided. It may be tempting to set this much higher, but this will be limited by the power of your system, and the destination system you’re scanning against. If you’re in a network environment, such as HackTheBox, or OSCP then setting this higher may not pose much of an issue. If, however, you’re working on a production system over the internet then you are likely better off spending time tailoring the flags you’re passing to FFUF, and keeping your thread count lower, than trying to acheive a quicker result merely with raw thread count. Various flags you can use to better tailor your requests can be found further throughout this guide.

By default FFUF will strip colour from results (unless you enable it with the -c flag). This makes results easy to pass to other application, for additional work. One challenge here, is the header information, essentially:

  1.  /'___\  /'___\           /'___\       
  2.        /\ \__/ /\ \__/  __  __  /\ \__/       
  3.        \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
  4.         \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
  5.          \ \_\   \ \_\  \ \____/  \ \_\       
  6.           \/_/    \/_/   \/___/    \/_/       
  7.        v1.0.2
  8. ________________________________________________
  9.  :: Method           : GET
  10.  :: URL              : https://codingo.io/FUZZ
  11.  :: Follow redirects : false
  12.  :: Calibration      : false
  13.  :: Timeout          : 10
  14.  :: Threads          : 40
  15.  :: Matcher          : Response status: 200,204,301,302,307,401,403
  16. ________________________________________________

and the footer:

  1. :: Progress: [3/3] :: Job [1/1] :: 0 req/sec :: Duration: [0:00:10] :: Errors: 0 ::

To remove this, and only show results that line up with the matcher filters, you can use the silent flag, -s. This flag will enforce only successful hits to be shown. For example, our command from earlier, if exapnded with -s becomes:

  1. ffuf -u https://codingo.io/FUZZ -w ./wordlist.txt -s

Which will then only show the result:

As that responds with a 301 request, which is within our matcher filters.

Automatically Calibrate Filtering

The ac flag in FFUF can be used to automatically calibrate filtering of requests. This flag tells FFUF to send a number of preflight checks before brute forcing begins and to quantify common elements of those requests for further filtering. For example, FFUF may send random strings, and if each of those responses were a 200 response code, with a common content length, then that content length would be automatically filtered from future results.

Custom Automatic Calibration Filtering

In addition to the ac flag, FFUF allows you to provide the seed request to build autocalibration against, instead of using pre-flight checks. A good example where this shines, is with Virtual Host Scanning. When checking for Virtual Hosts (VHosts), you are seeking responses that don’t match the host request. If we were to do that with acc, we could use the following:

  1. ffuf -w vhostnames.txt -u https://target -H "Host: FUZZ. target" -acc "www"

This would send a preflight check to our target to capture the content-length and response code of www, and then highlight only responses which have a different content length that return from our wordlist. This greatly helps to eliminate false positives, and in these types of cases is more accurate than ac which would use random strings to capture the response, and is unlikely to be as accurate for this type of (and other types of) fuzzing activity.

FFUF can force stop once an error is received, using the sa flag. This overrules any of the other error condition flags (se and sf) as their thresholds would never be met.

Stop on Spurious Errors

FFUF has a flag to allow jobs to automatically stop when a percentage of the recent requests have thrown an error. This flag is se, and will end the job if the last 50 requests have thrown a 403 response code 95% of the time, or if 20% of the responses have been a 429 response code. This can be safer than the flag sf, which will only stop if a portion of the entire request pool have errored, and not just recent requests. These limits may change over time, and are referenced here, should you wish to manually review them: https://github.com/ffuf/ffuf/blob/master/pkg/ffuf/job.go#L382-L407

With production hosts, or under various testing conditions you will need to throttle your responses. When these conditions are required, FFUF provides a number of options.

Delay Between Requests

The p flag specifies the seconds of delay between requests. This can be a range, or a set figure. For example, a p value of 2 would enforce a 2 second delay between each request, whilst a p value of 0.1-2.0 would enforce a random delay between 0.1-2 seconds.

Limited Max Requests/second

As FFUF is a multi threaded application, you can easily end up overwealming a destination target with too many requests. In order to control this, you can specify a maximum number of requests that can be sent per second. This can be set with the -rate flag. For example, if you wish to limit to 2 requests per second, then you would specify -rate 2.

Match on Response Code

There are a variety of predescribed matching options in FFUF, the most common one that you’ll find yourself using is mc, which matches the response code. In many cases, you’ll want to change this to limit to only 200 requests, to help isolate the results to content that you’re seeking.

Match on Regular Expression

In some cases, however, you may be fuzzing for more complex bugs and want to filter based on a regular expression. For example, if you’re filtering for a path traversal bug you may wish to pass a value of -mr "root:" to FFUF to only identify successful responses that indicate a successful retreival of /etc/passwd. Such cases are quite common, and highlight some of the power that FFUF brings into fuzzing that competitive offerings are not yet able to match.

As useful as matches are, filters being the inverse of matches can be just as, if not more useful. When returning the results of a page that has a sink (a location where your source, or wordlist item is reflected in the page) within the response, it can be more useful to filter the number of words in a page, rather than filter by content length. For this purpose, FFUF provides fw, or filter words. If you can identify the number of words commonly in the response, you can apply this filter to remove any results that have your content length. If words aren’t specific enough, you can also filter on the number of lines within the HTTP response, using fl.

Much like filters, you can also filter based on content length (fc) to remove response types from the results. This can be especially useful where you want to first filter for all defaults, which includes the 301 response code, and then filter this response code out from the results to see more specific responses.

For a variety of reasons, you’ll often find yourself wanting your FFUF scans to be sent via Burp Suite. Notably, there’s a few ways to acomplish this goal, and it’s important to understand each of them, and apply the right one for your use case.

Locally, Using Replay Proxy

FFUF has a command within it, replay-proxy to dictate. This will retoute successful commands (ones that hit your matches, and not your filters) to Burp Suite proxy for further investigation. Notably, this does mean that you’re doubling your requests, and this should be used in situations where it makes sense to do so.

If for whatever reason (such as engagement terms) you need to send all information via Burp Suite, and not just successful traffic, then you can instead use x which will replay all requests via a Burp Suite project, regardless of whether they line up with FFUF filters/matches or not.

Using an Interface

Occasionally, you’ll encounter situations where you need all of your FFUF (or another tools) traffic to be send via Burp Suite over a Burp Suite Interface. This could be due to engagement logging (required by the firm you’re testing for/against), or due to a complex authentication schema that Burp Suite is better positioned to handle. Personally, I’ve also found this useful for fuzzing various elements (such as CSRF tokens) in conjunction with Burp Suite Macros. Whatever the use case, the method for doing this is quite simple. Firstly, we need to go to Burp Suite and setup a second interface, you can do this under proxy->options->add

关于FFUF你需要知道的一切| 编码 - 图8

Under binding, set a port, for the second interface I prefer to use 8181 (as 8080 is the default and I find this easy to recall).

关于FFUF你需要知道的一切| 编码 - 图9

Under the request handling flag, set “Redirect to host” and “Redirect to port” to match that of our destination target:

关于FFUF你需要知道的一切| 编码 - 图10

After we’ve done that, leave other settings the same and click ok. We can then target https://127.0.0.1:8181 with any of our tools, including FFUF, and it will automatically redirect to the destination target. This means, instead of using http://target.com/path/FUZZ in FFUF to focus on our target, we can use https://127.0.0.1:8181/path/FUZZ. Everything will work as it did before, except the requests are being sent to, and out from Burp Suite.

Be cautious when using this approach on large wordlists, as Burp Suite will store the history within your associated project, and passing large fuzzes via Burp Suite is likely to cause your project file to become bloated, and unwieldy quickly.

Remote VPS Traffic via a Reply Proxy

When using a remote VPS you’ll occasionally hit decisions in your testing that would be aided by using a local version of Burp Suite. To help aid in this, when fuzzing with FFUF you can open a reverse SSH tunnel and combine it with reply-proxy on your remote VPS to replay it over the remote port, to your local Burp Suite instance.

First connect to your remote VPS over SSH server using:

  1. ssh -R 8888:localhost:8080 user@remotevps

And then run FFUF with the following:

  1. ~/go/bin/ffuf -u http://codingo.io/FUZZ -w ./wordlist -replay-proxy http://127.0.0.1:8888

Since we bound port 8888 to relay over our reverse SSH tunnel to our remote burp instance, on port 8080, this will then replay back in Burp Suite.

When using multiple wordlists, FFUF has two modes of operation. The first, and the default, is clusterbomb. This takes both wordlists and tries all possible combinations of them, and is best for brute forcing operations. By default FFUF will use the clusterbomb attack mode, however you can specify other modes (for now, just pitchfork and clusterbomb) using the mode flag.

For example, let’s assume we had a wordlist called “users”, with two users, “codingo” and “anonymous”. In addition, we’ll assume we have a wordlist “passwords”, with two items, “hunter1”, and “password”. In clusterbomb mode, all combinations of these would be tried, resulting in the following output.

Alternatively, FFUF provides another mode called “pitchfork”. This mode is intended for when you want to use wordlists in series. For example, let’s assume that you have a list of passwords, that go with a list of users and want to fuzz via a username and parameter endpoint. In this example, the password “hunter1”, would be tried with the user “codingo”, and the password “password” would be tried with the user “anoymous”, however that would be the end of the operation, and further combinations would not be tried.

Each has its own use cases, and it’s important to know how to use both, however if you’re unsure which to use, it’s best to stick with the default, clusterbomb.

Clusterbomb

Most useful for a brute-force attack style, the clusterbomb will try all combinations of payloads. As Burp Suite Intruder operates with the same kind of wordlist approaches, I’ve found this is best explained by Sjord, here. To paraphrase Sjord, essentially the clusterbomb tries all possible combinations, while still keeping the first payload set in the first position and the second payload set in the second position. As shown in the following example:

关于FFUF你需要知道的一切| 编码 - 图11

Here we can see that the first payload position is used in position one, 456. And the second, in postion two, <br. The first payload is then rotated, whilst the second isn’t, until the first list has been exhausted at which time the second list continues through the same operation. Operating in this style ensures that all possible permutations are tested.

Pitchfork

Much like the Clusterbomb approach, I’ve found the Pitchfork style of fuzzing is also best explained by Sjord, here. To paraphase, the pitchfork attack type uses one payload set for each position. It places the first payload in the first position, the second payload in the second position, and so on. This attack type is useful if you have data items that belong together. For example, you have usernames with corresponding passwords and want to know whether they work with this web application.

关于FFUF你需要知道的一切| 编码 - 图12

As you can see when compared to the clusterbomb atack, the pitchfork attack works the wordlists in series. Not all combinations will be reached, but the use case for these is that they aren’t intended to and doing so would be a waste of requests.

HTML Output

Using Silent and Tee

If you want to print results only, without all of the padding, the s flag, or silent mode, works great for this. For example:

  1. ffuf -request /tmp/request.txt -w ./wordlist.txt -s

With our original example, will only output admin, as it’s the only successful match. This can also be useful to pass to other tools, however when doing so I suggest also using tee). The tee command will output the results to console, whilst also redirecting it as stdout, allowing other applications to consume it. For example, the following:

  1. ffuf -request /tmp/request.txt -w ./wordlist.txt -s | tee ./output.txt

Would output to the console and write to output.txt. This is a useful trick for a number of tools, including those that don’t stream output, to allow you to see results in realtime, whilst also streaming them to a file.

On of the easiest ways to work with complex queries is to simply save the request you’re working with from your intercepting proxy (such as Burp Suite), set your fuzzing paths, and then import it into FFUF for usage. You can do this with the request flag in FFUF, as explained below.

Going back to our original fuzzing example, let’s assume we visited codingo.io in Burp Suite, and we captured the following request:

关于FFUF你需要知道的一切| 编码 - 图13

We can right click in the request, and select Copy to File:

关于FFUF你需要知道的一切| 编码 - 图14

Be sure not to select Save item as that will save this in a format known only to Burp Suite, and not of use to FFUF.

Once we’ve saved the file, we then need to open it in our favorite editor, and add our fuzzing points. For this example, I want to brute force items at the top level of the codingo.io domain and so I’m adding FUZZ on the top line, as shown below:

关于FFUF你需要知道的一切| 编码 - 图15

We can then open our request in FFUF, and instead of passing cookie information or a URL, we can use request to feed it the information in our saved request. In this case, this would look like the following:

  1. ffuf -request /tmp/request.txt -w ./wordlist.txt

This guide is open source, maintained on Github. If you’d like to contribute to this guide, or to make a correction, you can do so here: https://github.com/codingo/codingo.github.io

Contributors

The following authors have contributed to this guide:

Date Contributor Twitter Description
17 Sep 2020 codingo https://twitter.com/codingo_ 初稿 / 出版
2020 年 9 月 28 日 p4fg 不适用 添加了有关对多个域进行模糊测试的其他提示

https://codingo.io/tools/ffuf/bounty/2020/09/17/everything-you-need-to-know-about-ffuf.html