Maintaining PCI-DSS Compliance While Accessing Host Data via the Web
Everyone has a web browser.
That means you can make data available to everyone who needs it by putting it on the web. Even data accessed through legacy host applications can be made available on the web – without touching the mainframe or the host application. Simply by using a web-based terminal emulation or file transfer program, users with nothing more than a web browser can access everything they need.
That part is easy. The hard part is security. If your organization deals with credit cards, you need to comply with PCI-DSS (Payment Card Industry – Data Security Standards), which means you have to defend against cross-site scripting (XSS) attacks.
Cross-site scripting? XSS? What’s that about? When you authenticate to a website, the web server returns a “session cookie” to your browser. When you click on other pages, your browser sends that session cookie back to the server, to say “hey, it’s me again, the person you just authenticated.”
The session cookie is a big convenience – it means you don’t have to enter your password repeatedly. But it has to be kept secure. If someone steals your session cookie, they might be able to use it to impersonate you and steal your data.
That’s where XSS attacks come in. Some websites have coding flaws that allow attackers to plant malicious scripts that run when you connect to the site. The scripts ask your browser to read your session cookie and send it back to the attacker, who can then try to hijack your session.
Fixing those coding flaws is the best answer, but that’s hard to get right. So a powerful fall-back defense was developed: the “HTTPOnly” flag.
HTTPOnly is a simple idea. The web server marks the session cookie as HTTPOnly. That tells the browser, “don’t let scripts read this cookie – only proper HTTP requests are allowed to use it.” So if a malicious script asks the browser to read the cookie, the browser will refuse.
It’s a powerful defense, which is why PCI-DSS requires use of HTTPOnly.
You might be wondering why the browser needs to be told not to read the cookie on behalf of a script. The answer lies in some unfortunate history. In the early days of the web, poorly behaved applications commonly manipulated the cookie directly. Modern applications, if they are designed for security, leave it to the browser to handle the cookie, and do not try to read it directly.
One hallmark of a well-designed, secure web application is that it functions correctly even if HTTPOnly has been enabled on the web server. If an application malfunctions when HTTPOnly is turned on, that’s a sure sign that the application is not well-behaved when it comes to cookies and security.
The takeaway: to comply with PCI-DSS, you need to enable HTTPOnly. If this causes problems for your application, then you need to question your vendor about whether the application is properly designed.
