Compromised WordPress Blogs Poison Google Image Searches
Orome1 writes "Google Image Search has for some time been littered with images that lure users to compromised sites that serve as doorway pages to other malicious sites. Part of the problem is that these compromised sites often use the WordPress publishing platform, which is infamous for the great number of security bugs that make it such a preferred target. This fact has been proven once again by security researcher Denis Sinegubko, who has pinpointed 4,358 WordPress blogs hijacked by unknown attackers and pumped full of popular search keywords and images, which redirect users to sites that try to scare them into buying a fake AV solution."
Or, you know... don't use Wordpress...
Is there a free CMS which offers the same balance of simplicity, usability and extensibility, and that can run on most shared hosts? I'm genuinely curious.
You *can* code reasonably secure web apps in PHP, however. It just takes a certain amount of diligence to making sure that user input never gets through to your backend without going through at least one layer of regex filtering to strip out or outright ignore crafted SQL (and other query) exploits, and paying careful attention to which route information is taking to get into your code. (There are separate pseudo-arrays for GET, POST, COOKIE, SESSION, and SERVER. I use those to prevent malicious injection through GET into parameters I'm expecting to come in through POST, etc, as well as to handle flow control through what may be a remote throw/catch into a subpage that needs some initialization parameters of its own, for example. There's also a pseudo-array that gathers all of these into one big list so it's not possible to tell which one came in where. I don't use that one at all.)
..
I'm not as comfortable with JavaScript because I've had to deal with too many broken JS engine implementations in too many browsers.
Not saying either of them doesn't utterly nauseate me, but it's possible to do things well in both, and when you're stuck with whatever your hosting provider decided to implement (which you pretty much are, if you're not running your own colo server and dealing with a whole *different* range of security vulnerabilities), you know they're there and can be made to work
"Basically every web app implemented using any server side language programmed by someone who doesn't know what they're doing will be full of security holes." Fixed that for you.
pumped full of popular search keywords and images, which redirect users to sites that try to scare them into buying a fake AV solution
It takes them to McAfee's website?
The only thing necessary for evil to triumph is for it to be pitted against a slightly greater evil
In that case, you have to write your own http server, too.
And text editor.
And compiler.
While sanitising inputs is laudable, PHP programmers should be using bind variables.
PHP, MySQL and PostGreSQL all support them, now.
Prevents most SQL injection, improves performance, results in cleaner and more readable queries.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
Not always. This guy is talking specifically about self-hosted WordPress sites, as opposed to the ones on WordPress.com. The vulnerabilities exist mainly in sites that don't keep up with the latest bugfixes, or potentially, sites that are hosted by shared hosting providers who leave stupid PHP options enabled, leading to the vulnerability. There are various reasons why any site might be compromised. There are plenty of sites running technologies other than PHP that have been compromised. The bottom line is that it does actually take a little bit of diligence to operate your own Web site. Even if you aren't a PHP programmer, you should understand the correct operation and maintenance procedures for your PHP-based software, or else you risk being compromised.
Breakfast served all day!
Fail to see how that helps, although it would be more fun. :)
Wordpress lets you slap together a site that looks nice and is functional, and do it very quickly and without (or with little) graphic design skill, and is open source. If you write the site from scratch, it is substantially harder to have a site that looks nice and is functional.
-- IANAL, this isn't legal advice, and definitely isn't legal advice for you. Also, Squee!
PHP does everything in its power to make safe and secure software development damn near impossible. Add in some JavaScript, and an already bad situation gets much worse. It, too, is a horrible language for writing safe, secure software.
It seems to me you've just made the case for not writing your own Web software at all, but instead choosing a well-established, well-maintained open source project -- such as WordPress. TFA is surprisingly short on what versions of WordPress are vulnerable to the exploit (and there are many versions). I'm willing to bet, however, that people running the most up-to-date version are not vulnerable.
I don't think JavaScript is as shitty as you claim, but I'm no fan of PHP. Still, A.) It is very easy to find cheap shared hosting that supports PHP; less so for any other language; and B.) Name me a language that I could write a CMS in right now that makes it easy for me to write safe and secure database-backed Web applications. (The answer is there is none; no matter what my personal language preferences, my best bet is to use someone else's mature, open source codebase -- such as WordPress).
Breakfast served all day!
PHP does everything in its power to make safe and secure software development damn near impossible.
There's a saying about whether good craftsmen blame their tools...
It's not PHP's fault that the designers of WordPress are about as competent as I was a year out of college. Everything is global, global functions, global variables, all over the place. If it was possible to use a global variable or a global function instead of something sane like a class, then by god they're going global. WordPress altogether just reeks of amateurish practices. Hell, in order to embed the thing on an existing page you include a file called "wp_blog_header" or something. But, it's not a header, and may not even result in a "header" being printed, it's basically all of WordPress. There's another include file called "wp_settings", which is great except it doesn't contain a single setting, it contains only function definitions. There are exit and die statements all over the include files, so if you pull up the page and it's blank, good luck finding out which condition in which include file got triggered to make the thing bail.
The global nature of everything makes it nearly impossible to embed in various template engines, and I hope your own applications aren't defining global functions with the same generic names that WordPress uses. One of PHP's more insecure options, register_globals, is also implemented in WordPress. No idea why they think they need that option, but if it's disabled in PHP then they go through and define all of those global variables anyway. The entire application looks like it was conceived by a fresh college graduate who recruited his younger brothers to actually build it. It's like the MySpace of CMS applications, the only reason it got big was because it filled a need when the need was there. Not because it's good, but because it was available. If there was ever an application in need of a ground-up, compatibility-smashing re-write, this is it.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
Basically every web app implemented using PHP and JS will be full of security holes.
Wikipedia is implemented in PHP and JavaScript. If it's been compromised, I haven't heard about it. So I must have misunderstood what you meant by "basically".
As I understand it, the +1 button on Slashdot has a very complicated unlock procedure. First, you have to create an account and log in. Second, you have to post 25 excellent comments early in a discussion that get noticed while you are logged in. Third, you have to wait a year or two for your account to be old enough. Fourth, you have to read Slashdot on this account just enough (not too much, not too little). Then you're supposed to get the +1 button. Unfortunately, I can't help you further because I haven't figured out how to qualify under the fourth step.
IMO a good language makes the safe tools painless and the unsafe ones painful. A poor language makes the safe tools painful and the unsafe ones painless.
A web orientated language designed for security for example could have multiple string types and make it easier to apply appropriate conversion processing than to convert between them without doing the processing.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
A Singleton is Global State in Sheep’s Clothing. Static methods are also as problematic as globals. It's just that some people don't see the problems with them when they're not labeled "globals".
John