Beefing up Web application security
By Staff, Michael Mullins CCNA, MCP, Special to ZDNet Asia
Wednesday, March 30, 2005 11:59 AM
Wednesday, March 30, 2005 11:59 AM
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.
There are currently no comments for this post.