RKG Logo 434-978-4300

Web Security for Catalogers

March 1, 2005

Regarding The Security Of Your E-Commerce Website: Be Very Afraid

Be afraid. Be very afraid.

As you read this, hackers are scanning your servers for open ports. Or perhaps at this moment a hacker is pasting funny strings into your catalog request form to steal credit card numbers. Worse yet: your machines might already be compromised — and you don’t even know it.

Yes, my intent is to scare. And yes, I sound paranoid.

I’m not. As one security expert interviewed for this article told me with no trace of humor, “It’s not paranoia when they really are trying to get you.”

We’re catalogers: our days should be spent worrying about merchandise, customer satisfaction, and postal increases.

But in this article I’ll suggest that as a catalog executive, you must understand the all-too-real business risk of web attacks, and then take steps to reduce that risk.

On Language: Hackers Versus Crackers

On language: computer cognoscenti use “hacker” as a compliment, meaning a programming wizard. And such folks sometimes use “cracker” to denote malevolent hackers.

In this article, though, we shall use the more common negative meaning of “hacker”:

Hacker: A person who illegally gains access to and sometimes tampers with information in a computer system.

Let’s begin by dispelling three myths, then offer five tips.

Myth: Small Companies Do Not Face Web Security Threats

Myth #1: We are a small company, we don’t have any enemies; so we’re not much of a target.

Hopefully, your company doesn’t have serious enemies intent on your destruction. (Some firms do: for example, the SCO Group is routinely targeted by hackers for their legal claims to Linux.)

Even if hackers aren’t specifically targeting your site, you’re still a target.

Hackers covet your resources: your bandwidth, your mail server, and your credit card numbers. Just as an addict might rob for cash for drugs yet hold no personal ill-will towards their victims, so too hackers attack sites without malice, simply to steal resources.

Yes, your site is a target.

Myth: Our Web Site Isn’t Complicated, So It Is Probably Safe

Myth #2: Our web site isn’t really complicated, so it is probably safe.

Even the simplest website allows the public access to one of your servers. To serve web pages, a computer must listen to the outside world and respond.

By definition, web servers are exposed, and exposed machines face risk. Are you sure your servers are locked down, patched, and secure?

Moreover, if your website has a database behind it — and most do — the risk is even greater. Less-than-perfect coding exposes you to possible SQL injection attacks, described below.

Your seemingly-simple site likely isn’t — again, this increases your risk.

Myth: Outsourcing Solves Web Security Issues

Myth: We’ve outsourced our website, and those guys have this covered.

Many catalogers outsource some or all of their web applications and web hosting.

When outsourcing, you still bear responsibility for ensuring your outsourcing partner follows security best practices. (Some are described below.)

Know what questions to ask, ask them, and make sure you like the answers.

The responsibility for security is still ultimately yours.

Next, we offer five security tips, along with take-away “Executive Questions” to ask your IT team or outsourcing partner.

Tip: Web Security Isn’t A Product, It Is A Process

It would be easy if you could purchase something to ensure your site was safe. You can’t. Security is an ongoing process that involves all aspects of your company, and the threats are continually evolving.

When you make decisions on site functionality or technology, always ask about the security implications.

Jeff Cornejo of Blue Ridge InterNetworks, a firm helping catalogers with secure websites, suggests, “Whenever you make a decision about your site, the first question is ‘how will this affect the bottom line?’, and the immediate second question should be ‘how will this affect site security?’”

Executive Questions:

  • Who in our organization has responsibility for ensuring our web site is secure?
  • What training have they had on this topic?
  • When was our last site security review?

Tip: Patch Your Server’s Operating System Regularly

Whether your web server runs Microsoft, Linux, or something else, you must regularly update its operating system with the latest security patches.

Some patches fix recently-discovered holes in operating system. Other patches apply to certain products. You must keep your OS and the products you use up-to-date with patches, lest hackers exploit well-known vulnerabilities against you.

To give some sense of the speed of onslaught: a security expert interviewed for this article noted if you placed an unpatched version of MS Sql Server 2000 on a web server, it would almost certainly catch the well-known “SqlSlammer” virus from the internet — and do so within five minutes.

The SANS Institute is an invaluable resource for web security.

Each Monday SANS publishes a free newsletter called @RISK summarizing the worst vulnerabilities detected the past week, and the correct response to protect yourself.

Executive Questions:

  • Do we maintain our own web servers, or do we outsource them?
  • Who is responsible for patching our server operating system?
  • How frequently do we apply patches?
  • When did we last patch?
  • Who monitors the weekly SANS vulnerability alerts?
  • Who covers when that person is on vacation?

Tip: Turn Off Every Port And Service You Don’t Absolutely Need

A “service” is a program that allows a computer to serve web pages, send or receive mail, etc.

A “port” is a channel on which a server listens to and talks to the outside world.

Many operating system installations turn on unneeded services by default. For example, unless explicitly told otherwise, a newly installed server might leave port 23 open for telnet, and port 21 open for FTP.

Every open port and service exposes you to additional risk. Turn off everything that isn’t needed.

