Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a situation where I need to facilitate file uploads of up to 200M to a utility server which is separate from the main web site server. Here's my configuration:

Client on
Public Internet
    /\    \
    |      \_____ 200M
    |            \_____  
    |                  \_____
    V                        V
Authenticating <------->  Utility Server
Web Site                  (EC2, Windows, Apache, Python, Django)

My current solution is simply for my Web server to pass the EC2 URL of the Utility server, and allow the client to communicate with the Utility server directly. This has two flaws -- it exposes the URL of the unauthenticated utility server, and it requires cross domain tricks on the client to route the POST upload to the utility server.

The question is what's the best way to hide the utility server from the client, without pushing the file upload data through the web server? These are the ideas I thought to try:

  1. DNS alias the utility server with a subdomain. This probably fixes my cross domain scripting problem, but I'm not sure if it helps with securing the utility server. Maybe I can check the web server's authentication cookie from the utility server?
  2. Rewrite rule in web site's Apache config. I'm not clear how this affects where the data of the POST would actually be routed.
  3. Redirect in the web site's Apache config. I'm not sure if I can hide the utility server URL from the user with a redirect.
  4. Redirect from the web site's controller code. Same issue as #3, but I thought this might be better than #3 since it would pass the request through the PHP authentication layer.
  5. Something better??


  • The unusual config of the utility server is a function of the intersection of available software for the utilities that it needs to perform.
  • The utility server is NOT a high value target for serious mischief. It would be sufficient to have the security equivalent of locking the front door, but I'd like to avoid leaving the key under the mat.
share|improve this question
up vote 3 down vote accepted

You cannot hide the utility server url from the client without proxying it in the web server. I would setup a shared key in both the web server and utility server and proceed as follows:

The web server draws a link or redirects the client to the utility server with the following parameters:

  1. authenticaded username
  2. link generation (or redirection) timestamp
  3. client ip
  4. signature (the previous 3 values hashed with the shared key)

In the utility server you check that:

  1. The signature received is correct (redoing the hash with the shared key)
  2. client ip is the same as reported in the parameter
  3. elapsed time since timestamp received in the parameter is less than a reasonable amount (10-20 seconds should be enough, given that both web server and utility server use the same time source)

If all the checks are passed you can accept the user as authenticated (cause you trust the shared key), start a session, and draw the form for file upload.

share|improve this answer
Great answer. The first sentence is key. Even if I avoided embedding the utility server name on the web page, I wouldn't be able to mask the network traffic. All the user needs to do is start HTTPFox and the game is up. Thanks! – mjhm Aug 18 '11 at 15:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.