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
- Your browser history
- Cache files created by your browser
- Shoulder surfing
Server-side
- Web server logs
- Log aggregating services such as SIEM, Elasticsearch, Splunk
- Log files indexed by search engines (Google dork)
- Reverse proxy logs
Third-parties
- Proxy logs (e.g. in an enterprise environment)
- Other websites via the
Refererheader - A friend in case the URL is shared
- Fellow tenants in a public cloud
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:
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.
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.
