Evan Schuman's StorefrontBacktalk

A funny thing happened here the other day. In reviewing the top sites linking to us, we often click on some of the referrals to see the context of the reference. But when we clicked on one such link, it seemed to bring us to our own E-mail newsletter in the subscriber’s Inbox. While trying to back out, the user’s complete Inbox was revealed—with full read, delete, modify and send privileges.

We immediately contacted the owner of that site and did some tests. Sure enough, we were able to send from his account and open his messages. After some frantic exploration on his end, he reported the hole that we suspected. We had continued access until the site manually logged out and then logged back in.

“What this exposed was a time-out failure on the E-mail site that needs to be corrected,” the site administrator told us. “I’m not sure what cycle we will adjust it to, but the E-mail address needs to log itself off and reset periodically—I’d like to see every 30 seconds or less—so that what I did manually would be done automatically, behind the scenes, without my having to actually log out and back in.”

This incident wouldn’t be so noteworthy if it had been the first time such a thing happened, but it wasn’t. A major publisher that links to us frequently—and which has a very robust IT operation—had an identical problem. When we clicked on the link back to the publisher, it would let us have full access to its site behind its firewall, as though we had logged in as admin/superuser.

This breach is similar to the search engine spider problem, in that few security managers think about it much. My favorite anecdote about that issue comes from an RFID privacy book published a few years back. The authors found a wide range of confidential documents about their target companies by doing Google searches for the word “confidential.”

In searches that we’ve conducted, we routinely stumble on confidential E-mail exchanges that were clearly found by a relentless spider. This problem is likely going to get much worse as the efficiencies of cloud computing tempt companies to place the contents of server after server on the cloud for faster and easier access. Easier access is certainly right, but for whom?

The Sears incident from last summer—where site visitors took advantage of Sears’ Akamai cache approach to change the name of a grill to “body parts roaster” and “grill to cook babies”—should have been a wake-up call. The cache method can certainly be made more secure through stricter techniques that perhaps cut into the page acceleration time—Sears’ certainly have—but how many retailers will think to insist on that approach?

But cloud computing is not the only new target for security holes. Mobile computing and especially M-Commerce have an even greater potential for issues. Beyond the inherent breach possibilities with anything wireless, retailers are going to feel the need to push more functionality onto these consumer devices.

Full disclosure: Yes, we’ve been one of those trying to increase that pressure. To make M-Commerce work, functionality is going to have to move overwhelmingly—if not entirely—to the handheld unit so that it can truly be standalone. That’s our strong belief. But that necessity doesn’t negate the fact that new security holes will almost certainly crop up as those moves are made, often before sufficiently creative testing to plug any gaps is completed.

We offer this comment as a call for enhanced vigilance from IT security folk. And, yes, such vigilance is going to mean that you’ll need to be unpopular with both the rank-and-file and senior management—rarely a good career advancement move—because you’ll force deployment to be slowed down. You will become the bottleneck, and your chain needs you to assume that role.

It will mean a lot of explanation to senior execs as to why this vigilance is critical to them. (Mention the Sears example a lot. Sears is a very sophisticated, world-class IT operation, which makes the baby-cooking example that much more persuasive.) It’s also probably not a bad idea for you to have team members assume the white hat role and get imaginative about ways to manipulate and get around firewalls.

This is a heads-up. Please take it seriously, or we may have to E-mail you about this situation—from your own Inbox.