comment form nonce

[tellyworth]

This adds a nonce to public comment forms, via the comment_form action.

[scribu]

Can non-logged-in users still comment?

[johnbillion]

I don't see what this solves. I assume it's attempting to prevent automated commenting by bots. The nonce will be identical for every non-logged in visitor so it'll be very easy for an automated comment bot to get this nonce and use it in its requests, and then we're back to square one.

Scribu: yes they can.

[filosofo]

An admin has greater posting privileges than a non-logged-in user, so there would be some advantage just in preventing XSS-commenting for only logged-in users.

And perhaps we could use the client's IP address in the nonce hash when generating it for non-logged-in users?

[tellyworth]

"I don't see what this solves. I assume it's attempting to prevent automated commenting by bots. The nonce will be identical for every non-logged in visitor so it'll be very easy for an automated comment bot to get this nonce and use it in its requests, and then we're back to square one."

It blocks several things:

1. Dumb bots that just drive-by POST without fetching the page. These are still very common, so it will block a substantial amount of spam.

2. XSS attacks that try to defeat spam filters by tricking real people into submitting an anonymous comment on another blog. Currently rare, but there's no reason to wait until it becomes common.

3. Slightly less dumb bots that do a single fetch on a blog first, then submit many comments on multiple posts. This won't work with the patch applied because the nonce is unique to each post.

This is not intended to block all spam (that's the job of specialized plugins), just raise the bar a little by eliminating the simplest attacks.

filosofo, incorporating the client's IP address would block some legitimate comments. There is scope for hashing and checking additional info, but I think that's the job of spam filtering plugins, not core (that sort of stuff has to change frequently for it to be effective).

[westi]

Nice idea.

I don't think we should use normal nonces for this.

I think it is better that we have a different class of "nonce" for use on the frontend for non-logged in users.

We can then enforce the usage of the current nonces for logged in users only.

[Denis-de-Bernardy]

you can also use wp-hashcash...

in case anyone missed it, such a patch can have severe implications when it comes to caching.

[scribu]

Punting, pending more discussion.

[ryanhellyer]

I just came across this ticket now via a Google search (I need to do something similar for another project).

This seems like something far more suitable for a plugin as I don't see any way of getting around this when caching heavily.

[mrmist]

Related forum post - ​http://wordpress.org/support/topic/wp-comments-postphp-misery

[scribu]

Related: #13791

[tellyworth]

refreshed patch tested against trunk

[johnbillion]

As per the comments above, this needs to take into consideration persistent caching mechanisms which can cause an out of date nonce to be delivered to a new visitor, preventing them from being able to leave a comment.

As also mentioned in the comments above, this affords no protection for anonymous users. If the nonce was only included and verified for logged in users, then it would solve both issues.

[snarebold]

As a result from a professional penetration test

Is it possible to perform CSRF attacks (regarding the comment form) ?
Yes, an attacker could e.g. integrate the comment form (HTTP POST) in a hidden iFrame and trick a victim to load this frame. In this way, an attacker could silently post arbitrary comments from the victim's IP address.

[egyptimhotep]

This should be in core!

[ocean90]

#40043 was marked as a duplicate.

[egyptimhotep]

I am sorry for duplicate, but I just want to emphasize the importance of the security.

[ayeshrajans]

Hello everyone,
I'm sorry for bringing years old issues back. I have created a new plugin ​https://wordpress.org/plugins/comment-form-csrf-protection/ for those who really care about this issue. I'd be happy to work on a core patch if it helps.

[bookdude13]

I'd like to renew interest in this as well. CSRF on the comment form might not be a complete solution, but I'd argue that it's better than no protection at all. As mentioned by @tellyworth it would stop some passive or drive-by attacks/spam. A more robust solution could be discussed and implemented in #10931.