I need some kind of proxy which sits between client and server and simply dumps all request, but also forwards the requests to allow communication between client and server.
|--------| |-------| |--------|
| client |-----------| proxy |-----------| server |
|--------| |-------| |--------|
Reason I need this: I'm working on a client software and want to see how the (REST) requests actually are sent to the server. For example, I want to see the multipart POST entities, etc.
Off course I can use netcast to "emulate" the server, but this does not actually result in traffic going from client to server and vice versa. The ideal situation would be a proxy listening on port yyy which forwards all traffic from the client machine to host:yyy.
So my main question is: what kind of proxy am I looking for? Is it a forward proxy? Or a transparent proxy?
If you are on Windows, you could be looking for the Fiddler HTTP proxy.
It is a web development tool that, when run will set itself up as a global proxy for your computer. It will show all http requests that your computer makes, with various options to inspect/replay/alter them.
You can get it at: http://www.telerik.com/fiddler
Related
I have a use case where I have to put a middle server or relay or tunnel to do network communication with the following points:
I have a web server running, let say when I hit an API /request hosted my web server, it creates a post request to https://www.google.com and gives me a response through the endpoint.
I want a middle server (proxy etc.) which I will call while creating this post request instead of communicating through my webserver,
the call goes to the middle server and gives me the same response as I was getting directly.
For this, the SQUID proxy worked for me.
I came across NGINX, but we can not use NGINX as a forward proxy, also there are some observations that might be useful with this regard.
SQUID proxy also uses the conf file as similar to NGINX,
HTTPS traffic is encrypted, the proxy server need to do some more work to get something with Https requests,
For intercepting, and creating ACL rules, someone will need to have a dummy certificate to be used by the server to act as the owner of the requested content through the proxy,
a list of rules can be incorporated within SQUID.conf to achieve the filtering.
I hope this could be useful to achieve something like this.
I made a proxy server in python 3. It listens on the port 4444. It basically receives the request from clients and sends it to the server. I want to use it as a firewall to my Dvwa server. So added another functionality to the proxy. What it does is, before sending the request to the DVWA server, it validates the input.
But the problem is, the clients have to configure their proxy settings in the browser to use my proxy server. Is there any way to access the proxy without configuring the browser settings. Basically I want to host the proxy server instead of the original web server. So that all the traffic goes through the proxy before going to the webserver.
Thanks in advance...
You don't say whether your Python3 proxy is hosted on the same machine as the DVWA.
Assuming it is, the solution is simple: a reverse-proxy configuration. Your proxy transparently accepts and forwards requests to your server who then processes them and sends them back via the proxy to the client.
Have your proxy listen on port 80
Have the DVWA listen on a port other than 80 so it's not clashing (e.g. 8080)
Your proxy, which is now receiving requests for the IP/hostname which would otherwise go to the DVWA, then forwards them as usual.
The client/web browser is none the wiser that anything has changed. No settings need changing.
That's the best case scenario, given the information provided in your question. Unfortunately, I can't give any alternative solutions without knowing the network layout, where the machines reside, and the intent of the project. Some things to consider:
do you have a proper separation of concerns for this middleware you're building?
what is the purpose of the proxy?
is it for debugging/observing traffic?
are you actually trying to build a Web Application Firewall?
I'm running a local web server written in Go and I can debug traffic going to it from my browser; but, I can't see the http request that it makes to external services.
Do I have to run some particular configuration of the web server in order to get the traffic to appear in fiddler? It is running as a background process.
Short answer: you can't...
...unless your web application is written to open a connection to a Proxy server and route requests through that connection (e.g. connect to a remote proxy, and then send requests through it).
Typically what developers do is just dump the Web Request/Response to a debug file to inspect during development (or to debug on a live server, by enabling it with a flag at runtime).
Fiddler is a "proxy" service/server. When you are using it normally to debug browser requests, your Browser is configured to connect to a Proxy server. That is, it will send all web requests through your fiddler's local server (I think it's localhost:8888 if i remember from my Windows days of using Fiddler) which in turn makes a connection to your local web server that you are debugging.
You can read more about Proxies at Wikipedia.
In that picture above, your local web server would be Alice. Meaning, Alice would need to be configured to connect to a proxy server and then make web requests through it.
EDIT:
(for the "I really need this" crowd)
If you really want to modify your web server to send requests through a proxy, there are a few Go packages already written to help you. GoProxy is one such package.
This may not be the correct place for this question as it's part networking, but here goes.
I am wanting to put together a WebApi (using the ASP.NET MVC WebApi framework) to be consumed by client machines external to our network. However the client machines resolve web traffic through a proxy server for which our software does not have authentication. We have noticed that outgoing FTP connections are possible though.
So I am wondering whether we can host the webapi and have client machines connect out through Port 21? Does that even make sense? Sorry if it's a stupid question.
I managed to find some answers and thought I would share for anyone that might be interested.
Binding WebApi to ports other than 80
This is possible, but tricky. When you publish the Api project onto IIS (or wherever you are hosting it) you just bind it to an alternative port. You then also make sure you forward that port in your router. Then, clients of the API just specify the host using your custom port to access the endpoint through that port: http://myhostname.com:21/api/values or whatever.
Complications
Testing the endpoints can be tricky as Chrome blocks HTTP traffic being sent via some ports - port 21 is one such port. So to test it you need to write a client exe that can hit the endpoints to make sure they are working (like a console application).
Despite figuring all of this out, I still could not connect out through the firewall. I suspect that some configuration is blocking the traffic because even though it is going out through an open port (21), it is not FTP traffic: it's HTTP traffic.
A Solution
It occurred to me that SOAP operates through a range of protocols (FTP, SMTP, HTTP, to name a few) and formats its messages as XML. So in this scenario it would make more sense to use a SOAP service via Port 21 rather than REST which is strictly HTTP.
We often find columns like Address, Port in web browser proxy settings. I know when we use proxy to visit a page, the web browser request the web page from the proxy server, but what I want to know is how the whole mechanism works? I have observed that many ISP allow only access to a single IP(of their website) after we exhausted our free data usage. But when we enter the site which we wants to browse in proxy URL and then type in the allowed IP, the site get loaded. How this works?
In general, your browser simply connects to the proxy address & port instead of whatever IP address the DNS name resolved to. It then makes the web request as per normal.
The web proxy reads the headers, uses the "Host" header of HTTP/1.1 to determine where the request is supposed to go, and then makes that request itself relaying all remaining data in both directions.
Proxies will typically also do caching so if another person requests the same page from that proxy, it can just return the previous result. (This is simplified -- caching is a complex topic.)
Since the proxy is in complete control of the connection, it can choose to route the request elsewhere, scrape request and reply data, inject other things (like ads), or block you altogether. Use SSL to protect against this.
Some web proxies are "transparent". They reside on a gateway through which all IP traffic must pass and use the machine's networking stack to redirect outgoing connections to port 80 to a local port instead. It then behaves the same as though a proxy was defined in the browser.
Other proxies, like SOCKS, have a dedicated protocol that allows non-HTTP requests to be made as well.
There are 2 types of HTTP proxies, there are the ones that are reversed and the ones that
are forward.
The web browser uses a forward proxy, basically it is sending all http traffic through the proxy, the proxy will take this traffic out to the internet. Every http packet that comes out from your computer, will be send to the proxy before going to the target site.
The ISP blocking does not work when using a proxy because, every packet that comes out from your machine is pointing to the proxy and not to the targe site. The proxy could be getting internet through another ISP that has no blocks whatsoever.