I need to monitor HTTP traffic in my dev env which is PHP/Apache/Windows. But Apache seems to refuse the HTTP requests coming from fiddler which sits between the browser and Apache.
Error is No connection could be made because the target machine actively refused it
I suppose there should be some configuration on Apache which allows traffic via Fiddler. Can any one help me with it?
What windows version are you using?
What browser are you using?
Does the Apache reside on localhost?
Try disabling IP6 support (in the Fiddler options -> General -> uncheck "Enable IPv6 if available")
If apache is on localhost try http://machinename:port instead of http://127.0.0.1:port or http://localhost:port
Also check Fiddler know issues
I'm going to assume that your browser and Fiddler are installed on the same machine and the deve enviroment is remote. I would install Wireshark and capture the native browser requests, and the ones proxied through Fiddler. See what is different between them. I would seem they would be comming form the same src IP, so I would look at the various HTTP request headers, and see what is different.
Related
I am new to mitm.
https://mitmproxy.org/
AppServer1 (A windows 2016 server) has our IIS website application (WebApp1) running (its running fine without any problems currently).
I have added an SSL certificate as well, and it is loading fine without any issues.Chrome shows that it is trusted ("Connection is secure" when navigating from inside and outside AppServer1 server but "within the LAN". So far we havnt allowed access to internet users as of yet until the app is completely ready.)
We have a business requirement where
we need to intercept all traffic/requests from users from outide AppServer1
and send them to another application that we created (UserRequestDashboardApp),
and ALSO we need mitm to send it to WebApp1 as well.
I have read the articles multiple times and from what I understand, reverse proxy mode is the correct option to for our requirement.
WebApp1 is running on url - customappservice1.com, port - 443
I then started mitm (version 4.0.4) with the following CMD command
.\mitmdump -p 8080 --mode reverse:https://customappservice1.com
I get the status proxy server listening at http://*:8080
I dont seem to see any traffic in the terminal when I type customappservice1.com on AppServer1 chrome browser or any server browser outside AppServer1.
The WebApp1 pages load fine from outside and inside AppServer1 server but no traffic at all on the terminal
Can anyone please help me to capture the traffic on the terminal as an initial step before sending the traffic/requests to UserRequestDashboardApp AND WebApp1?
I have tried running mitm normally and it works fine(I can see traffic/requests fine in the terminal)
I launched mitm in CMD (It says Proxy Server listening at http://*:8080)
I set the
Windows server proxy to = localhost
Port = 8080
Did you try configuring your requests to use the mitmproxy's address ?
Also, web browsers may have use a separate proxy configuration from the operating system's. So you may try configuring Chrome's proxy settings.
I scaned my site with Burp Suite Proffessional.
It said a vulnerability called "HTTP Request Smuggling" has been detected.
This vulnerability was detected in the August 7, 2019 Burp Suite Professional ver2.1.03.
My server environment is as follows.
CentOS 7
Apache 2.4
PHP 7.3
PortSwigger says how to resolve this problem.
That is by changing the network protocol of the web server from "HTTP/1.1" to "HTTP/2".
https://portswigger.net/web-security/request-smuggling#how-to-prevent-http-request-smuggling-vulnerabilities
So I changed my site with SSL support and then HTTP/2 support as well.
And I scaned again, the "HTTP Request Smuggling" vulnerability was detected AGAIN.
HOW TO FIX THIS?????????
I am NOT interested in what is this problem details or how it works at all.
What I want to know is how to stop detecting this problem.
If you have encountered a similar event, tell me the solution. please?
If possible, I wish what you did something to this, wrote in httpd.conf or php.ini, etc.
I found that need to improve version of tomcat but I haven't tried yet
Article about solution
If you are using end-to-end HTTP/2 communication then that should eliminate the vulnerability. What I mean by this is that HTTP/2 is the only HTTP version used in all HTTP traffic.
Many web architectures has a load balancer or proxy in front of the web server which accepts HTTP/2 traffic. However, many frontend servers rewrite the incoming HTTP/2 traffic into HTTP/1 when it forwards the traffic to the backend server/ web server. When the traffic gets rewritten to HTTP/1 then HTTP request smuggling is possible. More info here: https://www.youtube.com/watch?v=rHxVVeM9R-M
I'm posting this quote from James Kettle, a researcher from Portswigger: "you can resolve all variants of this vulnerability by configuring the front-end server to exclusively use HTTP/2 to communicate to back-end systems, or by disabling back-end connection reuse entirely. "
source: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn
I use my home network (ATT U-Verse) to serve my ASP .NET website on a Windows 8.1 Pro machine with IIS 8.5. Because Chrome requires https for doing audio recording, I want to move to https. I followed the instruction video at https://www.netometer.com/blog/?p=1758 , and everything corresponds (IIS showing that I have a certificate in the bindings and an entry for port 443) until I test the actual https link in a browser (on the server itself, on an other machine on the home network, or externally via my phone with data), which gives me a "This page can’t be displayed" or equivalent message. I added port 443 to the Norton firewall rule I already had. The http access still works, however. Netmon 3.4 shows no TLS or SSL traffic. I also tried disabling the Norton firewall temporarily. This leads me to believe that the problem is that either the ATT NVG510 router I have is blocking port 443, or that ATT itself is blocking it. Looking at the router settings on the Packet Filter page, it seems none of the default "Drop" rules are enabled, and there is an "Enable Packet Filters" button. Do I specifically have to set up a "Pass" rule?
Does anyone have any ideas on what I could do? Can I actually do https on my home server? My web site is www.jtlanguage.com . Sorry if this is the wrong place to put this. I'm a programmer trying to do some IT.
Thanks.
-John
Turns out I wasn't doing port forwarding. For NVG510 users this is done by going to the router page in the browser to firewall->NAT/Gaming page and adding a hosted application referencing the HTTPS service and the web server machine name.
after installing apache in my pc I cannot visit http://localhost.
firefox shows that :
Firefox can't establish a connection to the server at localhost.
what is the problem? can anyone help
This has nothing to do with your webserver.
Check http://kb.mozillazine.org/Error_loading_any_website .
There are many things that could go wrong in this case. My best bet is to check your proxy or firewall settings.
UPDATE:
Antivirus programs interfere with firewall and security settings, so you might take a look into that... Make sure the port that Apache is running is not blocked by your firewall. Go to the firewall settings and make sure that Apache (or HTTP port number used by Apache) is not blocked
In windows if you installed apache you have to start your apache service first then go throw your Firefox or other browser simply type local host then you can access your server.
I have recently switched from mac development environment to windows development environment. I was used Chrles proxy extensively to capture network traffic, requests and response details. Right now I have installed Charles proxy version 3.7 in windows 8. How ever I have observed that the website on which I am working is not opening at all with Charles proxy ON. It is showing below exception message. And it is working perfectly for all other websites.
Charles Error Report
Failed to connect to remote host
Charles failed to connect to the remote host. Check that your Internet
connection is ok and that the remote host is accessible. Maybe your
network uses a proxy server to access the Internet? You can configure
Charles to use an external proxy server in the External Proxy
Settings.
The actual exception reported was:
java.net.ConnectException: Connection timed out: connect Charles
Proxy, http://www.charlesproxy.com/
Research that I have done before coming to SE:
I have searched in google with the keyword "Charles Error Report-Failed to connect to remote host". I got couple of links which are related to the above issue.
First link says to check for external proxy setting. I have checked, there are no external proxy settings in my computer.
Second link says open the url in browser and close charles proxy and reopen it. I did that. Still no luck.
How to overcome this issue?
Do you get the same problem with other proxies like Fiddler? If so, it's probably not related to Charles but either a network problem or inability of your application to work with a proxy.
Other causes may be using HTTPS (which can cause certificate errors) or using the loopback address (localhost or 127.0.0.1) which may or may not be ignored by the proxy.
UPDATE
In IE10+ Enhanced Protection Mode prevents untrusted applications from accessing local resources. Pages and sites that are not in the Trusted Zone are considered unstrusted, so they can't connect to any local proxy. Fiddler includes a configuration button to configure Windows 8 to bypass this. You can find a very good explanation of what happens and why here.
In Windows 8, EPM is enabled only for Metro IE. In 8.1 it is enabled by default even for Desktop IE.
You may be able to make Charles work again simply by adding your site's address to the Trusted Zone in IE's security settings, or you can download the EnableLoopBackUtility mentioned in Configure Fiddler for Windows 8 Metro-style applications to allow IE to connect to your site through the local proxy
I have experienced this as a timing or caching related gremlin. For me, in most cases, this is resolved by doing force-reload a few times in the browser. Doing so is slightly different on each platform. In Mac/Chrome, holding down Command + Shift + R for a couple of seconds does the trick. In Win/IE, holding Shift and clicking the reload icon in the address bar a couple of times does it - in theory, Shift + F5 should do the same thing, but it does not work as well.