I'm using the request module to send http requests from my server.
I want to be able to intercept the request before it is sent and save it as a raw http request text.
There are GUI tools such as burp suite that will act as a proxy server and intercept outgoing requests in raw HTTP text, but I need to be able to do this in my node server.
So far my efforts to convert a request object to raw string has been futile and I'm pretty sure there are better ways to do so but I'm stuck.
Thanks
Related
Is there a way to perform GET and POST requests using only socket.io-client? Regardless of the server framework.
Something like socket.emit('/endpoint', req).
You are confusing Websocket protocol with HTTP (another protocol). GET and POST are HTTP methods and have nothing to do with Websockets.
The only similarity between Websocket and HTTP is, that both are using TCP on the layer below.
I need to build an application that connects via web socket and replicate http requests. I looked for how to send a json/dict and send requests in some format, I didn't find anything in lib requests that was completely straight forward.
Say user makes a request (get|post) to http://example.com/data
now i've server setup, nginx, to redirect all requests to https.
so browser again sends a request but via https protocol.
my question is did server tell browser to redirect right after reading http headers or it could have gotten data in body of request and then told browser please send this via https.
because if latter, sensitive data has already been sent via insecure method.
I understand to prevent this i can include redirection in html file, are there any other methods.
It doesn't matter if the server reads it, because the client might have sent it anyway.
At the time when the server has finished reading the headers, the client has already sent the headers (obviously) but it also has sent some or all of the body.
How much of the body has been sent by the client is not dependent on HTTP, but on the underlying TCP protocol. It is dictated by variables such as the receive window, the congestion window and the size of the headers and of the body.
See this great article for an explanation about congestion/receive windows in TCP.
What tool / function can we use on our linux server running CentOS to monitor the http headers that are sent from our application to another application on a different server? Looking for http header monitoring from server to server. My issue is I have no idea how to capture the data sent from the server, meaning the http headers sent via a post. I have tried many methods and third party software's like fiddler2 and ieinspector and the list goes on, but they only seem to capture the client headers and not what is being sent out from the server. I just need to capture the string being sent out via a post function and what is being returned. Seems simple, yet in this case, I'm beyond lost and running out of time to resolve what should be a simple solution. Please advise & thank you kindly.
I have a server that takes http request and return json data. How does my server know if the http request is from a client browser and not from a server? especially if traffic may proxy from a client to another server and make a call to my server.
I know i can check the http header to know user-agent, remote-addr..etc but it is not secure. People can fake the http request header.
What other tricks I can do to identify the incoming request?
There is no way for you to know. "Anonymous proxies" will not have the X-Forwarded-For header. Some IRC servers will port scan clients as they connect looking for common proxy server ports like 8080, 3128, ect. You could hack up a tool like YAPH to look for proxies on people connecting to you. But it won't pick up phpproxy, or proxies running on strange ports.
This is an up hill battle, and its why hackers use them. If this is a problem, perhaps you should reevaluate your business model or how your application functions.
If you're able to check for headers, you'll be able to see X-Forwarded-For, which will tell you the ip of the "real" request. Legitimate proxies utilize this header.
For browsers, User-Agent header is what you'll be interested in. Popular browsers and crawlers will utilize this header.
That said, those headers can be faked or omitted. There is no single way to determine the "real" factor of incoming requests. It's best to incorporate as many headers, patterns and behaviors to determine legitimacy of a request.