Yes, you’ve made sure that you’ve chosen a password that you can remember, that no one else can guess, and that has in it at least one number and one punctuation mark. You know, though, that there is more to securing your web site than that, but you don’t know where to start looking for the most common methods of weakness exploitation, and how to make them not so weak.
Though they may sound hopelessly technical at first, the basic types of security issues are easy to understand, and once understood, easy (enough) to prevent.
One of the oldest tricks in the book is still one of the most commonly used. The Denial-Of-Service attack (DDOS) consists of nothing more than flooding a web site with more requests than it can handle, effectively paralyzing the site so that it cannot be used by legitimate web surfers.
The reason that this type of attack still exists today is that it is surprisingly hard to deflect. Done right, a single request from a DDOS doesn’t look noticeably different from a legitimate request. It’s only in the volume of requests that the problem becomes apparent. Furthermore once an attack is recognized the only way to shut it down without shutting out “real” traffic is to find a unique fingerprint on the requests and filter only that. While this means that a lazy attacker can be stopped by simply blocking his IP address, a sophisticated attacker (or worse, dedicated group of hackers) can create a deluge of requests that is very difficult to differentiate.
The only real solution to this is to have a web host that is willing to stay with you and keep the barbarians from the gates. A good host will.
Hacking by URL and buffer overflow
A web page’s URL is a common place to send the information to a web server that it needs to form new pages. The problem is that this information often goes to a script which has privileges that, if hijacked by URL, could be used against the server itself.
A subset of this problem is the buffer overflow. This is when a URL is sent that is too long for the web server to handle. What often happens, depending on the server specifications, is that the remainder of the URL is sent to the server as a command, often run as “root” (the user set by default to have universal privileges).
What you need to do about this depends on what the operating system of your server is, but usually comes down to both making sure that your scripts are secured against this weakness and making sure that they are setup in such a way that, even if they are compromised, they don’t have the security permissions necessary to do anything nefarious.
Check with your web host
A security problem for a single user is potentially a security problem for all users, meaning that your web host doesn’t want it any more than you do. Check their help documentation, and by all means, ask about anything that confuses you. Their livelihood is on the line right along with yours, so they will always be glad to help you both feel more secure in your site.