Session IDs as Query Parameters Must Die

Purge those nasty JSESSIONID and PHPSESSID parameters from the URL bar. Now. Sensitive data in GET parameters are bad. Even over HTTPS. Just stop. Please. No more excuses.

Check out this session ID killer proxy built on nginx, that converts these sensitive query parameters into safe and secure cookies.

The 9 Deadly Sins of Query Parameters

We might all know that session identifiers function as a usernames and passwords. You would never give away your credentials, so why would you do the same with session IDs?

Let’s overview where these query parameters are exposed along the way between your computer and the web site you visit.

On your computer / smartphone


  • Web server logs
    • Log aggregating services such as SIEM, Elasticsearch, Splunk
    • Log files indexed by search engines (Google dork)
  • Reverse proxy logs


The bad news is that most of these are still problematic even when the web site is served over HTTPS.

Removing Session IDs

So to solve the issues above, we need to get rid of the sensitive query string somehow.

In many cases fixing the application may not be an option for many reasons. Those working with mod_security a lot now might be familiar with virtual patching. This is basically a quick ‘n’ dirty hack for masking web application vulnerabilities without touching the application itself. So why not borrow this great idea?

Enter SID Killer Proxy

What we need here is to deploy a reverse proxy in front of the insecure web app. Although the application continues using a GET parameter for passing session data, the proxy will convert between unsafe query parameters and safe cookies on the fly.

The concept is the following:

SID Killer Reverse Proxy Diagram
SID Killer Reverse Proxy Diagram

Server Side Components

I am using phpBB3 as a vulnerable app for this demonstration. This app still uses a GET parameter called sid= as well as cookies for passing the session ID back and forth. Long story short, I have turned the cookie support off in phpBB to simulate a legacy web application here.

The SID Killer Proxy is based on nginx and its quite powerful Lua module, and installed on a standard Ubuntu image.

Traffic Flow

When a visitor loads our “legacy” website (phpBB), it generates a HTTP response with session data in the URL bar. However the response is sent through the nginx proxy first before it reaches the visitor.

The intermediate proxy strips the secret sid= parameter off from all HTTP responses, and replaces it with a Set-Cookie HTTP header. This will install a cookie in the visitor’s browser instead.

New Cookie in Browser

The other direction of traffic works similarly. When the visitor’s browser sends the cookie back in each HTTP request, nginx rebuilds the sid= parameter for the application server from the appropriate Cookie: value.

For more details, check out the comments in the source code below.

Reverse Proxy Configuration

Magic and Sparkles with Lua

Closing Words

In order to minimize the exposure of the secret query parameter, this proxy should be deployed as close as possible to the mischievous application.

Nothing substitutes a web application that is developed with security in mind of course. However, this neat trick may help protect the visitors of legacy web applications.


Gabor Szathmari is a cybersecurity expert and digital privacy enthusiast. In his professional life, Gabor helps businesses, including many small and mid-size legal practices, with their cybersecurity challenges at Iron Bastion.