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.
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.
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.
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.
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.