Automated HTTP Requests

[JonCooperWorks]

Hey, this is a cool project. I wrote a Go HTTP fuzzer (https://github.com/JonCooperWorks/httpfuzz) that could be a quick drop in to the Hetty. The only issue is the UI. What did you envision it looking like?

[dstotijn]

Hey, thanks! I'll have a look at httpfuzz. How does it relate/compare to ffuf? I saw you use Go plugins; what is your experience with it? Any caveats/gotchas?

I haven't investigated/thought about the UI for an "Attacker" module yet. I'm still gathering all the feedback I've received today and once the dust settles a bit I'll do some thinking and start writing some proposals for next steps.

[JonCooperWorks]

It's comparable to ffuf, but it automatically generates files and makes file upload fuzzing a bit easier with custom payloads. ffuf is definitely a more mature project though, I just started writing httpfuzz last month, and haven't released v0.0.1 yet. I'm still testing it against real targets. I see they use filters in CLI args, but I intended for plugins to do filtering. ffuf takes cURL style CLI args, whereas httpfuzz takes a text seed request (or a http.Request if used as a library).

In terms of Go plugins, they're pretty straightforward. No gotchas I've seen apart from plugins need to be compiled against the same version of the program they'll be loaded into. I've been considering moving my plugin code into a separate package to get around this. They're pretty simple to implement. My plugin handling code is 108 lines including comments (https://github.com/JonCooperWorks/httpfuzz/blob/master/plugin.go) and it's mostly to keep the program running until the last plugin finishes and send messages to loaded plugins.

Plugin authors only need to know about the Result, InitializerFunc and Listener types to create a plugin.

// Listener must be implemented by a plugin to users to hook the request - response transaction.
// The Listen method will be run in its own goroutine, so plugins cannot block the rest of the program, however panics can take down the entire process.
type Listener interface {
	Listen(results <-chan *Result)
}

// InitializerFunc is a go function that should be exported by a function package.
// It should be named "New".
// Your InitializerFunc should return an instance of your Listener with a reference to httpfuzz's logger for consistent logging.
type InitializerFunc func(*log.Logger) (Listener, error)

// Result is the request, response and associated metadata to be processed by plugins.
type Result struct {
	Request     *Request
	Response    *Response
	Payload     string
	Location    string
	FieldName   string
	TimeElapsed time.Duration
}

I could write a httpfuzz.Listener that sends results back to the UI. httpfuzz can be embedded as a Go library, so it should be pretty straightforward. All you have to do is create an httpfuzz.Config and pass it to the httpfuzz.Fuzzer.

// Config holds all fuzzer configuration.
type Config struct {
	TargetHeaders             []string
	TargetParams              []string
	TargetPathArgs            []string
	TargetFileKeys            []string
	TargetMultipartFieldNames []string
	FilesystemPayloads        []string
	TargetFilenames           []string
	LogSuccess                bool
	EnableGeneratedPayloads   bool
	FuzzFileSize              int64
	FuzzDirectory             bool
	Wordlist                  *Wordlist
	Seed                      *Request
	Client                    *Client
	RequestDelay              time.Duration
	Plugins                   *PluginBroker
	Logger                    *log.Logger
	URLScheme                 string
	TargetDelimiter           byte
	waitGroup                 sync.WaitGroup
}

All of those fields can be populated from the UI, except the sync.WaitGroup, which you don't need to worry about. The fuzzer uses that internally to keep the fuzzing goroutine open until all requests send.
See https://github.com/JonCooperWorks/httpfuzz/blob/master/config.go and https://github.com/JonCooperWorks/httpfuzz/blob/master/fuzzer.go