While this is by no means an exhaustive list of attacks that could occur, they are some of the most common means by which your infrastructure can be exploited.
Cookie Poisoning: Cookies can be a dangerous way of storing sensitive information. Because cookies are simply text-based files, attackers can visit a site and modify the cookies to gain access to your systems.
Database Sabotage: Even though your database may be secured, it still needs to allow access by application and/or Web servers. And those servers are likely to have read and write access. While you can save time by using in your application input field names that match the database, it's a bad idea from a security standpoint. Attackers can take that information and craft SQL statements within text fields or HTTP requests to the servers to perform all sorts of nasty deeds.
Stealth Commanding: This attack has been around for years and continues to harvest a cornucopia of data for those of malicious intent. By the attacker's appending or inserting commands into text fields, the Web or application server can be forced to execute commands that are often destructive or that reveal sensitive information. This attack can be alleviated by careful consideration of user input inside the application.
Direct Requests: One of the methods used to garner sensitive information from your site is to directly request it, in effect creating an end run around the checks you may have in your application path. For example, you may have an entry point into an application that lets customers view the status of their orders or their profiles. You generally expect these functions to be accessed from a link on another page, so your verification of customer identity may not be as strong on the order status or profile page. It's easy enough to directly request these pages without going through the expected pages and score a hit, thereby retrieving sensitive customer information.
The No. 1 security rule when developing Web-based applications: Never trust user input. Always check and, if necessary, double check any input received. Don't rely on JavaScript or VBScript checks in the browser intended to force compliance, because this technique is easily avoided by direct request to your servers. For an in-depth look at attack strategies, see our previously published workshop, "Maintaining Secure Web Applications."