I’m spending more of my time these days helping other people be effective at security testing applications, and as part of that I’m a huge fan of “over the shoulder” mentoring. Some of the most useful things that I’ve learned from others are not things they thought to mention, but rather those moments of “hey, back up a second — what was that thing you just did?“. Sometimes it’s commands or small utility tools, shortcut keys or capabilities of a program I didn’t know about, or just some quick and dirty technique that someone uses all the time but doesn’t think is special enough to talk about.
To that end, here’s a quick walkthrough of the broad strokes of how I set up Firefox for use in testing. My preferred testing setup is Firefox through Burp: the simplest setup is going to be useful, but there are a lot of small configuration details that can help a stock Firefox become even more of a pentesting asset.
To test authentication and authorization issues you’re really going to need two browsers open at the same time, in different principal contexts (such “User”/”Admin”, “Tenant1″/”Tenant2”, and the ever populated “Unauthenticated”). Then, when you notice something that might have horizontal or vertical privilege issues, you can simple paste the request into the other browser, or swap cookies between your two active browsers. I prefer to run both through the same Burp instance so that I can easily diff or replay between equivalent requests/responses for different principals.
That’s where profiles come in. Normally when you launch Firefox it’ll give you multiple windows that share a common profile; however, if you launch with special command line flags, you can run two completely separate profiles at the same time. To create and manage profiles, launch Firefox Profile manager by adding the Profile Manager flag:
firefox -no-remote -ProfileManager
After creating different profiles, you can create shortcuts to launch them directly, eg:
"C:\path\to\firefox.exe" -no-remote -profile "C:\path\to\Mozilla\Firefox\Profiles\Assess1" "C:\path\to\firefox.exe" -no-remote -profile "C:\path\to\Mozilla\Firefox\Profiles\Assess2"
To keep track of which is which, both visually and in Burp, I add a contrasting color themes (such as blue and red) and use a plugin to ensure that each sends an identifying header (see plugins section).
Firefox Add-On collection that includes a lot of tools mentioned below and that you may find useful during a penetration test.
Some specific plugins you’ll definitely want:
And a couple other pieces of functionality which can be filled by various plugins:
- Manage proxy settings:
- Change User Agents
- Simplify JS and JSON
- Passively detect remote technologies:
- Fetch lots of content at once:
- Interact with REST services:
- RESTClient (although Chrome’s Postman is better, SoapUI is quite serviceable, and Burp will also work)
For Foxyproxy, I like to just blacklist a bunch of domains right in the browser so that they’ll never get passed to the proxy. This keeps the Burp request history cleaner and means I don’t have to make too many assumptions in Burp about what hosts an application will talk to (It also means you won’t have to reconfigure Firefox for each engagement to keep it clean). If the browser is too chatty through Burp you risk losing some valuable information when you rely on “Show only in-scope items”.
When advertising and tracking domains are out of scope, you can also load large lists of advertisers and blacklist those from your proxy to keep the burp state even trimmer.
I use the ModifyHeaders plugin to send a unique header from each browser profile (eg, “BrowserProfile: AssessRed”). This helps me keep track in Burp during my testing, and it can also seriously help with potential client issues when they can easily identify and (hopefully) rule out your traffic as a potential cause of a problem.
Disable Chatty Features
Speaking of chatty features, you’ll probably want to disable a bunch of automatic/implicit traffic that could bloat your Burp state or create red herrings in testing: https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections
You’ll also want to tweak some settings in about:config to prevent both chatty traffic and sending potentially sensitive client URLs to public antimalware lists:
A Few Words on Chrome
You can do a lot of this with Chrome. It supports profiles, has many approximately equivalent plugins, and can be configured to not use the system proxy by installing proxy manager plugins. That said, it feels like you have to work harder to make Chrome play nice in a pentesting environment. YMMV.
Burp Testing Profile
Although it’s not related to Firefox, one thing that I notice biting a lot of people is that they don’t load a consistent profile. Every single new test I do starts with a standard, clean burp state file with all of my preferences loaded in it. I just copy “InitialEngagementBurpState.burp” into my notes directory, load it in, and know that I’m getting all my standard preferences such as autosave (every hour (!) and into a directory that I can regularly clean up), logging, plugin config, etc. I’ve seen colleagues forget this on back to back tests and lose their first day of testing each time because they didn’t manually enable the autosave and hit a crash. (Update Sept 2016: this is less relevant now with Burp’s new project file feature. I’m still figuring out if there are any gotchas in it, but it really helps persisting defaults and making it harder to be dumb.)
What about you?
What did I miss? Some favorite plugin, or special approach? What’s unique about your own setup that you take some pride in?
This is a Security Bloggers Network syndicated blog post authored by Patrick Thomas. Read the original post at: Coffee To Code