Any resource/codes on how fiddler works? - http

I need to track http/url requests & redirects from a windows forms application using C#. It should handle both IE & firefox. Not sure if Fiddler is open-source but if i'm not mistaken, it's written using .NET. Sample codes or online articles on how to listen to http/url requests & redirects will be appreciated.
Thanks!

Fiddler works as standard HTTP proxy. There is no magic here. See HTTP protocol for details. In both IE/Firefox, you need to set Fiddler (or your custom program) as proxy, and then browser will use it for all outgoing requests. Proxy is responsible for forwarding request to correct server, and returning response. Proxies are typically used for 1) caching, 2) controlling access (and avoiding firewalls), 3) debugging.
See also Open Source Proxy Library for .Net for .NET proxy library (just quick googling... I have no experience with it).

You'd probably be interested in the new FiddlerCore library: http://fiddler.wikidot.com/fiddlercore

Related

Why do browsers not support gRPC?

gRPC is based on HTTP/2, which (assumption) is widely supported by browsers. Therefore, I feel there should be no problem with gRPC from a browser.
However, it is clear that there is a problem. The protocol, grpc web, is different, as exists "due to browser limitation". There are also numerous blog post describing complicated tech stacks deployed to get gRPC to work from a browser.
I'm missing the actual problem - why does gRPC not simply work from browsers?
I now understand that browsers only supports HTTP/2 in the sense that they use it to fetch resources from the server on behalf of your application (javascript) code.
Javascipt application code can still only use HTTP/1 (which may be handled under the hood by the browser in an HTTP/2 connection). Therefore it is not possible for application code to use grpc.
If anyone should find where this is explained in the docs, it would be good to add a link to it here.
Most browsers use HTTP1.1 whereas GRPC only works with HTTP2. You can use nginx, envoy or traefic to run it behind a reverse proxy, very similar to how web sockets are often used behind a reverse proxy(in that case the http1 is upgraded to a websockets connection). The reverse proxy will send the grpc request sent over http1 to an http2 backend and vice versa. You can use Envoy(suggested/currently used by grpc-web), traefik(am using this personally) and nginx.

is there any tools that help me to find all the messages from my computer out,not just the HTTP message via the browser?

postman is perfect!with it i can know most of the HTTP messages.but now i wonder if there is any tools like that one to help me know all the messages between my computer and outer world,not just the HTTP messages
I would recommend you to use fiddler, it's a web debugging proxy that I'm using most of the time on HTTP protocole but not only as you can capture FTP protocole for example.
You can also re-edit your request and have lots of interaction as web debugging :
http://www.telerik.com/fiddler

See data that an app is secretly sending to web server in the background

I was playing around with fiddler (http proxy) and I noticed that some apps are making http get/post requests in the background and sending data and stats to and from the web. This got me interested and a little concerned to see what data various apps were sending but it seems that most of them are not doing it on port 80 via http but presumably on another port so you can't see the data in fiddler. Is there some way to view and/or potentially block the data being sent?
You're asking: "Using Fiddler, I saw that traffic was being sent by clients to servers. How can I see that traffic?"
Might I suggest you use Fiddler?
You can see the process sending the traffic in the Process column, and you can view the contents of the requests and responses using the Inspectors tab.
I would check out burp suite. It is a proxy you set up in your web browser and shows all of the data that passes through it. There's plenty of tutorials online. Check it out here

How to sniff http requests

I want to sniff a local HTTP request to an ASP.NET web application.
Is telnet an option?
How do you capture packets to a web application?
Depending on your exact requirements, Fiddler may be sufficient.
http://www.wireshark.org/ is a very advanced and free sniffer/protocol analyzer. I use it on our servers to monitor things from sip protocol info to raw http data. Its all you need and you can add filter rules to just get the data from certain IP etc. ie:
ip.addr == 192.168.1.1
Raw packets and headers all included.
For ease of setup, I personally would use either the Tamper Data (https://addons.mozilla.org/en-US/firefox/addon/966) or Live HTTP Headers (https://addons.mozilla.org/addon/3829) plugin for the FireFox browser - or for a lower level solution WireShark (http://www.wireshark.org/)
Have you tried browser plugins that allow you to do this? Firebug, etc.
I found this in another post, it works
http://socketsniff.nirsoft-freeware.qarchive.org/_download2.html
There are browser add-ins that can make sniffing of the HTTP requests easy:
For Internet Explorer, there is the Fiddler Web Debugger.
For Firefox, there is the Live HTTP Headers add-in.

Need some help with HTTPS, certificates and signing

I am quite new to HTTPS and can not get my head around it.
Can someone suggest good starting point for learning about HTTPS, certificates and signing?
Possibly with a working example in ASP.NET with IIS.
If all you are trying to do is have your site in HTTPS there is no code needed. All you need to do is set IIS to serve pages with HTTPS.
If that is all you want, you are better off asking this question in http://www.serverfault.com.
To get you started, here's a link on how to set https in iis 7: http://learn.iis.net/page.aspx/144/how-to-setup-ssl-on-iis-70/
HTTPS is just normal HTTP traffic that is encrypted using SSL/TLS. The protocol is fairly straightforward. I wrote a detailed blow-by-blow of what happens at the start of a connection on my blog: The First First Few Milliseconds of an HTTPS Connection.
It's unfortunate that the APIs built on top of the protocol are often much more complicated.

Resources