[drupal-devel] help
"Ялдыгин В.Б."
yaldygin at yandex.ru
Wed Sep 14 04:13:07 UTC 2005
>Send drupal-devel mailing list submissions to
> drupal-devel at drupal.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.drupal.org/listinfo/drupal-devel
>or, via email, send a message with subject or body 'help' to
> drupal-devel-request at drupal.org
>
>You can reach the person managing the list at
> drupal-devel-owner at drupal.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of drupal-devel digest..."
>
>
>Today's Topics:
>
> 1. [bug] comment preview "Required" is easily bypassed (Jeremy)
> 2. [bug] comment preview "Required" is easily bypassed (Jeremy)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 13 Sep 2005 20:16:21 -0700
>From: Jeremy <drupal-devel at drupal.org>
>Subject: [drupal-devel] [bug] comment preview "Required" is easily
> bypassed
>To: drupal-devel at drupal.org
>Message-ID: <type=project&nid=28420&cid=44266&host=@drupal.org>
>Content-Type: text/plain; charset=UTF-8; format=flowed
>
>Issue status update for
>http://drupal.org/node/28420
>Post a follow up:
>http://drupal.org/project/comments/add/28420
>
> Project: Drupal
> Version: cvs
> Component: comment.module
> Category: bug reports
> Priority: normal
> Assigned to: Jeremy at kerneltrap.org
> Reported by: Jeremy at kerneltrap.org
> Updated by: Jeremy at kerneltrap.org
> Status: patch (code needs review)
> Attachment: http://drupal.org/files/issues/form_validate-2.patch (1.1 KB)
>
>This optional patch is intended to be applied after my
>form_validation.patch attached to #20 above. It makes the
>drupal_private_key more secure by regenerating it every 24 hours.
>Without this patch, it would be possible for a spammer to use
>brute-force to learn a site's private key by reading the code and
>observing the token generated for a given form. With this patch, brute
>force is still possible, but with this patch it would have to be done
>every 24 hours.
>
>
>It is possible for a form to be generated prior to a rekey, and then to
>be validated after a rekey. In this event, the key will fail validation
>and the user will see a message telling them something like "Validation
>error, please try again. If this error persists, please contact the
>site administrator." When they try pressing "submit" again it will
>work fine.
>
>
>I kept this patch separate as it adds complexity that may not be
>desired in core. Personally I think it is important and should be
>merged along with the first patch. I added it to the system module as
>it seemed the most logical place, and is a "required" module that can
>not be disabled.
>
>
>
>
>Jeremy at kerneltrap.org
>
>
>
>Previous comments:
>------------------------------------------------------------------------
>
>Mon, 08 Aug 2005 01:55:34 +0000 : Jeremy at kerneltrap.org
>
>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?
>[1] http://kerneltrap.org/jeremy/drupal/spam/
>
>
>
>
>------------------------------------------------------------------------
>
>Mon, 08 Aug 2005 02:26:21 +0000 : moshe weitzman
>
>even if you get this fixed, won't these bots just add a preview step?
>
>
>this 'preview required' feature is designed to maintain high quality
>submissions by forcing users to proof read. it isn;t designed for
>security.
>
>
>i think you want to hook into comment_validate(). just add a hook here
>- there is already a hook_comment() waiting for you to add an
>operation.
>
>
>
>
>------------------------------------------------------------------------
>
>Mon, 08 Aug 2005 08:49:30 +0000 : Eaton
>
>I posted a patch a few days ago (http://drupal.org/node/28255) that adds
>validation and form construction hooks for comments. It's similar to the
>one that the captcha module uses, though it adds comment form_pre and
>form_post hooks instead of a single comment form hook.
>
>
>
>
>------------------------------------------------------------------------
>
>Mon, 08 Aug 2005 13:30:34 +0000 : Jeremy at kerneltrap.org
>
>Attachment: http://drupal.org/files/issues/comment.module_11.patch (2.5 KB)
>
>> even if you get this fixed, won't these bots just add a preview step?
>
>
>Eventually, yes, but it drastically changes their ability to fling spam
>at a site. As is, they simply have a script that shoots data out at
>high speed without having to wait for messages to return from the
>server. It is the server that is doing all the work, thus making it
>simple for a spammer to DoS a site.
>
>
>If "preview required" really meant "preview required", they would be
>forced to first automate clicking "preview", and then wait for a
>response before clicking "submit". This requires more resources on
>their side, and allows us to add delays after clicking "preview" (if we
>detect that they are a spammer) further using their resources.
>
>
>> this 'preview required' feature is designed to maintain high quality
>> submissions by forcing users to proof read. it isn;t designed for
>security.
>
>
>Regardless of the intention, I was misled to believe that configuring
>my site to require previews would require that all comments were first
>previewed. As a site administrator, I would prefer to know that
>"required" really means "required".
>
>
>> i think you want to hook into comment_validate(). just add a hook
>here -
>> there is already a hook_comment() waiting for you to add an
>operation.
>
>
>Yes and no. Ultimately yes that will work and will allow my spam
>module to prevent the spam from ever being posted. But it still leaves
>the greatest burden on the web server, instead of on the spammer. The
>spammer can still use a very simple script that only pushes data, and
>thus can generate spam at an unbelievable rapid rate.
>
>
>Here is an example patch to enforce "preview required". It's one idea,
>I'm sure there are better ones.
>
>
>
>
>------------------------------------------------------------------------
>
>Mon, 08 Aug 2005 14:01:38 +0000 : Jeremy at kerneltrap.org
>
>Attachment: http://drupal.org/files/issues/comment.module_12.patch (1.4 KB)
>
>Here's a second version of the patch that doesn't require any manual
>configuration.
>
>
>
>
>------------------------------------------------------------------------
>
>Mon, 08 Aug 2005 16:27:27 +0000 : Jose A Reyero
>
>I like this idea, and the patch looks good
>
>
>Still, I think it misses something, like some timestamp related hash,
>because once you get the hash code you can post multiple comments with
>that.
>
>
>Another problem I can think of is, what happens when a cron run happens
>between the preview and the post?? I'm afraid comments would get lost
>
>
>For this second problem, I think a key generated only once after module
>activation could do. About the first one....mmm... I'll sit down for a
>while and think.....
>
>
>
>
>------------------------------------------------------------------------
>
>Tue, 09 Aug 2005 12:27:20 +0000 : Jeremy at kerneltrap.org
>
>Attachment: http://drupal.org/files/issues/comment.module_13.patch (1.33 KB)
>
>> I think it misses something, like some timestamp related hash, because
>> once you get the hash code you can post multiple comments with that.
>
>
>Using a timestamp will mean that the comment form "expires". That is,
>if you wait too long to preview your comment, it will generate an error
>when you try to post.
>
>
>Yes, technically a spammer could post one real comment, then based on
>what was in the session from that they could post the same identical
>comment over and over, so long as it was attached to the same node.
>But this is not what they do, they try and spread their spam throughout
>your webpage. Furthermore, the spam module is perfectly capable of
>detecting and preventing this.
>
>
>> Another problem I can think of is, what happens when a cron run
>happens
>> between the preview and the post?? I'm afraid comments would get lost
>
>
>The key is only generated once, that's what the first test is about.
>In any case, in the unlikely event that the key were to change between
>preview and post they would simply have to post a second time.
>
>
>My earlier patch wasn't quite right, I was testing the token in the
>wrong place. This patch fixes that.
>
>
>BTW: This is beneficial for maintaining high quality submissions too,
>as prior to this change someone could:
> 1) enter a comment
> 2) press preview
> 3) completely change their comment (introducing a mistake)
> 4) press submit and the comment (mistake and all) would go into the
>database unpreviewed
>
>
>After this change:
> 1) enter a comment
> 2) press preview
> 3) completely change their comment (introducing a mistake)
> 4) press submit and they get an error because they didn't preview
>their changes - forcing them to preview once after any change
>
>
>
>
>------------------------------------------------------------------------
>
>Wed, 10 Aug 2005 03:50:33 +0000 : Jeremy at kerneltrap.org
>
>FWIW: I've been getting slammed by spam attacks this whole week.
>Installing this patch has made a huge difference. Well over 100 spam
>attempts per minute (sometimes two and three times that) and I hardly
>notice the spammer, whereas before it was choking my database.
>
>
>(Granted, the spammer has not yet upgraded his script to first preview,
>then submit. But even if he did it wouldn't help him as testing has
>verified that the new spam module would prevent the comments from ever
>getting to the database.)
>
>
>Additionally, user and anonymous (nonspam) comments continue to show up
>at a normal rate.
>
>
>
>
>------------------------------------------------------------------------
>
>Tue, 16 Aug 2005 14:08:04 +0000 : Jeremy at kerneltrap.org
>
>I would love to see _any_ discussion on this. Drupal is currently too
>easy to spam, with little effort on the spammer's side, and lots of
>resources wasted on the Drupal side. A patch like this will greatly
>increase the spammer's burden, and make it possible to effectively
>block even the most aggressive spammer attacks.
>
>
>
>
>------------------------------------------------------------------------
>
>Wed, 17 Aug 2005 16:24:04 +0000 : Jose A Reyero
>
>Well, this patch is definitely better than what we have, and would save
>some spam for sure.
>
>
>But maybe keeping track, at the session level, of generated hashes for
>a user, and then removing them when the comment is sent, could do the
>work.
>
>
>This way we can forget about previewing comments or not, and also the
>"permission" to post the comment would expire when the session expires.
>Any randomly generated value could do for this, no need for complex
>hashes, but having nid and pid in the hash would add some extra
>security.
>
>
>
>
>------------------------------------------------------------------------
>
>Wed, 17 Aug 2005 19:58:02 +0000 : breyten
>
>Jeremy, a big +1 on the idea, but why not generate the private key when
>it is actually needed (Ie, when displaying the comment form), instead
>of wasting a _cron() hook on it?
>
>
>
>
>------------------------------------------------------------------------
>
>Thu, 18 Aug 2005 03:20:02 +0000 : Jeremy at kerneltrap.org
>
>> Well, this patch is definitely better than what we have, and would
>save some spam for sure.
>
>
>It is continuing to work very well on my site, which seems to be under
>nearly perpetual spam attacks from multiple sources.
>
>
>> But maybe keeping track, at the session level, of generated hashes
>for a user, and then
>> removing them when the comment is sent, could do the work.
>
>
>The catch is: the key has to be something unique to the server, not
>guessable or learnable from the outside Simply storing the hash data
>in the session alone is not enough, as then the spammer could create
>any random data and store it in the session.
>
>
>That said, the hash could be generated off something other than the
>text of the comment as it is now, so that a preview is not required.
>I'll look at doing something like that and submit another patch.
>
>
>> This way we can forget about previewing comments or not, and also the
>"permission" to
>> post the comment would expire when the session expires. Any randomly
>generated value
>> could do for this, no need for complex hashes, but having nid and pid
>in the hash would
>> add some extra security.
>
>
>nid and pid alone are worthless, as they are easy to learn. The pid
>can always be 0 (spam is rarely attached to a pre-existing comment).
>The nid is obtained in the path of where the spam is being posted.
>
>
>The solution is a "private-key", which is what my patch adds. Then
>sure, hash the private key plus the nid and the pid, and you've got
>enough protection to prevent most spammers. To make it even more
>secure, automatic rey-keying could be easily accomplished.
>
>
>
>
>------------------------------------------------------------------------
>
>Thu, 18 Aug 2005 04:09:10 +0000 : Jeremy at kerneltrap.org
>
>Attachment: http://drupal.org/files/issues/comment.module_15.patch (1.18 KB)
>
>The attached patch:
> 1) gets rid of the _cron() hook
> 2) no longer requires that comments be previewed
>
>
>Prior to this patch, comment spammers were able to send data to a
>Drupal server acting as though they'd filled out a comment form and
>pressed submit. As they didn't actually use the form, they could
>submit spam comments at an obscene rate.
>
>
>With this patch, comment spammers will have to actually load the form,
>enter text, and press submit. Yes, that can still be automated, but it
>takes much more work and slows them down, as they have to wait for the
>entry form to load each time.
>
>
>Unfortunately a spammer could manually submit one comment, then re-use
>that same session info over and over to attach repeated spam comments
>to the same node. Such an attempt would be detected and blocked by the
>spam module if enabled, but again such a session re-use attack could be
>done without loading the form each time. Fortunately there is much
>less gain for a spammer to submit 100 spam comments on the same page,
>versus submitting 100 spam comments each on a different page as they do
>now.
>
>
>Ideas to improve upon this concept include:
> - re-key every day or week, changing the private key regularly to be
>sure it couldn't ever be permanently cracked
> - add a key table, and generate a unique key for every comment form.
>essentially, upon comment form creation generate a random key which is
>stored both in a database table and in the session. when a comment is
>submited, look for the key from the session in the database table, if a
>match is found delete it from the database table and post the comment.
>this would prevent session re-use, but adds overhead. i don't know if
>it's worth it, perhaps as an external module if the hooks were
>available.
>
>
>
>
>------------------------------------------------------------------------
>
>Fri, 19 Aug 2005 18:55:11 +0000 : drumm
>
>
><?php
>form_set_error('error',В═t('ValidationВ═error,В═pleaseВ═beВ═sureВ═cookiesВ═areВ═enabledВ═onВ═yourВ═browser.'));
>?>
>
>
>
>
>form_set_error [2]()'s fist argument should be the name of a form
>field, not 'error.' Using (..., 'error') would be better in this case.
>
>
>And the actual message needs work. Since this is a hidden field I don't
>think it has anything to do with cookies.
>[2] http://drupaldocs.org/api/head/function/form_set_error
>
>
>
>
>------------------------------------------------------------------------
>
>Fri, 19 Aug 2005 18:56:41 +0000 : drumm
>
>The unclosed link in my last update was supposed to say
>drupal_set_message(..., 'error')
>
>
>
>
>------------------------------------------------------------------------
>
>Sat, 20 Aug 2005 16:00:15 +0000 : Jeremy at kerneltrap.org
>
>Attachment: http://drupal.org/files/issues/comment.module_16.patch (1.11 KB)
>
>drupal_set_message(..., 'error') isn't sufficient to prevent the comment
>from being posted. I have instead updated the patch to set the error on
>the hidden 'token' form field.
>
>
>I have updated the message to read:
>"Unable to validate your comment, please try again. If this error
>persists, please contact the site administrator."
>
>
>If you don't like the error message, better suggestions are welcome.
>
>
>
>
>------------------------------------------------------------------------
>
>Fri, 09 Sep 2005 03:16:06 +0000 : Jeremy at kerneltrap.org
>
>Any feedback on this patch? I have been running it on my website for a
>couple of weeks, and it has completely stopped the most persistent
>auto-spam scripts that had been posting poker type comments constantly
>to my site.
>
>
>
>
>------------------------------------------------------------------------
>
>Sat, 10 Sep 2005 18:12:15 +0000 : Zed Pobre
>
>This patch is against HEAD? It doesn't want to apply to my 2.6.3
>comment.module.
>
>
>
>
>------------------------------------------------------------------------
>
>Sun, 11 Sep 2005 18:09:08 +0000 : Abalieno
>
>It's is for cvs but I'm trying to manually apply it to 4.6.3.
>
>
>Will comment later to tell how it went.
>
>
>
>
>------------------------------------------------------------------------
>
>Mon, 12 Sep 2005 19:49:17 +0000 : Abalieno
>
>Well, it worked.
>
>
>No spam at all in more than a day. I don't know if other users are
>having problem but this patch broke the tool the spammer was using.
>
>
>:)
>
>
>
>
>------------------------------------------------------------------------
>
>Wed, 14 Sep 2005 02:47:40 +0000 : Jeremy at kerneltrap.org
>
>Attachment: http://drupal.org/files/issues/form_validation.patch (2.72 KB)
>
>Here's a completely rewritten version of the patch, based on an email
>discussion with Dries. This provides a more generic interface that can
>be used to validate other form submissions, not just comments. The
>patch introduces two new functions, form_token() and form_validate().
>The first function uses a private key and a public key to set a token
>in a hidden field. The second function validates the token. The patch
>also updates the comment module, demonstrating how these new functions
>are used.
>
>
>More information as to how the patch works can be found in the comments
>that are within the code.
>
>
>Based on my own experiences on kerneltrap.org, this patch blocks 99% of
>the current comment spammers.
>
>
>
>
>
>
>------------------------------
>
>Message: 2
>Date: Tue, 13 Sep 2005 20:58:35 -0700
>From: Jeremy <drupal-devel at drupal.org>
>Subject: [drupal-devel] [bug] comment preview "Required" is easily
> bypassed
>To: drupal-devel at drupal.org
>Message-ID: <type=project&nid=28420&cid=44270&host=@drupal.org>
>Content-Type: text/plain; charset=UTF-8; format=flowed
>
>Issue status update for
>http://drupal.org/node/28420
>Post a follow up:
>http://drupal.org/project/comments/add/28420
>
> Project: Drupal
> Version: cvs
> Component: comment.module
> Category: bug reports
> Priority: normal
> Assigned to: Jeremy at kerneltrap.org
> Reported by: Jeremy at kerneltrap.org
> Updated by: Jeremy at kerneltrap.org
> Status: patch (code needs review)
> Attachment: http://drupal.org/files/issues/contact.module_8.patch (1.44 KB)
>
>This third patch updates the contact.module to use the new form token
>validation functions.
>
>
>Note that this is not yet a perfect solution. Someone wanting to spam
>the contact form could manually fill it out once to obtain a valid
>token. They could then use that token to spam the contact form
>repeatedly, so long as they don't change the fields that were used to
>generate the token.
>
>
>The solution is to keep a history of recently validated tokens. Each
>time a token is validated, make sure it was not already recently
>validated -- if it was, don't allow it a second time. I would be happy
>to provide patches for this if it is deemed necessary, and these first
>patches are merged. It would require a new database table, and a
>db_query to validate the token. Ideas for alternative solutions are
>welcome.
>
>
>
>
>Jeremy at kerneltrap.org
>
>
>
>Previous comments:
>------------------------------------------------------------------------
>
>Mon, 08 Aug 2005 01:55:34 +0000 : Jeremy at kerneltrap.org
>
>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?
>[1] http://kerneltrap.org/jeremy/drupal/spam/
>
>
>
>
>------------------------------------------------------------------------
>
>Mon, 08 Aug 2005 02:26:21 +0000 : moshe weitzman
>
>even if you get this fixed, won't these bots just add a preview step?
>
>
>this 'preview required' feature is designed to maintain high quality
>submissions by forcing users to proof read. it isn;t designed for
>security.
>
>
>i think you want to hook into comment_validate(). just add a hook here
>- there is already a hook_comment() waiting for you to add an
>operation.
>
>
>
>
>------------------------------------------------------------------------
>
>Mon, 08 Aug 2005 08:49:30 +0000 : Eaton
>
>I posted a patch a few days ago (http://drupal.org/node/28255) that adds
>validation and form construction hooks for comments. It's similar to the
>one that the captcha module uses, though it adds comment form_pre and
>form_post hooks instead of a single comment form hook.
>
>
>
>
>------------------------------------------------------------------------
>
>Mon, 08 Aug 2005 13:30:34 +0000 : Jeremy at kerneltrap.org
>
>Attachment: http://drupal.org/files/issues/comment.module_11.patch (2.5 KB)
>
>> even if you get this fixed, won't these bots just add a preview step?
>
>
>Eventually, yes, but it drastically changes their ability to fling spam
>at a site. As is, they simply have a script that shoots data out at
>high speed without having to wait for messages to return from the
>server. It is the server that is doing all the work, thus making it
>simple for a spammer to DoS a site.
>
>
>If "preview required" really meant "preview required", they would be
>forced to first automate clicking "preview", and then wait for a
>response before clicking "submit". This requires more resources on
>their side, and allows us to add delays after clicking "preview" (if we
>detect that they are a spammer) further using their resources.
>
>
>> this 'preview required' feature is designed to maintain high quality
>> submissions by forcing users to proof read. it isn;t designed for
>security.
>
>
>Regardless of the intention, I was misled to believe that configuring
>my site to require previews would require that all comments were first
>previewed. As a site administrator, I would prefer to know that
>"required" really means "required".
>
>
>> i think you want to hook into comment_validate(). just add a hook
>here -
>> there is already a hook_comment() waiting for you to add an
>operation.
>
>
>Yes and no. Ultimately yes that will work and will allow my spam
>module to prevent the spam from ever being posted. But it still leaves
>the greatest burden on the web server, instead of on the spammer. The
>spammer can still use a very simple script that only pushes data, and
>thus can generate spam at an unbelievable rapid rate.
>
>
>Here is an example patch to enforce "preview required". It's one idea,
>I'm sure there are better ones.
>
>
>
>
>------------------------------------------------------------------------
>
>Mon, 08 Aug 2005 14:01:38 +0000 : Jeremy at kerneltrap.org
>
>Attachment: http://drupal.org/files/issues/comment.module_12.patch (1.4 KB)
>
>Here's a second version of the patch that doesn't require any manual
>configuration.
>
>
>
>
>------------------------------------------------------------------------
>
>Mon, 08 Aug 2005 16:27:27 +0000 : Jose A Reyero
>
>I like this idea, and the patch looks good
>
>
>Still, I think it misses something, like some timestamp related hash,
>because once you get the hash code you can post multiple comments with
>that.
>
>
>Another problem I can think of is, what happens when a cron run happens
>between the preview and the post?? I'm afraid comments would get lost
>
>
>For this second problem, I think a key generated only once after module
>activation could do. About the first one....mmm... I'll sit down for a
>while and think.....
>
>
>
>
>------------------------------------------------------------------------
>
>Tue, 09 Aug 2005 12:27:20 +0000 : Jeremy at kerneltrap.org
>
>Attachment: http://drupal.org/files/issues/comment.module_13.patch (1.33 KB)
>
>> I think it misses something, like some timestamp related hash, because
>> once you get the hash code you can post multiple comments with that.
>
>
>Using a timestamp will mean that the comment form "expires". That is,
>if you wait too long to preview your comment, it will generate an error
>when you try to post.
>
>
>Yes, technically a spammer could post one real comment, then based on
>what was in the session from that they could post the same identical
>comment over and over, so long as it was attached to the same node.
>But this is not what they do, they try and spread their spam throughout
>your webpage. Furthermore, the spam module is perfectly capable of
>detecting and preventing this.
>
>
>> Another problem I can think of is, what happens when a cron run
>happens
>> between the preview and the post?? I'm afraid comments would get lost
>
>
>The key is only generated once, that's what the first test is about.
>In any case, in the unlikely event that the key were to change between
>preview and post they would simply have to post a second time.
>
>
>My earlier patch wasn't quite right, I was testing the token in the
>wrong place. This patch fixes that.
>
>
>BTW: This is beneficial for maintaining high quality submissions too,
>as prior to this change someone could:
> 1) enter a comment
> 2) press preview
> 3) completely change their comment (introducing a mistake)
> 4) press submit and the comment (mistake and all) would go into the
>database unpreviewed
>
>
>After this change:
> 1) enter a comment
> 2) press preview
> 3) completely change their comment (introducing a mistake)
> 4) press submit and they get an error because they didn't preview
>their changes - forcing them to preview once after any change
>
>
>
>
>------------------------------------------------------------------------
>
>Wed, 10 Aug 2005 03:50:33 +0000 : Jeremy at kerneltrap.org
>
>FWIW: I've been getting slammed by spam attacks this whole week.
>Installing this patch has made a huge difference. Well over 100 spam
>attempts per minute (sometimes two and three times that) and I hardly
>notice the spammer, whereas before it was choking my database.
>
>
>(Granted, the spammer has not yet upgraded his script to first preview,
>then submit. But even if he did it wouldn't help him as testing has
>verified that the new spam module would prevent the comments from ever
>getting to the database.)
>
>
>Additionally, user and anonymous (nonspam) comments continue to show up
>at a normal rate.
>
>
>
>
>------------------------------------------------------------------------
>
>Tue, 16 Aug 2005 14:08:04 +0000 : Jeremy at kerneltrap.org
>
>I would love to see _any_ discussion on this. Drupal is currently too
>easy to spam, with little effort on the spammer's side, and lots of
>resources wasted on the Drupal side. A patch like this will greatly
>increase the spammer's burden, and make it possible to effectively
>block even the most aggressive spammer attacks.
>
>
>
>
>------------------------------------------------------------------------
>
>Wed, 17 Aug 2005 16:24:04 +0000 : Jose A Reyero
>
>Well, this patch is definitely better than what we have, and would save
>some spam for sure.
>
>
>But maybe keeping track, at the session level, of generated hashes for
>a user, and then removing them when the comment is sent, could do the
>work.
>
>
>This way we can forget about previewing comments or not, and also the
>"permission" to post the comment would expire when the session expires.
>Any randomly generated value could do for this, no need for complex
>hashes, but having nid and pid in the hash would add some extra
>security.
>
>
>
>
>------------------------------------------------------------------------
>
>Wed, 17 Aug 2005 19:58:02 +0000 : breyten
>
>Jeremy, a big +1 on the idea, but why not generate the private key when
>it is actually needed (Ie, when displaying the comment form), instead
>of wasting a _cron() hook on it?
>
>
>
>
>------------------------------------------------------------------------
>
>Thu, 18 Aug 2005 03:20:02 +0000 : Jeremy at kerneltrap.org
>
>> Well, this patch is definitely better than what we have, and would
>save some spam for sure.
>
>
>It is continuing to work very well on my site, which seems to be under
>nearly perpetual spam attacks from multiple sources.
>
>
>> But maybe keeping track, at the session level, of generated hashes
>for a user, and then
>> removing them when the comment is sent, could do the work.
>
>
>The catch is: the key has to be something unique to the server, not
>guessable or learnable from the outside Simply storing the hash data
>in the session alone is not enough, as then the spammer could create
>any random data and store it in the session.
>
>
>That said, the hash could be generated off something other than the
>text of the comment as it is now, so that a preview is not required.
>I'll look at doing something like that and submit another patch.
>
>
>> This way we can forget about previewing comments or not, and also the
>"permission" to
>> post the comment would expire when the session expires. Any randomly
>generated value
>> could do for this, no need for complex hashes, but having nid and pid
>in the hash would
>> add some extra security.
>
>
>nid and pid alone are worthless, as they are easy to learn. The pid
>can always be 0 (spam is rarely attached to a pre-existing comment).
>The nid is obtained in the path of where the spam is being posted.
>
>
>The solution is a "private-key", which is what my patch adds. Then
>sure, hash the private key plus the nid and the pid, and you've got
>enough protection to prevent most spammers. To make it even more
>secure, automatic rey-keying could be easily accomplished.
>
>
>
>
>------------------------------------------------------------------------
>
>Thu, 18 Aug 2005 04:09:10 +0000 : Jeremy at kerneltrap.org
>
>Attachment: http://drupal.org/files/issues/comment.module_15.patch (1.18 KB)
>
>The attached patch:
> 1) gets rid of the _cron() hook
> 2) no longer requires that comments be previewed
>
>
>Prior to this patch, comment spammers were able to send data to a
>Drupal server acting as though they'd filled out a comment form and
>pressed submit. As they didn't actually use the form, they could
>submit spam comments at an obscene rate.
>
>
>With this patch, comment spammers will have to actually load the form,
>enter text, and press submit. Yes, that can still be automated, but it
>takes much more work and slows them down, as they have to wait for the
>entry form to load each time.
>
>
>Unfortunately a spammer could manually submit one comment, then re-use
>that same session info over and over to attach repeated spam comments
>to the same node. Such an attempt would be detected and blocked by the
>spam module if enabled, but again such a session re-use attack could be
>done without loading the form each time. Fortunately there is much
>less gain for a spammer to submit 100 spam comments on the same page,
>versus submitting 100 spam comments each on a different page as they do
>now.
>
>
>Ideas to improve upon this concept include:
> - re-key every day or week, changing the private key regularly to be
>sure it couldn't ever be permanently cracked
> - add a key table, and generate a unique key for every comment form.
>essentially, upon comment form creation generate a random key which is
>stored both in a database table and in the session. when a comment is
>submited, look for the key from the session in the database table, if a
>match is found delete it from the database table and post the comment.
>this would prevent session re-use, but adds overhead. i don't know if
>it's worth it, perhaps as an external module if the hooks were
>available.
>
>
>
>
>------------------------------------------------------------------------
>
>Fri, 19 Aug 2005 18:55:11 +0000 : drumm
>
>
><?php
>form_set_error('error',В═t('ValidationВ═error,В═pleaseВ═beВ═sureВ═cookiesВ═areВ═enabledВ═onВ═yourВ═browser.'));
>?>
>
>
>
>
>form_set_error [2]()'s fist argument should be the name of a form
>field, not 'error.' Using (..., 'error') would be better in this case.
>
>
>And the actual message needs work. Since this is a hidden field I don't
>think it has anything to do with cookies.
>[2] http://drupaldocs.org/api/head/function/form_set_error
>
>
>
>
>------------------------------------------------------------------------
>
>Fri, 19 Aug 2005 18:56:41 +0000 : drumm
>
>The unclosed link in my last update was supposed to say
>drupal_set_message(..., 'error')
>
>
>
>
>------------------------------------------------------------------------
>
>Sat, 20 Aug 2005 16:00:15 +0000 : Jeremy at kerneltrap.org
>
>Attachment: http://drupal.org/files/issues/comment.module_16.patch (1.11 KB)
>
>drupal_set_message(..., 'error') isn't sufficient to prevent the comment
>from being posted. I have instead updated the patch to set the error on
>the hidden 'token' form field.
>
>
>I have updated the message to read:
>"Unable to validate your comment, please try again. If this error
>persists, please contact the site administrator."
>
>
>If you don't like the error message, better suggestions are welcome.
>
>
>
>
>------------------------------------------------------------------------
>
>Fri, 09 Sep 2005 03:16:06 +0000 : Jeremy at kerneltrap.org
>
>Any feedback on this patch? I have been running it on my website for a
>couple of weeks, and it has completely stopped the most persistent
>auto-spam scripts that had been posting poker type comments constantly
>to my site.
>
>
>
>
>------------------------------------------------------------------------
>
>Sat, 10 Sep 2005 18:12:15 +0000 : Zed Pobre
>
>This patch is against HEAD? It doesn't want to apply to my 2.6.3
>comment.module.
>
>
>
>
>------------------------------------------------------------------------
>
>Sun, 11 Sep 2005 18:09:08 +0000 : Abalieno
>
>It's is for cvs but I'm trying to manually apply it to 4.6.3.
>
>
>Will comment later to tell how it went.
>
>
>
>
>------------------------------------------------------------------------
>
>Mon, 12 Sep 2005 19:49:17 +0000 : Abalieno
>
>Well, it worked.
>
>
>No spam at all in more than a day. I don't know if other users are
>having problem but this patch broke the tool the spammer was using.
>
>
>:)
>
>
>
>
>------------------------------------------------------------------------
>
>Wed, 14 Sep 2005 02:47:40 +0000 : Jeremy at kerneltrap.org
>
>Attachment: http://drupal.org/files/issues/form_validation.patch (2.72 KB)
>
>Here's a completely rewritten version of the patch, based on an email
>discussion with Dries. This provides a more generic interface that can
>be used to validate other form submissions, not just comments. The
>patch introduces two new functions, form_token() and form_validate().
>The first function uses a private key and a public key to set a token
>in a hidden field. The second function validates the token. The patch
>also updates the comment module, demonstrating how these new functions
>are used.
>
>
>More information as to how the patch works can be found in the comments
>that are within the code.
>
>
>Based on my own experiences on kerneltrap.org, this patch blocks 99% of
>the current comment spammers.
>
>
>
>
>------------------------------------------------------------------------
>
>Wed, 14 Sep 2005 03:16:21 +0000 : Jeremy at kerneltrap.org
>
>Attachment: http://drupal.org/files/issues/form_validate-2.patch (1.1 KB)
>
>This optional patch is intended to be applied after my
>form_validation.patch attached to #20 above. It makes the
>drupal_private_key more secure by regenerating it every 24 hours.
>Without this patch, it would be possible for a spammer to use
>brute-force to learn a site's private key by reading the code and
>observing the token generated for a given form. With this patch, brute
>force is still possible, but with this patch it would have to be done
>every 24 hours.
>
>
>It is possible for a form to be generated prior to a rekey, and then to
>be validated after a rekey. In this event, the key will fail validation
>and the user will see a message telling them something like "Validation
>error, please try again. If this error persists, please contact the
>site administrator." When they try pressing "submit" again it will
>work fine.
>
>
>I kept this patch separate as it adds complexity that may not be
>desired in core. Personally I think it is important and should be
>merged along with the first patch. I added it to the system module as
>it seemed the most logical place, and is a "required" module that can
>not be disabled.
>
>
>
>
>
>
>------------------------------
--
Сегодня удачный день, чтобы завести почту на Яндексе http://mail.yandex.ru
More information about the drupal-devel
mailing list