mkrausnick,
There are plenty of techniques for comprimising a website. Though excluding all the normal OS attacks here are a few simple examples;
1. SQL Injection - an unchecked SQL statement dynamically generated from variables passed by the user which contain certain hacks (e.g. "' OR 1=1" as the password )
2. File Uploads - allowing users to upload files without checking the type of file can lead to them uploading scripts that they can execute and use to perform actions on your site.
3. Cross Site Scripting (XSS) - this can lead to DoS attacks from unsuspecting visitors to your site - if a user uploads a script (e.g. javascript) this (when a user views it as part of your page - e.g. blog comments etc) could be used to continually request your site, or propogate to more pages/posts etc - a recent example of this was MySpace. This can be used for other things besides DoS.
4. WebServer Vulnerabilities, e.g. Global.asa access (for unpatched ASP Servers) - although quite an old vulnerability, if your host hasn't patched their server correctly a specially formed HTTP request can trigger the response of the contents (code) in the global.asa - which can have security information in it.
5. Password/security Files - it is easy to place unsecured information into a readable (though not necessarily directly navigable) file, which can be searched for or blind tested by attackers - always secure every page - for example .inc renamed to .asp / .php / .jsp etc.
6. Using Debug Information that has been left in the source code - not an attack vector, but an info gathering exercise that could be used to formulate an attack
7. Exploitation of Server side processing methods that do not cleanse input data (similar to SQL Injection) - functions that execute literal code generated by inputs from the user - or use that to access the operating system (e.g. filesystem). Though you would expect developers that work at this level to be somewhat aware of the potential risks and necessary steps to safeguard themselves.
8. Bypassing client side validation - NEVER rely on client side validation to secure the inputs - users can use tools like telnet or netcat to send the HTTP request, and therefore bypass any security you put into your client side script.
9. Hidden form elements holding sensitive data is surprisingly still done - with everything you do - DO NOT TRUST THE CLIENT SIDE !!
10. Server Side Includes... again from user input may trigger the server to execute them at some point.
OK, that should be enough examples, but there are plenty more. The main point to take from this is that treat every bit of informtation from the client machine as potentially dangerous, and filter out what shouldn't be there. Also don't send anything to the client if it should be secret - e.g. passwords in cookies, or in the URL or hidden form elements.
A smile is worth a thousand kind words. So smile, it's easy! 