2

Is it possible to modify users' HTTP request to 

www.example.com/options

instead of 

www.example.com/options_and_params

My scenario is that about 30000 users connect to my company's network backbone and I want to add one or more server (with the code I'm current working on) between the backbone switches and Radware LoadProof to achieve this work.

After googling all the night, I have no lead but some more questions:

  1. I don't need to intercept every packet through the network. With some helps like iptables, I can filter out the package I want. I have done it before using iptables. However, packet is not equal to HTTP stream. Do I need to do HTTP re-construct?
  2. If I successfully find a way to modify HTTP request URL content, I still should put it back to network stream. As I know TCP packets have a checksum and after I modify the content it must be wrong. How do I calculate a new checksum and put the packet back to network?

It's my first time to do network programming or packet processing develop. Any suggestion is appreciate.

Alex Chen
  • 645
  • 2
  • 10
  • 25
  • No way using simple rewrite rules on server level? They should be suitable to add paramters. – arkascha Oct 05 '12 at 13:56
  • See [Fiddler2](http://www.fiddler2.com/fiddler2/)'s `AutoResponder`. AFAIK, you can use its c# libraries. – L.B Oct 05 '12 at 14:01
  • @arkascha Rewrite rules can not meet my need. The site is not running within my company and I can not control it. – Alex Chen Oct 05 '12 at 14:12
  • 1
    Then take care that you don't raise any legal issues. Intercepting and modifying someone elses communcation can be considered a serious crime very fast... – arkascha Oct 05 '12 at 14:14
  • @L.B Interesting, as a .net programmer I am, Fiddler is used almost everyday. However, 30000 users and more than 1 million active connections maybe a little overwhelmed for Fiddler? And I am afraid it is hard to use fiddler transparent to my intranet users. – Alex Chen Oct 05 '12 at 14:16
  • @arkascha Thanks for your notice. Legal issues won't be a problem. The site's owner tell us they won't maintain their product anymore and they suggest us to do what I answered like a workaround. What a pity they can't offer any further technical support on their "workaround". – Alex Chen Oct 05 '12 at 14:19
  • It is your decision. Neverthess take care, intercepting communication is usually done in good intentions, but communication is protected by clear laws. Just because you and the sites owner agree upon the solution does not mean it is legal :-) – arkascha Oct 05 '12 at 14:23
  • @arkascha Yep, it seems like my boss need some law consult work to do :D – Alex Chen Oct 05 '12 at 14:46
  • This is doable though there are questions. 1. Do you only want to intercept the incoming request and let the response go back itself without intervention? Another way is like you are sitting as a middle man i.e. receiving the requests, modifying them, receiving the response and sending back to the clients. If it is otherwise, even then you would need to recompute checksum. 2. Which language? Some have api for recalculating checksum, that you can write at the appropriate offset in the packet. tcprewrite is one utility which allows rewriting checksums, but is done on pcap files, not on the fly – fkl Oct 11 '12 at 11:52
  • Also another thing, can you configure yourself (i.e. the node in the middle which modifies the request to act as proxy). Configuration is required on client, to use your as a proxy node. In this case it would be easy to do so. Please clarify all these things and i hopefully will be able to assemble basic code for you. – fkl Oct 11 '12 at 12:00
  • @fayyazkl I want everything I do is transparent to end user. So proxy may not be a good solution. Given a mid-server running linux, C or C++ will be the only choice that I known well enough. – Alex Chen Oct 11 '12 at 16:44
  • @AntiGameZ You haven't answered another question. Your mid server would receive the request, alter it and send it. Will the mid server receive the response too and have to send it back to ultimate client? Or do you want to response to be directly sent to client and mid server only intercepts the incoming request – fkl Oct 12 '12 at 07:30
  • The only option I see so far is a reverse-proxy. If the former owner will not use the site anymore you could probably change DNS settings just to point to your proxy, so to keep users thinking they work with original site. – Stan Oct 12 '12 at 17:57
  • 2
    Appeal to **be transparent**. Don't invisibly act man in the middle. Return a HTTP 302 redirect. This makes your work easier too. – Colonel Panic Oct 12 '12 at 20:57
  • There are some serious architectual questions here. But i dont think your intent/goal is clearly stated to give any kind of useful answer. – Michael Brown Oct 14 '12 at 12:20
  • @fayyazkl My mid-server only intercept request from my internal user to external service and did noting with response from external service. – Alex Chen Oct 15 '12 at 07:52
  • @ColonelPanic I tried to use nginx to solve the problem. Depending on the very complex transformation and condition detective, nginx can't work. – Alex Chen Oct 15 '12 at 07:54

2 Answers2

1

This depends on whether you are doing HTTP/1.0 or HTTP/1.1 and whether its an initial request you need to modify or all requests in a single HTTP 1.1 session.

If you have the packet and can modify it before it is sent on and you are trying to modify just the request then given the length of a typical packet and the location of the URL in the HTTP request stream (very near the beginning) and the fact that it will be the first thing sent in the TCP stream I think you can fairly safely assume that it will be present in the first N bytes of the first packet sent and therefore won't be split over multiple packets.

However, if this is an HTTP/1.1 stream then multiple requests will be being sent via the same TCP connection in which case in future requests the URL may well be split over two TCP packets.

If you can maybe force HTTP/1.0 or possibly if you modify the initial or all requests to be HTTP/1.0 then you can be pretty sure that the first packet will correspond to the first packet of the TCP stream and that you are very unlikely to see the URL split over multiple packets, meaning no reconstruction and the ability to just do a replace.

However this will come at a cost of new TCP connections which is pretty inefficient.

If you don't and you leave it as HTTP/1.1 then the URL could be at any random point in any future request and therefore split over multiple TCP packets (two realistically given the size of the URL).

AntonyM
  • 1,602
  • 12
  • 12
0

If I got your question right, then this could be probably done with some fast reverse-proxy like nginx.

Andrey Kuzmin
  • 4,479
  • 2
  • 23
  • 28