As a web developer you have your share of demons you have to face. If your company processes credit cards, chances are your yearly PCI DSS compliance scan is one of those demons. I thought I would do a short series on a few security items I tightened down as a result of our last PCI scan. This is by no means a comprehensive list of everything needed to pass a PCI scan. If you want to know that and have time to read a 74 page PDF you can get a copy of the Spec at www.pcisecuritystandards.org.The Payment Card Industry Data Security Standard is an international standard for computer systems dealing with customer data used in credit card transactions. Basically your company gets to pay every year for a third-party Qualified Security Assessor or QSA to run a battery of tests against your network and give you passing or failing grade. If you fail, you have to pay extra fines or possibly lose your ability to process credit cards. Well, that is if you don't fix the items they find wrong. PCI compliance scans are one of those things I love to hate. I understand why they exist, and I am a BIG fan of security. It's just that many people think PCI compliance scans can cause a false sense of security. While they have the potential to point out serious holes in your network, they also don't come close to checking all the possible vulnerabilities your application may have as a whole. Most PCI compliance sans consist of automated scans for known exploits. Code reviews would provide a much more in-depth picture, but honestly few companies care enough to spend that kind of money and time when the superficial scan is enough to keep them in business. Our scan also made everything look twice as bad as it really was by listing most of the vulnerabilities two times-- once for HTTP traffic and once for HTTPS traffic.

The problem

The first item I addressed was a "Web Server Predictable Session ID Vulnerability". The idea is that if you assigned a simple easy-to-guess id to each user's session on your site (like 1, 2, 3... etc.) and stored that value as a cookie, a hacker could easily guess another session ID that another user was using and pass that in instead. The ironic thing here was the analysis was completely inaccurate and no problem really existed. The automated scanning tool simply found a cookie called "WEBID" being set to this value: "web003". The automated scanning tool incorrectly identified this cookie as being used for a unique session identifier. Turns out this cookie was nothing more than a hint to the load balancer about what server had processed the last request. I was actually mildly irked over this one. Firstly, a quick look the .cfm extensions and the presence of a random 36-character JSESSIONID cookie should be a clue to anyone worth their salt how sessions are being tracked. Secondly, the report included an insultingly-long description of just how horrible of a vulnerability this is and all the dastardly ways it can be exploited-- which might not have been so bad if they weren't looking at a COMPLETELY INNOCUOUS cookie.

The Solution

In short, use JSessionID to track your ColdFusion sessions. Before JSessionID, there was CFID and CFTOKEN. CFID was a predictable auto-incrementing number, and was always used in conjunction with CFTOKEN which was a randomly generated number. Even though that setup was pretty random and secure, JSessionID's are slightly harder to guess (even though we're talking about billions of possible combinations here) and tend to make PCI compliance testers feel more at ease. Adobe actually talks about keeping PCI compliance testers happy with your session ids in this knowledge base article: http://kb2.adobe.com/cps/404/kb404762.html In the end I simply removed our WEBID cookie even though it had nothing to do with our session tracking. Our new load balancer uses its own cookies that it injects into the HTTP headers anyway so our old WEBID cookie wasn't even being used. Tune in soon for PCI DSS Compliance Part 2 - Weak SSL And Ciphers