[drupal-devel] [bug] comment preview "Required" is easily bypassed
http://drupal.org/node/28420 Setting "Preview comment" to "Required" does not strictly require that the comment be previewed first. This is being abused by spammers to quickly and efficiently post spam comments. I discovered this after I added a new feature to my new spam module [1] to auto-blacklist spammer IP addresses, allowing me to block comment spammers when they preview a comment and thus preventing them from ever inserting their spam into my database. I configured my comment module to "require" comment previews, and yet found that the comments were slipping past my filter. I finally realized what the spammer is doing is setting $_POST['op'] to 'Post comment', effectively bypassing the preview phase. I'm currently looking for a clean solution to this. At the moment the only idea I have is to generate a token at the preview phase, and validate the token at the post phase. Unfortunately the token would have to be stored in the databse between the preview and the post, which adds overhead. Alternatively, I've considered using a time-based hash which would constantly update depending on the time of day. This could easily be validated without storing anything in the database. If too long has gone between the preview and the post, an additional preview step would be required... The down side here is that the time-based hash would be publically available, and thus the spammer could easily duplicate it in their script. A private key could solve for that, but increases the complexity as it adds a configuration step. I have the feeling I'm missing a simpler, cleaner solution. Suggestions? I have created a bug report here: http://drupal.org/node/28420 -Jeremy [1] http://www.kerneltrap.org/jeremy/drupal/spam/
On Sun, 7 Aug 2005, Jeremy Andrews wrote:
my filter. I finally realized what the spammer is doing is setting $_POST['op'] to 'Post comment', effectively bypassing the preview phase.
[...]
I have the feeling I'm missing a simpler, cleaner solution. Suggestions?
I think that the form code rewrite that I've proposed and that Adrian is/was working on should take care of this. It would check whether a field "op" could have been present in the original form. The problem that we in this case have a dynamic form. I think that checking of a session variable would help. This would break posting for clients which do not accept our cookie. Which maybe would be quite welcome in this case. ;^) Since you probably do not wait for Drupal 4.7 you should thus try to put the unique preview ID into the session. Cheers, Gerhard
participants (2)
-
Gerhard Killesreiter -
Jeremy Andrews