Methods (wiki)
High-level languages that first get compiled into an intermediary language before execution can produce remarkable results when diassembled. Special tools can even replicate much of the program's original source code thanks to .NET's use of a Common Intermediate Language, which allows a program to have the same CIL build regardless of the .NET language used to write it. Java's implementation of bytecode for the Java Virtual Machine can produce the same effect.
SQL vulnerabilities
The Structured Query Language used to perform work on a CRUD (create, read, update, delete) database is versatile and powerful. The use of SQL provides highly optimized access to a relational database, removing the need for the database administrator to write their own unreliable, platform-dependent processes to do the same work in twice the time. However, the structure of the language and the manner in how it is used opens up several options for significant exploitations
Direct examples
These attacks pertain to a situation in which access to the database is already possible given some source of information. A technique called SQL injection allows the attacker to execute unauthorized or harmful SQL instructions (or queries) on the database, despite not having complete and open access ot it. For example, the database may only be accessible through the use of an application, like a small program or web site. The application can use variables to return customized information from the database based on user input. For example, the query:
SELECT IDNumber FROM UserInfo WHERE UserName = @UserName
where @UserName = "Frank" will return the ID number for the username Frank. This variable's value can be filled by the application so that it works for any username provided. However, if the contents of @UserName are not just a user name but an extended query statement, the results of the query can become significantly different. What if the application's user provides this for @UserName?
@UserName = "\'a\' OR 1 = 1';"
The final database query would then take the form:
SELECT IDNumber FROM UserInfo WHERE UserName = 'a' OR 1 = 1
Since 1 always equals 1, the query returns ALL ID numbers from the UserInfo table. The same technique can be used to destroy information or access even more sensitive information.
Filtering the variable's value for escape characters is a standard way of avoiding this problem. Careful sanitization of the application's variables is paramount for secure database applications.
See SQL Injection at wikipedia for a more comprehensive list of variations on this technique
Indirect examples
These attacks take place when direct access to the database is not yet possible. These techniques grab information about the database by some auxiliary means to gain access.
The first method is easy. Running a packet sniffer while attempting to use the database application might expose some important information about the database. At the very least, the database's location should be picked up by the sniffer. Worse yet, if the database's server can be accessed through telnet, then even more information is exposed. The database's username and password will probably show up as plaintext, and even queries and structural information is at risk. If any of this information is obtained, then the attacker can simply log into the database directly.
The second method is much more time-consuming. Assume packet-sniffing exposes only the database's location. Even though the communication is encrypted, the location would still be fairly obvious from the packet sniffer. If the attacker is really persistent, they might execute a brute-force attack to repeatedly guess at the database's usernames and passwords. The success of this attack depends mostly on the strength of the default username's passwords. In Microsoft SQL Server 2005, this means giving the user accounts sa, Administrator, and any user-defined accounts very strong passwords.
This method's usage is typically proportional to the popularity of the database, but anyone's server can be attacked. Over 1000 failed login attempts were logged immediately after a Microsoft representative tested and used our application for our Imagine Cup entry. Luckily, our passwords were fairly strong and no harm came of it :)