ZAP Proxy Not Working - zap

I am trying to Proxy my browser traffic through the ZAP Proxy tool. I have setup my browser proxy according to the user docs on ZAP site and the same as the instructions in the post below. My site I am trying to scan just hangs at the login page, but as soon as I disable the proxy everything works fine. Also, looking at the network traffic in the Firefox or Chrome Dev tools, it shows "Waiting for fonts.googleapis.com". Any ideas what I check or try? I have tried 4 different browsers
Adding authentication in ZAP tool to attack a URL

Turns out IIS and ZAP were both configured to use port 8080. I changed ZAP to use a different port and it worked fine.

Related

MITM Proxy - How to intercept user requests in reverse proxy mode from inside/outside Web Application Server

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.

How to debug https setup?

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.

SSH Tunneling not working properly

I created an SSH tunnel via Putty and configured firefox to use it. Everything is working properly.
I have a spare AWS server that I am using for this purpose. I have verified that firefox is indeed using the proxy by checking my IP address.
Now, I want to be able to use this tunneling proxy to access Facebook which is blocked at my workplace.
When I try to access Facebook via firefox with the tunnel, it still says that facebook is blocked?
What is going on here?
You can reach the same effect, i.e. to see facebook page and everything is forbidden in your network, by using Tor Browser

IBM Worklight - Application Center Console - Redirection to port 9080

We are trying to setup the Worklight Server for production, which is behind a reverse proxy that will help manage the SSL certificate.
What this means is that, when the user hit the domain, say https://mydomain.com:443, the proxy will automatically forward the request to the Worklight Server on port 9080.
After the setup is done for the reverse proxy following this guide, the installers.html page is working well. However we notice that when we try to access the console using https://mydomain.com:443/appcenterconsole, the user gets redirect to http://mydomain.com:9080/appcenterconsole/console.html instead and this is causing problem.
I searched around and found this link Worklight Console redirects to port 9080, which is similar to the problem i'm having. Is there a way for me to configure the Websphere Liberty Profile so that it will use the reverse proxy URL as the redirection URL?
I notice also that the index.html file in the appcenterconsole.war is using the meta refresh method to do the redirection. I'm tempted to change it to use a full URL, but then i also notice that the same issue happens when we go to the login.html and perform login. (Whereby after login, the page redirects the user with the 9080 port as well).
Any pointers or idea are welcomes. The Worklight version used is 6.1.
Thank you.
EDIT
The network setup in my environment:
Proxy Gateway (with SSL cert) configured to connect to Worklight Server for port 9080 whenever a connection with port 80 or 443 is received. Therefore:
https://mydomain.com:443/appcenterconsole -> will be mapped to http://worklightserver:9080/appcenterconsole
The mapping is done internally between the proxy and the worklight server.
When we type the full URL on the browser, ie. https://mydomain.com:443/appcenterconsole/console.html after i login, the console works fine.
Have you set up the JNDI entries detailed here?
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.installconfig.doc%2Fappcenter%2Fr_ac_appres_endpoint.html

Apache on Windows and Fiddler

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.