Please eliminate wp-comments.php!

@rawalex – I read your ideas, but they really don’t get to the core of the problem, which is the ability to automate comment submissions.
Although your ideas would reduce the amount of spam your website visitors have to look at, they don’t stop the spam from being submitted in first place. If you stop the automation you stop 99% of the spam.

When I have more time I’ll clean my comments system up and package it for redistribution. Or if anyone else wants to try my comments system as it is now, let me know. It really just needs a code clean-up. I just don’t have time to do it right now because I am on a huge project.

You can find my comments system here – https://github.com/jasonlau/Spamless-WordPress-Comments.

Actually, it would get rid of much of the automated spam, because they almost all use the URL field in their posts to get a link. By automatically declining comments submitted with anything in that field (because you aren’t accepting it from your comment form) it would get rid of pretty much all of the direct comment spam (the ones that call wp-comments.php )

You can also add filters for a href and ahref and other variations as well, which gets rid of a bunch of the stupid ones, and decline anything with more than 2 links in it. That is a big part of your spam issue right there.

I agree with you, being able to rename the the wp-comments.php to something else would be a good way to stop it as well.

It wouldn’t work on BuddyPress sites, or many social networking WP installs, mind you. By default, if I’m logged in on a BP site, my URL becomes a link to my user profile. And clearly turning off the check for logged in users would serve no purpose, since any open-registration site would still have that problem. Also, looking at three sites (a very non-scientific check, I know), regular, legit posters often use their URLs.

It’s a good idea, but it doesn’t take into account the myriad ways people use WP, and would cause more harm.

“It’s a good idea, but it doesn’t take into account the myriad ways people use WP, and would cause more harm.”

It would only cause harm if it was “disable and never use”, which is not the idea. I suggest it as a check mark box in the configuration, defaulting to “disable urls” for the simplest of wordpress installs. Obviously, a site that uses buddy press or other methods could click the box and turn it back on.

For those who want to deal with those issues, they can still do it. But it would stop a great number of wordpress installs (especially less active ones) from becoming spamhaus sites, which many of them are.

Sorry, I disagree–if that becomes standard wordpress then it will be automated. It takes nothing for a bot to know how to go to one page before it goes to the next page, just like a human. It got rid of your spam because you’re the only one doing it.

It takes nothing for a bot to know how to go to one page before it goes to the next page, just like a human.

Untrue. The bot has to find the file first. If it’s name is static, you know, something like wp-comments-post.php, then it’s open season for spambots. If it’s name is randomized, or if the file doesn’t even exist, it can’t be found, except only by chance. Having a static file to process comments is a MISTAKE, a weakness, and a security hole. It doesn’t take a genius to figure that out. I don’t expect WP to begin a “spam fighting” campaign. However, it IS a hole in WP which allows spammers to successfully attack WP websites. How is it not the responsibility of the WP developers to address that lack of security in their own system? Other security holes are fixed. Why not this one? How is this one any different? Spam IS a security problem. WP enables spammers by design; a design that could be fixed. Why would WP even make a comments system if it’s not going to be made secure? If it’s not going to be secure, then don’t include it in the core. If it’s included in the core, then plan on people expecting you to fix the security holes without arguing about it. 3rd-party developers shouldn’t be expected to patch WP’s holes. I’ve heard it before … “There’s a plugin for that” … a plugin that patches a core security hole? Why does there even need to be one of those in the first place? Because WP is not secured by the developers. Because the developers rely on 3rd parties to fix a security hole? Apparently so. If I made a program which somehow enabled people (or bots) to successfully attack it, I would damn sure fix it.

Almost 50% of my search engine traffic is from people who are desperate to stop spam comments on their WP websites. Funny they should have to come to my website to fix a core WP problem.

What copperblade means, I believe, is that any METHOD that can be coded, can be coded around, and that is not incorrect.

If you end up making the wp-comments.php file named wp-comments-<random>.php, there has to be SOME way of translating that back to the app. If there’s a way, it has the potential to be exploited. Randominzing the name only works for as long as it’s an uncommon method of prevention. Once it’s common, the people who write bots will account for it as best they can.

Alas :/

But … but …. but … you’re wrong. C’mon guys, think outside of the box.

Go ahead and ignore the problem. That’s a great solution.

Almost 50% of my search engine traffic is from people who are desperate to stop spam comments on their WP websites. Funny they should have to come to my website to fix a core WP problem.

Thanks for the Google Adsense traffic though!!!

I suppose the beauty of open-source is, if you don’t like how someone else did it, you can always do it correctly yourself.

Good luck with your spam guys. ??