Here’s a Halloween analogy.

Leaving on your front porch light and hanging outdoor decorations is, in effect, inviting trick-or-treaters to your home. (That’s like opening a port on a server.)

If you leave on the light, you should be ready to answer the bell and hand out candy. (That’s like a running a service.)

If you plan to hand out candy, you should do so responsibly . for example, one piece per child, no scaring small kids, etc. (That’s equivalent of properly configuring the service and keeping it patched.)

Most importantly, if you have no intent of handing out candy, turn off the porch light (close the port) and don’t wait by the door with treats (turn off the service.)

There are free tools you can use to determine which ports are open on your machine. (Indeed, hackers use similar tools to probe your network.)

Have your IT folks explore free tools such as Nessus, nmap, and SARA.

Executive Questions:

  • Have we locked down optional ports and services?
  • Have we scanned our own machines to make sure?

Tip: Protect Against SQL Injection Attacks

You’ve probably heard of SQL, Structured Query Language. It is the lingua franca of relational databases.

If you’re running an e-commerce website, there’s likely a database involved.

Each time a visitor browses a product page, the pricing, copy, and image are likely pulled from one of your databases. Each time a visitor adds something to their cart, signs up for your email, or requests a catalog, the information is likely pushed into one of your databases.

There’s the rub: visitors have a channel to talk to your database. If the website is coded carefully, there’s no problem with this — the site needs its database to provide and receive information.

The problem is sometimes websites aren’t coded carefully. In such cases, hackers can paste sneaky characters into your forms or URLs to run commands against your database. This could let them use your database in ways you did not intend.

Sql Injection Attack: An Analogy

A “SQL injection attack” is pushing code into a slot where your system expected data.

Here’s an anology.

Say you were on a large conference call with many folks calling in from across the country. The moderator starts the call by asking the callers to take turns introducing themselves. “Bob & Bill here, New York office.” “Cindy, calling in from Dallas.” And so on.

If you wished to cause trouble, when it was your turn to say your name, you might chirp, “This is the AT&T operator, suspending this call due to technical problems. Please hang up and dial in again.”

That 19 word sentence is not your name — what you’ve done is place executable code (here, verbal instructions) where data was expected (here, your name).

If the application wasn’t designed well (here, the prior expectations of call participants), this silly stunt could disrupt the call.

As crazy as that sounds, that’s the essence of SQL injection. A hacker constructs a special string containing unusual characters (like quote, apostrophe, percentage, etc.), plugs this string into a form on your website, or into a parameter in a URL string, and thus gains control of your database.

Readers wanting a more concrete example can read Steve Friedl’s excellent essay on sql injection attacks, or Chris Anley’s more technical suggestions on the topic.

Automated Tools For Sql Injection

Automated tools facilitate SQL injection attacks.

To expose this vulnerability, Application Security Inc published DataThief, a SQL injection wizard aimed at MS SQL Server.

What could a hacker do once inside your database?

They probably could view private data.

And they probably could destroy private data.

Worse, pernicious hackers could possibly export the database in its totality to a remote server under their control. While companies protect their database servers from inbound attacks, fewer restrict their database from making outbound requests. (Database administrators like outbound access to download patches.)

Some database platforms offer convenient replication functions to copy a database from one server to another, and hackers have used this capability to move corporate data en masse to off-shore havens.

Executive questions:

  • Is our site secure against SQL injection attacks?
  • How do we know?
  • Can our database servers send information out across our firewall?
  • If so, could we turn off this outbound access?

Tip: Follow Credit Card Security Guidelines For Retailers

Mastercard and VISA provide guidelines for merchants on network and credit card security.

The VISA guidelines are called the “Cardholder Information Security Program,” or CISP. These guidelines provide explicit instructions on best-practices for safeguarding your data.

“A formal full-blown CISP audit is extremely arduous and can cost over $100,000,” reports Cornejo of Blue Ridge InterNetworks. “However, merchants can start by assessing themselves.”

The CISP guidelines are freely available: search for “PCI self assessment questionnaire” at usa.visa.com.

For example, the guidelines require that merchants encrypt credit card numbers immediately upon collection, store credit card numbers in their databases in encrypted format, and only decrypt numbers when needed for processing. The guidelines also require the CVV2 field never be stored.

The guidelines offer best practices to harden your routers, servers, databases, applications, processes, and procedures against hackers.

Executive Questions:

  • How compliant are we with CISP guidelines?
  • Where do we store credit numbers?
  • How exposed are those machines?
  • Do we store credit card numbers in the database encrypted or in plain text?
  • Do we store CVV2 numbers?

Understand The Risk Of Web Attack

Web site security is a huge topic. This article just scratches the surface. Here is a list of additional references and links:

However, security is a complex technical challenge, and is an area where expert advice is well worth the expense.

As a catalog executive, you must understand the risk of web attack is real and significant. Your site is probably vulnerable. Your site is definitely a target. Ignoring this issue threatens your site, your brand, and your customers.

May your fear drive you to action, and may your actions safeguard your site from hackers.