The Byte Stops Here

CGI Facade?! I'm sure you are saying, I've heard of a Session Facade, but why a CGI Facade...

Well, simple really. Web Servers are evolving, and sooner or later, you'll put a device or a server in between you firewall and your web server, like a clustering device or a reverse proxy like my current favorite, NGINX (see previous post for details).

NGINX, for example, will accept http requests on port 80, and forward them to your web server. In doing so, the web server thinks the request is coming from NGINX and not from the outside world. Your CGI vars, notably REMOTE_ADDR and REMOTE_HOST will get skewed with the IP of NGINX. A lot of times you will run NGINX on the same physical server and the CGI variables will start displaying 127.0.0.1.

This can be a problem. For example, you may be using the IP for logging, or for configuration based on the dev environment. ColdFusion is not smart enough to know who the original requester is. But its only partially at fault.

When NGINX gets the request, as you'll see from sample configs, it DOES pass who the original requester is. It creates new HTTP headers and passes them off to the web server. Here are two lines, see if you can follow:

proxy_set_header    X-Real-IP       $remote_addr;
proxy_set_header    X-Forwarded_For $proxy_add_x_forwarded_for;

As you can see, its adding two headers: "X-Real-IP" and "X-Forwarded_For" with the IP of the requester. In your CGI Facade, you don't want to rely on REMOTE_ADDR and REMOTE_HOST, and instead, if the header has these values, pass them instead for whatever use case you may have. In face I would recommend you do that now so as to future proof your apps.

This is not a new problem. Many people are familiar with SQUID, and that too sets headers as it proxies. So get to it!

The Open Web Application Security Project has updated its list of Top 10 Risks.

Read this article at Information Week for more details.