Unfortunately it does not seem to have helped maybe if we could block accounts so they can't post if they already have got account might help

taftse said:

Unfortunately it does not seem to have helped maybe if we could block accounts so they can't post if they already have got account might help

They are persistent for sure.

This approach seems to have worked for David Walsh:

http://davidwalsh.name/wordpress-comment-spam

taftse said:

Unfortunately it does not seem to have helped maybe if we could block accounts so they can't post if they already have got account might help

Ping me on IRC during UK working hours and I'll happily ban spam accounts for you - hopefully I've not been missing too many the past week.

Is there anyway we can flag spam posts?

Five flags -> Post hidden till a moderator sees it Ten flags per user -> account disabled?

AlexanderWright said:

Is there anyway we can flag spam posts?

Five flags -> Post hidden till a moderator sees it Ten flags per user -> account disabled?

This would all be great and I have been contemplating on this and many other things but what I'd really like to prevent is for them to sign up in the first place.

Hoi Dries,

what about adding a honeypot to the signup confirmation page?

For example:

• 1. Add a hidden input server side (honeypot).
• 2.a) Add another hidden input client-side with javascript on form submit (this is not part of the honeypot).
• 2.b) For people with javascript disabled, add a captcha they need to fill out.
• 3. After submit, validate the form server side.

So, the honeypot may not be populated and the client-side added input needs to be present OR the captcha needs to be valid.

This way you won't need to show everyone a captcha as most devices have js enabled.

Let me know if you'd like to consider this idea.

MarkusHofmann said:

Hoi Dries,

what about adding a honeypot to the signup confirmation page?

For example:

• 1. Add a hidden input server side (honeypot).
• 2.a) Add another hidden input client-side with javascript on form submit (this is not part of the honeypot).
• 2.b) For people with javascript disabled, add a captcha they need to fill out.
• 3. After submit, validate the form server side.

So, the honeypot may not be populated and the client-side added input needs to be present OR the captcha needs to be valid.

This way you won't need to show everyone a captcha as most devices have js enabled.

Let me know if you'd like to consider this idea.

Tried it, didn't work. Spam still got through.

Seriously, I've tried every trick in the book. You name it, I've tried it :-/

I'm going to give @njames his solution a try. Seems like a solid one.

This topic could be covered in another useful tutorial by Jeffrey on laracasts. Didn't see any spam protection lesson there yet.

I've implemented @njames his suggestion now. Let's see how that works.

driesvints said:

I've implemented @njames his suggestion now. Let's see how that works.

Interesting idea, I might have to try that on one of my web forms ...

Doesn't look like they are spam BOTS, so captcha on signup page barely stops them.

I would second @AlexanderWright's idea of softdeleting their account & posts. And then a moderator could either resume or dissolve their account.

My 2 cents... Maybe should use spam database API service to check incoming IP address before letting people post / register ?

driesvints said:

I've implemented @njames his suggestion now. Let's see how that works.

