Can't seem to get fiddler to Proxy HttpClient - asp.net-web-api

I've been having issues getting fiddler to pick up the traffic of a self-hosted asp.net web api. My situation might be a little different in that the same application that is hosting the web api is also consuming it (yes we have reasons to do this :) ). We are using HttpClient. Here are the things I've tried:
Adding an HttpClientHandler and setting up the proxy.
added the following to app.config
<system.net>
<defaultProxy>
<proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://localhost:8888"/>
</defaultProxy>
Tried to hit the api from a separate .net client client (thinking the same process consuming the api that is hosting it was not allowing the traffic to be captured since it was all Intra-process).
Now if i open a web browser or postman locally and hit the api then traffic will be captured correctly
Here is the client code:
var handler = new HttpClientHandler();
handler.UseProxy = true;
handler.Proxy = new WebProxy("http://127.0.0.1",8888);
var client = new HttpClient(handler) {BaseAddress = new Uri(new Uri("http://localhost:8085"), "api/companies")};
HttpResponseMessage response;
using (client)
{
response = client.GetAsync(client.BaseAddress).Result;
}
var result = response.Content.ReadAsAsync<IEnumerable<Company>>().Result;
Now ideally i would want just to be able to open fiddler on a running app and capture traffic (even in production) without having to change the source code.

Unfortunately, the .NET Framework is hardcoded to bypass the proxy for Localhost addresses (see my feature request here: https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/6359204-support-the-loopback-token-in-proxy-bypass-lists)
To workaround this, change your request URL from http://localhost:8085 to http://localhost.fiddler:8085 and Fiddler will pick up the request.

Related

Call an http api endpoint using axios through an excel addin

I am calling an http endpoint using axios in an excel addin project. However I am unable to call the endpoint because the addin has an https certificate. It gets installed on every project I try to create using the addin cli. Is there a way to disable https so I can call this endpoint? Here is the error.
Mixed Content: The page at 'https://localhost:3000/taskpane.html?_host_Info=####'
was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint
'http://#######'. This request has been blocked;
the content must be served over HTTPS.
First, your question is missing an important detail that I was able to derive, but you should have included, your using NodeJS as your server.
This isn't technically a duplicate, but the question is really How to disable SSL in NodeJS, Yeoman Office-JS Template as it seems you have already figured out you can't call an http endpoint from an SSL enabled Office Add-In.
I'm not 100% how to disable SSL in NodeJS, but try changing the Dev URL to http. In webpack.config.js --> const urlDev = "https://localhost:3000/"; --> const urlDev = "http://localhost:3000/";.
If you have access to the backend server and can get SSL configured, your better off setting up a API Gateway/Proxy such as krakend to proxy http requests.
I know I just had to disable SSL in my project for the same reason, but I use Visual Studio, so I can't test NodeJS.
See --> https://stackoverflow.com/a/71461455/5079799

Is there a potential data leak when redirecting from http to https?

I have the following code in my Fastify server hosted on Heroku:
this.server.addHook('preHandler', async(req, reply) => {
const isHttps = req.headers['x-forwarded-proto'] === 'https';
if (isHttps) {
return;
}
const {
method,
url
} = req;
if (method && ['GET', 'HEAD'].includes(method)) {
const host = req.headers.host || req.hostname;
reply.redirect(301, `https://${host}${url}`);
}
});
The idea is to prevent access to the server through HTTP and force redirection to HTTPS at the application-level, since it is not possible otherwise on Heroku.
My question is: if the first request to the server via HTTP (before the redirection happens) contains sensitive information such as a username/password, wouldn't that still be "dangerous" or compromising somehow?
You have probably mis-configured something on Heroku.
Heroku domains (.herokuapp.com) are by default HTTPS enabled. The same page has a guide for custom domain SSL setup guide. Since you are talking about (username + password), I am going to assume this is a website. All you need to do is setup CORS with fastify-cors. Your website should ALWAYS be served over HTTPS.
Also you should not use the logic above. Fastify isn't meant to be used as a proxy server. The docs strongly suggest using a front-facing proxy server like nginx. With Heroku you don't need all these. It already handles this for you.
In the future you could also use Cloudflare as a "proxy server" outside Heroku.

Can a Blazor API project share the same localhost endpoint with the client?

As far as I can tell, the model for creating a Blazor client application is to have one project for the client and another for the server. The Microsoft template shows an async call to get data, but it's just a download of a static JSON file. Any real application would need to call an API.
So I have a separate API project for this. But that project has a different localhost endpoint for debugging, and this is causing a CORS nightmare for me. My call from client to server isn't really cross-site, except for this debugging problem, so I don't want to do a ton of work figuring out CORS.
How can I get the Blazor client and web api server to run off the same localhost (or alias) domain, so that the client can make same site requests?
Yes.
When you create a new Blazor Web Assembly app there is a tick box for hosting it in ASP.NET.
If you tick that checkbox then you'll get a server that both serves the client page (via _Host.cshtml) and also responds to web api calls.

Can't see Https traffic in fiddler - it only shows "tunnel" - https decryption enabled

I have a ASP.NET MVC based web site which runs on http.
From the above web site I'm making a https call to a web API
Configured fiddler as a proxy and trying to monitor the traffic using Fiddler Web Debugger (ver 4.4.8.4)
I only see "tunnel to" requests to the https web api sent from the MVC web application. Why am I not able to see other https traffic including request/response headers/body?
I have enabled decrypting https setting in fiddler. I have followed this link:
http://fiddlerbook.com/Fiddler/help/faq.asp
Is there anything else I can check?
Let's step back a bit:
Is the HTTPS request to the web API being made from JavaScript on the client, or from ASP.NET code on the server?
Did the request actually succeed?
What, if anything, do you see in Fiddler's LOG tab?

XMLHttpRequest cross site scripting on same server but different port

using XMLHttpRequest it is not possible to open a connection to a document on a different domain than where the page itself is hosted.
but what about different ports?
for example I have a webserver running on my machine listening on port 80 so the webaddress would look like this:
http://localhost:80/mypage.html
and I have another webserver running on localhost which is meant to process the ajax requests but listens on a different port. so the javascript in mypage.html would look like this:
var xmlhttprequest = new XMLHttpRequest();
xmlhttp.open("GET", "http://localhost:1234/?parameters", true);
xmlhttp.send();
would this work? or will it give a security exception as well?
Using a different port does indeed count as cross-site scripting.
There are several well-known ways to make a call (you can always send the data) and use the response (which is what you cannot normally do under anti-xss constraints), including JSONP and using an iframe in the page to load the data.
This wouldn't go as it is still practically on another server (at least another server instance, which may not be under your control).
You could add a Access-Control-Allow-Origin: http://yourdomain:1234/ in headers, google for Cross-Origin Resource Sharing. It's relativelly new though, not all browsers know about this.
Or you can use jQuery (read more on http://softwareas.com/cross-domain-communication-with-iframes).

Resources