We’re not wrong, and I never said it was a bad idea (or shouldn’t be done). Hell, I was asking you, repeatedly, to please consider SHARING your code on trac.WordPress.com so the devs can look at seriously including it. You keep saying you have this great method, and then when we ask you to share it, you don’t. That’s not helping anyone.

But if you think I’m wrong that anything you can code can be coded around, then you’re a bit ignorant about how code works. The best way would be to use md5/hash to pull it off. That’s, thus far, unHACKED by normal means. But anything can be broken. Thats the beauty of code ??

If it’s name is randomized, or if the file doesn’t even exist, it can’t be found, except only by chance.

Then how does a user find it? Take greasemonkey for example–you can just write a script to pretend to be a user anyway. And if you send it to a user’s email, well we know that bots already know how to activate themselves.

Having a static file to process comments is a MISTAKE, a weakness, and a security hole.

Well maybe. Maybe not. It might be easier to lock down wp-comments.php if it’s more isolated. I think that any user that needs to access the comment function needs to have a form that allows them to submit to. (We’re still talking about asymmetric web-design, right?) So I think it might be much the same thing.

I agree with you 100% that spam is a security problem. (But I think you should submit it as a feature request anyway.)

Ipstenu explained it better than I did. If it’s simply a matter of redirection, it’s arguably easier to get around than something like a captcha. Captchas (used to) work because it required an extra computer (your brain) which was very fast and good at pattern matching, therefore leveraging something a human can do easily that a machine cannot do easily. As far as I can tell on various software, even captchas aren’t working well anymore and if they’ve actually figured out how to do the pattern matching as well as humans, then I don’t know what to do next.

If it’s working for you, then great. But I think this is a case that obscurity is part of your formula–I think part of the reason it’s working for you is that no one wants to write the code just to crack your sites (yet?). I think the moment you include it into WP, it’ll do little to prevent the spam for everyone, and just make you like the rest of us ??

Oh by the way, thanks for sharing it. I’m not trying to knock down your idea. For the people who find your code, I’m sure it will help. My opinion aside, if you file a bug to WP on it, then maybe your idea or something similar can get included: https://core.trac.www.ads-software.com/

@jason Lau: Renaming the file is a classic example of the whole “Club vs. Lojack” discussion:

https://diveintomark.org/archives/2002/10/29/club_vs_lojack_solutions

Basically, while this might work for you as one of the few people to do it as soon as everyone renames the file the spammers will adapt.

You have to provide a link to the file from the comment form in order for people to be able to submit comments so it is trivial for a comment spammer’s script to find the file before auto-spamming.

Most scripts already work this way so as to work around a number of other club solutions such as hidden form fields etc.

@peter
Renaming the file is only part of the process.
The file isn’t simply provided a new name.
The file is generated from template with a completely randomized name.
Part of the name is served to a cookie which is unique to the user.
The other part of the name is only known to WP.
The form should be coded with no form tag. Wrap the form upon submission and retrieve the file name key from the cookie to insert in the action attribute.

Basically, here’s how it works –

• User submits form
• A few submission checks and balances.
• Processing script is generated on server in a secret location which is created when WP is installed
• Set the file name key in a cookie
• Then, $(obj).wrap(‘<form action=”‘+$.cookie(‘action’)+'” method=”POST”></form>’);
• Submit()
• Be sure current processing script belongs to current user.
• Accept or deny submission.
• Delete processing script.

That’s it. The processing file can no longer be reused or targeted by spammers. That in itself eliminates most spam.

Where is the file name to be found? No file name even exists in the source, on the server, or even in the cookie for that matter. Only WP knows the real name of the processing script.

The form requires cookies and js. That’s 2 strikes against bots right there. There is no processing script to attack directly … there’s strike 3.
So, I’m not talking about simply renaming a file. Create a unique processing script for each individual which should only exist for the duration of the submission. This idea works. Use it if you like, ignore if you want, but it does work.

Really one of the biggest problems with wp-comments-post.php is that it can be reaccessed and reused as many times as a bot needs. Not just one bot, but the entire world’s bots can come and visit your copy of wp-comments-post.php because they all know where to find it by name.

I can create a random file on my server and I challenge anyone to find it. I will even set part of the file name in a cookie on your machine.

These are amateurish, low-tech bots that attack WP comments. Nothing special. No “stuxnet for WordPress”. This is kid’s play for any real hacker.

If you can eliminate spam-bots’ direct access to your processing script, if even by simple means, then you put the ball back in your playing field. You will then gain control of the form submission. Until then, forget it, you’re at the mercy of the bot.