Hacker News Reader

Comment by DamnInteresting | Hacker News Reader

Around 16 years ago, Wordpress security was just not up to snuff yet, and my popular Wordpress-based site kept getting hacked by pharmaceutical spammers and the like. After several such incidents, I wrote a "wrapper" that loaded before Wordpress to scrutinize incoming requests before a lick of Wordpress code was executed. It had blacklists, whitelists, automatic temporary IP blocking, and that sort of thing. There was no reason for visitors to upload files, so any non-admin POST request with a file upload was automatically smacked down.

It wasn't pretty, but the hackers never got through again, and that clunky thing is still in service today. I coded it to quarantine all illicit file uploads, and as a consequence I have many thousands of script kiddies' PHP dashboards from over the years.

View on HN

Haha you invented WAF! https://www.cloudflare.com/learning/ddos/glossary/web-applic...

That reminds me of my terrible spam prevention hack. We kept getting a bunch of spammers signing up for our newsletters, so I made the form require a JavaScript based hidden input to submit. That worked for a while, but then new spammers started executing the JS and getting through. So I added new JS that just waits 15 seconds before putting the right hidden values in the form, and that’s done the trick (for now).

So CSRF?

Plain CSRF wouldn't help because they're scraping the site and executing the JS. It has to be time delayed CSRF so they give up and submit before it's loaded.

The real solution is to use a CAPTCHA, but they're so user hostile, that's the last resort.

Oh I got that, I was referring to the original solution.

And I can kind of agree with the CAPTCHA being the final solution, a question though, you can't implement the Cloudflare style "CAPTCHA" which is heuristics based and not "please click the bus" type?

Hey just a thought:

16 years is a long time, many of those shell dashboard sources are probably lost.

It'd be interesting to upload them somewhere as a "historical museum" of sorts.

When you say it loaded before Wordpress loaded, what exactly does that mean? Was it a proxy that handled incoming requests and passed them off to Wordpress?

I imagine just including the code in index.php before the bootstrapping process actually loads up Wordpress for real. That way you could just halt the script early after noticing a funny request.

I wrote my own front controller, and used htaccess rules to direct all requests there instead of to Wordpress. If the front controller deems the request safe, it just hands off the request to Wordpress. Otherwise it quarantines uploaded files (if any), and responds with an error. Lemon squeezy.

Nice. I just had nginx requiring basic auth for anything hazardous.

Probably broke a few features I’m not using in the process. :)

Reply on news.ycombinator.com