A few weeks ago, a typo in a file on a client side resulted in every unique URL request being logged to the database.
This included broken post URLs, every paginated tag archive page, search results listings, and even 404 errors. It was a colossal mess, but thanks to the way page caching had been set up, it didn’t impact the performance of the site’s front end.
It was an educational opportunity, though. In addition to our regular page view counts, we now had a discrete log of every URL visitors tried to use on the site. Some were innocent mistakes – possibly due to line breaks in emails or text documents breaking links. Others were due to code errors where characters were double escaped[ref]Or triple, or quadruple escaped. A few URLs even appeared to escape a character up to 15 times. It was pretty funny.[/ref]
Some logged URLs revealed active attempts to exploit vulnerabilities in the site.
Someone, somewhere wants to kill your site
We knew the site had come under attack in the past. We knew it was attacked daily based on traffic logs on the server.[ref]Our CDN alone showed several failed DOS attempts against large media assets.[/ref] We didn’t really understand the scale at which the site was being targeted, though.
To be clear, the site runs on WordPress and is completely up to date (including all plugins and libraries bundled with the theme). At the moment, there are no known exploits for the combination of software running on the server.
But that doesn’t stop hackers from trying.
I saw attempts to leverage the old Tim Thumb vulnerability – with no Tim Thumb on the server (vulnerable or otherwise), I found this highly amusing. There were attempts to access the admin account of some ASPX app allegedly installed on the server – we’re running Linux, and there’s not a single .aspx file on the server to begin with.
Little Bobby Tables even made a cameo.
The lesson here: there is always someone who will try something to break in to your site.
Questionable search history.
I write about WordPress a lot, and I often find myself defending it against its various detractors. Yes it’s secure. Yes it’s scalable. Yes it can run an enterprise-level infrastructure. Yes it can do more than host cat pictures.
Working with WordPress and security has led me to one of my other passions – digital security and safety. I’m a huge proponent of data encryption, and I love to write articles explaining both the how and the why behind various cryptographic systems. Lately, I’ve written a few articles specific to hashing – which, to be clear, is a one way algorithm. Hashed data cannot be restored to its unhashed state.
So when I found out that my top referrer so far this week is the search result page for “decrypt wordpress password hash online,” I had to ask myself … what’s going on?
It’s no surprise there are actually sites wholly dedicated to helping people[ref]I’m being explicitly vague here. “People” could be hackers bent on wreaking havoc online. It could also be honest business owners who forgot the password to their site. Either way, “people” are trying to bypass your security.[/ref] crack various hashing algorithms. Luckily, most of the automated tools can only handle unsalted phrases – so if you haven’t generated random security salts for your WordPress site, do so now.
My overall point here is not that WordPress is unsafe. Quite the contrary, WordPress is very safe and secure.
Today.
My point is that, also today, there are countless individuals trying to compromise that security. Tomorrow could yield a completely different story. Stay on top of the game, keep your site up-to-date (and backed up regularly), and help to thwart this constant threat before it becomes an active concern.
