I noticed yet again on vancouver.php.net that surprise surprise, while our backs were turned organizing the OpenWeb Vancouver 2008 conference, our Drupal based site got hammered with spam, again. We have a group of working professionals experienced in Drupal, up, down, and sideways, but we dont always have the time to monitor the website as closely as we would like. We make upgrades, we review configurations, security issues, we deal with issues as best as we can, but as volunteers, we have other things to do. We cannot keep ahead of exploits as fast as the exploiters, and I wonder who ever really does.
But really, this is a problem that is endemic to cms packages. A hacker can write one script and attack all drupal sites on the world wide web. Same problem for wordpress and every other website in a box. They all have a url that someone can post to with name & value pairs. There are always lots of things to do to protect your site, but with every new upgrade and patch, there are always new exploits that might just work when applied to your site.
Without a human being to look and see, you wont know that your site has been tossed until you see it for yourself, and remains that way until it is fixed.
Randomizing not only the form name but also the field names was a very successful experiment in my case when someone had my number. The attacker cant presume the name of your fields then so easily, and then they cant attack you. Its like you become a moving target, not a static one. At the very least, they actually need to be on the page in real time in order to post something. Now other developers have told me that in fact it could be attacked with a position based form filler, say based on a xul widget or hacked firefox, but this solution, while possible by some attackers, is generally extra effort to include in the whole looping construct for the attack.
Spam networks hire out at at least $5000 an hour, I learned at a VanLug talk last year. So if an exploit takes too long to seize on to, it is not worth the time. CMS packages are uniform instances of software in terms of action urls and form and field names, so they are static things to sieze upon in the eyes of an attacker who has to provide the biggest bang for the buck. They are sitting ducks, just waiting to get attacked. If even an array key was constructed of a md5 hash at page load time, stored in a session (oops, no sessions in Drupal, not Kosher, if you are a Drupalist), that at a minimum would be enough to be a moving target an attacker would be unable to sieze upon without actually being on the page in real time. And that is the whole problem with spammers, they never even visit your site. Never have and never will.
