How to stop Fiddler 2 from logging requests made from web browsers and other applications? - fiddler

I would like to use Fiddler 2 to make GET and POST requests and to analyze the responses, but it's made almost impossible because of how many other requests it logs from internet browsers and other applications.
How can I get Fiddler to only show requests that I made inside of it, along with the responses to those requests?

There are many ways to filter traffic by process in Fiddler; a simple search on any major search engine will turn up all of them.
For your needs, however, you simply don't want Fiddler to be the system proxy. Hit F12 or untick File > Capture Traffic; no other client will then send its traffic to Fiddler.
If you only ever care about requests from the Composer, click Tools > Fiddler Options and untick "Act as System Proxy on Startup" on the Connections tab.

Related

How to enable "streaming mode" in ZAP?

I am using zap as a proxy and I can't seem to find a way to allow applications connected to ZAP Proxy to stream content.
In another app, fiddler 4, there is an option to enable streaming mode. By default, fiddler 4 fully buffers content it receives from the server before forwarding to the requesting application. Now this becomes a problem when download sizes are big and the requesting application needs immediate response from the server. Now, the streaming mode in fiddler solves this problem by forwarding pieces of the content to the requesting application. Fiddler is only on windows but I use Linux, and fiddler everywhere still lacks features I need.
Now ZAP has the features but it buffers content.
Is there a way for OWASP ZAP to enable streaming mode?
Not at the moment I'm afraid. But you can approach to the ZAP team and open a new Feature Request so they can keep that need in mind for future releases.

Random sessions using Fiddler

all,
I use Fiddler for developing and debugging Web apps, and I find that random stuff shows up in the list of "sessions" after I turn off Capture Traffic. It's perhaps a few items every ten or fifteen minutes. I know this is a really broad question, but is there some way to figure out why these things are showing up and what they are?
Thanks!
The Capture Traffic setting controls whether or not Fiddler is registered as the system's proxy server. Most clients (Internet Explorer, etc) will react to the system proxy setting at runtime, so that when you disable the Capture traffic setting, they'll stop sending traffic to Fiddler.
However, some clients (particularly .NET applications) do not react to proxy setting changes and always use whatever proxy was set when the client was started; they'll continue to send traffic to Fiddler until the client is restarted.
You can examine the Process column in Fiddler to see what client isn't properly reacting to changes in the system's proxy setting.
You likely have web pages open that periodically hit the server from within javascript (ajax calls), fiddler captures that traffic and that's what you're seeing.

Chrome dev tools loses network history

The Network tab in Google Chrome developer tools is great but seems to lose all history on certain form posts.
Is there any way to get it to retain network history?
If not is there another tool I could use?
The "Preserve Log upon Navigation" status bar button in the Network panel should solve the issue:
Is there any way to get it to retain network history?
Yes and No. It may not retain the network history you want. (verified with chrome 62 in 2017-11-22)
If not is there another tool I could use?
https://www.charlesproxy.com/
Charles is an HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP and SSL / HTTPS traffic between their machine and the Internet. This includes requests, responses and the HTTP headers (which contain the cookies and caching information).
I am using chrome 98 and this worked for me checking this

How to make fiddler less intrusive?

Fiddler is a great tool for testing a wide variety of http scenarios. However Fiddler also blocks all kinds of traffic that it shouldn't. This intrusive behavior can be annoying and time consuming.
Is there a way to specify what Fiddler does and does not listen to? So I want to say only monitor and report on traffic going to localhost or www.google.com, everything else would be ignored.
Is that possible ?
Its just rather tedious to have to close fiddler whenever it blocks something it should not.
Fiddler acts as a system proxy, so you can't have some traffic flow through it and some not, unless you can configure the client to not use the proxy for some connections.
You can use Fiddler's filter options to determine what is captured and shown in the sessions window.
However, what does it block ? I use Fiddler extensively, and have no issues with connections being blocked. Perhaps there is another solution than closing Fiddler.
I faced the same problem when setting up Fiddler just now (Win7). My problem was that Fiddler (Fiddler2) was not detecting and using my corporate Proxy settings. I had to go and set them manually in Fiddler Options > Gateway
That is why all my non-local, non-intranet traffic was appearing to blackhole. Hope that helps.

Why can't I see WCAT traffic in fiddler?

I'm using WCAT to load test my app, and I want to see the traffic in fiddler.
When I run the WCAT script, it runs OK,but I don't see any of the traffic in fiddler... Do I need to configure fiddler to proxy WCAT traffic?
The web app I am testing is on my local machine, but I'm not addressing it with "localhost", I'm using the name of my machine in my settings config. I don't have any filters set up in fiddler either.
EDIT:
Here's my transaction I'm testing with (the ipv4.fiddler is a recent addition as per a suggestion below):
transaction
{
id = "add a new user";
weight = 1;
request
{
verb = POST;
postdata = "Name=Bob+Smith&Gender=M&DateOfBirth=01%2F01%2F1970&Email=testuserdude" + rand("1","1000") + rand("1","1000") + "#example.com&Password=123456&ConfirmPassword=123456";
url = "http://ipv4.fiddler/TokenBasedLoginTests/Account/Register";
statuscode = 302;
}
close
{
method = ka;
}
}
Thanks
Matt
Per http://blogs.iis.net/thomad/archive/2010/05/11/using-the-wcat-fiddler-extension-for-web-server-performance-tests.aspx,
WCAT requests won't show up in Fiddler
nor can a proxy server be used with
WCAT.
The former part of that statement is implied by the latter part. It suggests that the WCAT team specifically removed the ability to use a proxy server, which seems like an odd choice, but might make sense if they thought the load would take down a proxy.
If you wanted, you could configure Fiddler to run as a reverse proxy, and then point WCAT at that reverse proxy; you'd see the traffic then, and Fiddler would redirect inbound requests to their actual destination. See http://www.fiddler2.com/redir/?id=reverseproxy
You might consider using the Visual Studio Web Test tools instead, as they do properly use the proxy (and hence Fiddler).
You could use an extension like this one http://blogs.iis.net/thomad/archive/2010/05/11/using-the-wcat-fiddler-extension-for-web-server-performance-tests.aspx
What happens when you use the server of http://ipv4.fiddler? Local traffic doesn't go through Fiddler, but it adds the ipv4.fiddler as a proxy on top of wininet (I may be getting that wrong and Eric Lawrence will correct me, I'm sure), and as a result, can capture local traffic?
I use Fiddler quite a bit to test web apps and services and always use ipv4.fiddler to capture my local traffic.
Hope this helps!
You can easily track WCAT traffic (very useful for debugging) using a transport level tool (such as Wireshark or Ethereal) rather than an HTTP proxy. These tools are able to capture traffic at the network card/packet level. All you need to do is...
a) Run a capture with a filter enabled to limit to traffic between client(s) and server and using a particular protocol (i.e. HTTP) - There's always a lot of unrelated traffic flowing through your network card and adding the filtering will make things easier. If you have multiple clients it might be best to run the capture on the server.
b) Tracing a stream (normally just click on one of the packets related to the request / response and rebuild it to a request / response.
Note that this will impact on throughput/performance. Best to turn it off for a real run! Hope this is helpful!