Worried about security
issues? Who isn’t? Automatically
sign up for our free Security Solutions newsletter, delivered each Friday,
and get hands-on advice for locking down your systems.

When embracing a defense-in-depth strategy for your
organization’s systems, setting up a secure network boundary and applying best
business practices to your internal clients is a great start. But the work
doesn’t stop there.

One area that organizations often overlook is application
security for Web-enabled applications. In fact, some of the recent, highly
publicized thefts of private information occurred due to poor application
design and implementation.

When it comes to Web application security, we can divide the
topic into three specific areas: server-supplied data, database data, and
session data. Let’s look at each area more closely.

Server-supplied data

Nearly all Web applications serve remote user information
stored on a backend server. Consider a financial application: It’s
transactional in nature, and it supplies the user with accounting information.
If the server exposes the information natively to the user, the user can
then manipulate the information to process an unauthorized transaction.

For example, let’s say you’re using an application that
references actual sequenced account numbers to debit accounts for purchases. A
user could alter the account number used in the transaction to make a purchase
that debits another account.

How can you better protect your data? By using index numbers
based on user information, you can remove the possibility that a malicious user
could alter transactional data.

Database data

Most Web applications are merely front ends to a back-end
database. Because it’s such a broad topic, Web database security can involve a
host of issues.

Most of these issues revolve around three areas: user input,
access permissions, and staged databases. Use the following best practices to
properly lock down each area.

  • User input: Cleanse user-supplied
    data (e.g., a SQL injection) of database meta-characters. Would-be
    attackers could use these characters to modify queries to gain access to,
    corrupt, or destroy data.
  • Access permissions: Incorporate table-
    or row-level access permissions into any user database interaction. Base these
    permissions on user-specific accounts and not global database accounts. By
    limiting user interaction to a low-level authenticated account, you can
    limit the information that users can manipulate or change.
  • Staged databases: By incorporating
    multiple databases, you can direct users’ interaction through a
    transactional database that resides in a demilitarized zone (DMZ). With this
    approach, you only expose the current transaction to the user, providing
    no native user access to the entire database served from the back-end
    database.

Session data

Secure all Web applications entirely through either HTTPS or
another secure protocol. However, don’t make the mistake of securing the
authentication and then running the
application over HTTP. A black hat could easily capture the session token for
this type of application and use it to gain access to the entire user session.

Speaking of session tokens, issue them only over encrypted
channels after user authentication. In addition, if you serve multiple Web
applications, each application should issue its own secure session token. This
prevents the compromise of a single token allowing access to an entire range of
hosted applications.

Final thoughts

Because of the environment in which they operate, Web
applications are inherently vulnerable. However, most commercial Web
applications have well-developed security.

Internally developed applications are the ones that most
often involve application security challenges. So, if your organization develops
its own Web applications, make sure you incorporate security into the initial
design of the application—don’t add it as an after-market solution.

Mike Mullins has
served as a database administrator and assistant network administrator for the
U.S. Secret Service. He is a network security administrator for the Defense
Information Systems Agency.