> (I am, for what it's worth, extremely familiar with Burp, but only casually acquainted with mitmproxy).
You may be disappointed, since I am the opposite. I use burp in rare cases now, since I've been using mitmproxy for so long.
>That's interesting to me. Can you describe your Burp workflow, and how you accomplish the same things in mitmproxy?
You may also be disappointed on how my methodology might differ. I work for a shop that performs grey-box (authenticated) web application tests that focus on manual comprehensive coverage. So my work flow goes something like this:
- Manually walk the entire authenticated application, or designated portion. Populating all areas and using all application functionality.
- Analyze mitmproxy logs to identify all application entry points, and other OWASP areas of interest. (mitmproxy's "Limit" feature makes this fast and easy)
- Manually Test every endpoint, or other item, by duplicating the request, editing, and resending.
This is pretty basic, so I'm sure you see how this could be done with burp's repeater and intruder, which were the main areas I used.
In mitmproxy you can easily duplicate a flow, edit it, and resend it. Then, based on the response, resend it again. That's what I do for API testing, for web application testing it is usually closer to:
- Stage requests in Hackbar on Firefox and send the request, which goes through mitmproxy.
- Use Mitmproxy for fine-tuning anything, watching the details, and scripting the tedious.
> One of the things we're doing this year for our clients is selling them on the idea of doing basic security integration testing as part of their normal dev process, which might involve these companies buying copies of Burp for their team. But I could probably be convinced that mitmproxy would work just as well.
My basic common work flow is probably not very helpful in this case, but I think mitmproxy could still be very helpful to you. You probably know that mitmproxy can replay a series of requests, and has a great scripting API. I think these two features could be used together to meet a lot of your needs. Let me tell you about some of my experiences:
In some cases a customer just can't get their fix quite right, so I will need to repeatedly perform a series of tedious steps to retest an issue. So, I automate the process by using mitmproxy to save a file of the steps involved in testing the vulnerability. This may be something like:
Then, I can pass this to mitmdump to be replayed, with sticky-cookies enabled, and I just watch the output to make sure the output is correct.
As far as scripting goes, you may be interested in cases where I wanted to quickly test every input parameter for input validation of a list of characters. The script I wrote would be run on every request I made to the site I was testing, if it was a post request it would do the following:
- Duplicate the request for every POST parameter in the request
- Inject the list of characters in to the post parameter
- Run/Replay the new request
Hopefully you can make sense of my examples. I think by replaying request, or writing simple testing scripts, you could automate a lot of the basic security integration testing.
The beautiful thing about mitmproxy is that it has a simple, powerful, scriptable, core. By using the powerful building-blocks it's provided I can make it do whatever I want it to do. But, it may require a little python scripting.
Let me know if want additional attempts at clarification.
For what it's worth, the approach you take with web applications is pretty much the same as the one used by all the high-end software security firms (certainly Matasano, iSEC, Leviathan, and Bishop Fox). Out on a limb, I'd say every consultant at every one of those firms gets a copy of Burp.
The walk/filter/replay workflow you're talking about is one Burp is built around --- that's the Proxy History, "Send To Repeater", and "Repeater" features.
Regarding software teams at startups: I totally buy that mitmproxy is more scriptable than Burp (it doesn't hurt that most of the people we're working with in 2017 are Python shops). But I used Intruder a lot when testing, and I'm not sure I'd want to lose that; I think there's a lot of value in the sort of but not quite random fuzzing Burp is good at doing, for serendipity finds.
You may be disappointed, since I am the opposite. I use burp in rare cases now, since I've been using mitmproxy for so long.
>That's interesting to me. Can you describe your Burp workflow, and how you accomplish the same things in mitmproxy?
You may also be disappointed on how my methodology might differ. I work for a shop that performs grey-box (authenticated) web application tests that focus on manual comprehensive coverage. So my work flow goes something like this:
This is pretty basic, so I'm sure you see how this could be done with burp's repeater and intruder, which were the main areas I used.In mitmproxy you can easily duplicate a flow, edit it, and resend it. Then, based on the response, resend it again. That's what I do for API testing, for web application testing it is usually closer to:
> One of the things we're doing this year for our clients is selling them on the idea of doing basic security integration testing as part of their normal dev process, which might involve these companies buying copies of Burp for their team. But I could probably be convinced that mitmproxy would work just as well.My basic common work flow is probably not very helpful in this case, but I think mitmproxy could still be very helpful to you. You probably know that mitmproxy can replay a series of requests, and has a great scripting API. I think these two features could be used together to meet a lot of your needs. Let me tell you about some of my experiences:
In some cases a customer just can't get their fix quite right, so I will need to repeatedly perform a series of tedious steps to retest an issue. So, I automate the process by using mitmproxy to save a file of the steps involved in testing the vulnerability. This may be something like:
Then, I can pass this to mitmdump to be replayed, with sticky-cookies enabled, and I just watch the output to make sure the output is correct.As far as scripting goes, you may be interested in cases where I wanted to quickly test every input parameter for input validation of a list of characters. The script I wrote would be run on every request I made to the site I was testing, if it was a post request it would do the following:
Hopefully you can make sense of my examples. I think by replaying request, or writing simple testing scripts, you could automate a lot of the basic security integration testing.The beautiful thing about mitmproxy is that it has a simple, powerful, scriptable, core. By using the powerful building-blocks it's provided I can make it do whatever I want it to do. But, it may require a little python scripting.
Let me know if want additional attempts at clarification.
edited for formatting