I'm sorry to report that this has not worked - I've just cleaned up about 5 accounts and associated posts this morning. :(

sparksp said:

driesvints said:

I've implemented @njames his suggestion now. Let's see how that works.

I'm sorry to report that this has not worked - I've just cleaned up about 5 accounts and associated posts this morning. :(

I'm now 99% sure that the accounts get signed up manually. Because this just isn't possible anymore.

I'm going to try something else. Will let you guys know when it's in place.

Just something interesting: a google search at the latest spammer, "subhashbaba93"

I successful anti-spam method I use basically revolves around:

1. Create 2 hashs, key & value
2. Store them in session, along with the time
3. Add them to the form as a hidden input (name = key, value = value)
4. When form is sent, check these are correct, but also check the time that has elapsed. If it's less than 4 seconds (adjust this based on length of form), the form is rejected.

Basically, spam bots are going to fill the form in quicker than a human can, so the check is to see if it's too fast for a human. The key & value are just checking that they did visit the site rather than just posting the form without visiting, but this is easy for a bot to get around as it can just GET the page before submitting, I think the time elapsed check is the stronger component, but no reason to not have them both.

Of course, if it's manual spam than not much can be done.

I also limit the form submissions per IP by storing it in a database and seeing how many have occurred from that IP in the last X minutes/hours. That is one method that can help against manual spam.

DeanStr said:

I successful anti-spam method I use basically revolves around:

1. Create 2 hashs, key & value
2. Store them in session, along with the time
3. Add them to the form as a hidden input (name = key, value = value)
4. When form is sent, check these are correct, but also check the time that has elapsed. If it's less than 4 seconds (adjust this based on length of form), the form is rejected.

Basically, spam bots are going to fill the form in quicker than a human can, so the check is to see if it's too fast for a human. The key & value are just checking that they did visit the site rather than just posting the form without visiting, but this is easy for a bot to get around as it can just GET the page before submitting, I think the time elapsed check is the stronger component, but no reason to not have them both.

Of course, if it's manual spam than not much can be done.

I also limit the form submissions per IP by storing it in a database and seeing how many have occurred from that IP in the last X minutes/hours. That is one method that can help against manual spam.

That specific anti-spam measure is actually in place atm. Threads need to have a 5 second delay before they can be submitted. Replies (which aren't affected by spam atm) 2 seconds.

The IP addresses are varying a lot. They constantly change.

sparksp said:

driesvints said:

I've implemented @njames his suggestion now. Let's see how that works.

I'm sorry to report that this has not worked - I've just cleaned up about 5 accounts and associated posts this morning. :(

Yeah, it was to early to ping you on IRC when the spam started showing up.

driesvints said: The IP addresses are varying a lot. They constantly change.

Sounds like they are using web proxies to create the accounts, happened to one of my clients sites. After a month of persistence in removing their posts as quickly as possible they gave up. That along with blacklisting ip's, once I found the they were web proxies.

Notice that spams are actually advertisements with contact details (phone numbers) on them.

We can blocklist these numbers they are trying to advertise. Thus, anytime they post a thread and these blacklisted texts are found, we will simply deny posting and/or ban them.

New email accounts are easy to create, new github account are just a click away but new phone numbers, naa ! ;)

That's not a bad idea i think.. filter out any title that matches xx-xxxxxxxxx .

RemiCollin said:

That's not a bad idea i think.. filter out any title that matches xx-xxxxxxxxx .

That might be a good idea, as they have returned already.

We use https://packagist.org/packages/devfactory/mollom that will submit the posts to Mollom and weed off the spam.

You could try checking the IP address against known Tor nodes. I've done this before in the past to prevent credit card fraud attempts.

I know this isn't the most constructive because it doesn't involve more than a finger pointed to a direction. But, how about looking into Google Prediction API to check if a post is spam or not? Perhaps that would add more intelligence to the process.

After reading this thread and seeing that spam is still getting posted I am becoming more and more interested in what is happening here. I have been fighting spam for 12 years as a professional and I am totally intrigued.

Any chances of getting a peak at some of the logs, and any post data you might have captured for some of these?

It sounds like you have done everything right and gone above and beyond what I normally do and I have never had it persist like this. I abhor spam but at this point I am almost impressed by their success, that said I'd like to take a stab at crushing them lol

I wouldn't be surprised if these were actual people signing in, being paid to do that sort of stuff on regular basis, on different websites. In such case no measure that allows regular people to pass can stop them. Good to have the measures about actual bots in place, still.

Is it possible to make it so that the user's very first post must be approved by moderator and isn't publicly visible until then? I doubt many spammers would care enough to make their first post "normal" so that they would flood boards with spam later. Of course, it requires some work from mods still, but I guess it's not much different than what they have now. The biggest drawback would be very new users having their questions not visible immediately, I guess...?

(also, is there any way to report spam posts?)

• You can do 2 factor auth with sending SMS on mobile while registering new user. If user is spammer you can block that user, So he can not register again with that mobile number .

• Add a option like 'Mark as spam' in posts, if more than 5 users think post is spam then block that post. If same post owner makes more than 3-5 spam posts then block that user automatically.

This will reduce work of moderator.

In past, I have used "http-only" cookie set as hidden token , injected by jquery during submit button in form, and it worked for a week , but than spam again started after a week or so, Thus, i assumed, may be spammer found the name, i am using as hidden value, so i did something that pissed spammer.

I generated unique name along with value and created an hidden input and injected into form, everytime form is created, so it creates token like :-

$pee_on_you[$_SESSION['unique_name_here']] = $_SESSION[$another_unique]

and than creating hidden input name with but assigning value to hidden input name with jquery.

reset($pee_on_you);
$first_key = key($pee_on_you);

This stopped all auot-matic posting, but not russian spammer, as there are few people who does posting for money, and for them, most frequently used title was "SELL CVV cards" something like that, so all title with "CVV" card was moved to moderation before showing them up in forum.

Lots of processing was done. But this really reduced my more than 70% of spam.

One particularly feature I'd still like to implement before I go back to working on v3.0 is forum notifications. I hope to finish up that feature next week so keep an eye out for that.

I am looking to apply real time notifications to my application as well. What is the best way to accomplish that? Would node.js be used? Notifications are new to me and I would like to understand the logic so I can implement in my own app.

Thanks.

I've implemented a solution on a commercial site that sees ~1000 - ~1200 form submissions a day.

What I've done is the following:

• Add a captcha to the form
• Wrap the captcha in a div tag and apply a style of display:none to the div

On submit I check if the captcha has been filled in. If it has, I know it was a bot and I stop processing the form submission. Haven't had any spam since implementation almost 8 months ago.

Just a thought. Perhaps using the new reCAPTCHA and forcing new users to use reCAPTCHA for their first ten posts would weed out most, if not all of the spam?

Will someone please do something about the spam, it's getting out of hand. How does stackoverflow handle it, I don't see spam there?

Implementing a fix atm.

I've just implemented Google's recaptcha library. Hopefully that'll do the trick.

Would it not be worth while asking Jeff Way how he did the Laracasts forum he doesn't seem to receive any spam. Think mainly down to when you post a question you have to specify what language Laravel is built in, so I guess the recaptcha should do the trick, hope you get it sorted Dries :)

okay... since the spam is still coming even with google's new recaptcha library, I guess these are not bots but actual people who have nothing better to do...

is the problem due to the fact that github is allowing creating accounts without verifying the email? if so, why don't you implement authorization login account only after verifying email address? hopefully coming up with new email addresses that can be verified will be little more difficult than creating unlimited github accounts that don't require email verification?

Or maybe it is just that they (robots or persons) are not going through filling out the form to post. There could be a door in the code that allows to put posts directly to the backend... CSFR or XSS?

CSRF is in place. I've just implemented email confirmation. Let's hope that does the trick.

Maybe its real human(poor ppl) action ?

I'm 100% sure that they are real people.

The spam from today was from dormant accounts which signed up before the email confirmation implementation. So I think we're good.

And they are back again :(

• http://laravel.io/forum/12-12-2014-919799138999-online-black-magic-and-vashikaran-uk
• http://laravel.io/forum/12-12-2014-919799138999-black-magic-specialist-in-chandigarh
• http://laravel.io/forum/12-12-2014-919799138999-black-magic-specialist-in-haryana
• http://laravel.io/forum/12-12-2014-919799138999-black-magic-specialist-in-uk
• http://laravel.io/forum/12-12-2014-919799138999-black-magic-specialist-in-patna

another idea that was thrown about was the use of sms activation codes which could work except for the cost of sending the messages and the additional steps in signing up and addition info we need to keep track of

taftse said:

another idea that was thrown about was the use of sms activation codes which could work except for the cost of sending the messages and the additional steps in signing up and addition info we need to keep track of

Well it could be an idea to use something like Authy or google Authenticator to log the user in? maybe that could help?

taftse said:

another idea that was thrown about was the use of sms activation codes which could work except for the cost of sending the messages and the additional steps in signing up and addition info we need to keep track of

I'm not going to go there. That'll be a huge blow to user experience and besides, I'm not gonna pay for it.

I just implemented filtering on the phone numbers and auto-banning. Let's see how that goes.

I assume Login with Github is required?

Maybe accounts need to be on probation, and after a few posts a more SR person can clear them.

Possibly show a flag beside the account as untrusted until they seem legit.

I took my form down because I was getting about 15 spam messages per hour and that many more accounts created.

I've had this issue on client's sites in the past. We discovered they were real people getting paid for their time to do this. Because they were real people and get paid based on results we found the quicker the message is gone the quicker they give up on the site. What ultimately solved the problem however is we stuck our DNS for the domain under cloudflare.com and because they have a lot of clients their system was able to detect patterns from abusers and block them across their entire network. If they happened to be legit they would get a confirmation they had the fill out. The majority of blocks never had them trying to fill out the confirmation. Those that did had some of the funniest things in their request note. My favorite and most common was "Hey, I'm a legit advertiser who wants to post ads on your site, can you please give me access". Either way their load balancing actually took loads of my sites and traffic increased while pretty much eliminating the spam.

Why not just do sms verification when signing up? Should be pretty easy (and cheap) to do with the current solutions out there.

The spam problems have been gone for a couple of months now. I'm just going to leave the current implementations like this.

Spam is back!

It happens and is being taken care of by the moderators when noticed.

Thanks for the update :-).