I am guessing the hosting provider gets access to the information the client also gets, but that's just a guess without any evidence. It would just make sense in the absence of regulation.
This should be inserted by the customer instead of filtering traffic, but not necessarily. It's very user friendly to only have a button to turn something on or off.
At their scale, trying to automate it hardly seems surprising.
Not at any professional hosting service. It's not hard to secure the environment so that it'll take a classier attack than guessing somebody's WP login to get access to any other sites on the host.
The actual problem for hosting services is that compromised sites can be used to annoy visitors or other hosting services.
edit: okay, I don't care about the points, but I'm getting really curious why people disagree with this.
In any case, yes, I agree.
What is more plausible is malicious server-side code eating up server resources, and that load impacting the websites of other customers, but that has its own solutions which are different from automated detection of malicious JavaScript code.
1. Data theft. So, ripping off a database or intercepting credentials while people log in.
2. Embed a link into page output which will try to download something from somewhere somehow. It might be phishing, or (usually) it's some kind of JS trying to infect the user with malware. Lazy attacks work by just popping up a convincing-enough warning message with a link that lets the user download the malware themselves, and it's effective enough.
3. Credit card theft. Using a third party service with iframes makes this harder, but not impossible.
4. Dropping some kind of web-based shell, like C99.
#1 doesn't get anybody to care. If that's all that ever happened, I'm pretty sure shared hosting providers would still be saying, "sucks to be you." #3 causes headaches for the site owner and makes them care, but still not the hosting provider.
#2 got the hosting providers' attention once Google launched Safe Browsing. Suddenly this put some of the responsibility for maintaining a safe network back onto the hosting providers. Their first solution was to just shut down sites discovered to have malicious code, but that really irritated the customers. So gradually hosting providers started trying to be a little more helpful.
#4 is a big headache for hosting providers, because those things don't get picked up automatically by Google, and the shells can be used to irritate other hosting providers, who will definitely start lodging complaints with whoever's upstream of the hosting provider.
Not on this list is, "try to infect other sites on the same server", because shared hosting environments have had easy access to a variety of tools for a long time now that prevents that. In a LAMP environment, that used to include SuexecUserGroup; more modern LAMP environments now use php-fpm and have PHP processes running from distinct unprivileged user accounts. There's also the usual php.ini values, like open_basedir, which limit access to the filesystem or to other PHP functions (allow_url_fopen).
I won't say it's impossible for an infected site to attack another site on the same server in a shared hosting context, but you'll need a get-out-of-jail card and those are harder to come by.
No professional shared host would allow one site to access or modify another site on the same server.
Hell, Wordpress recommends against it (and still doesn't do a great job explaining): https://codex.wordpress.org/Changing_File_Permissions#The_da... -- probably because people keep suggesting it. A search for "chmod 777" brings up plenty of examples.
Even chroot will mitigate this, but e.g. reseller types quite often don't have that level of competence.
I was under the (false) assumption that every user’s website was in their own little VM, not they were sharing a web server.
Running a full VM, especially on the tools back then, took a ton of resources. Even server class machines only had 4 or 8GB of RAM typically.
By the time I got to the point where I would think about doing something on my own, VPS hosting was so cheap, I wouldn’t have thought about anything besides a VPS like Linode.
https://blog.linode.com/2003/11/04/new-linode-96-plan/
96M RAM
3GB Disk Space
38GB xfer
$29.95
Funny story (but not the ah-ah funny kind): such a service (hosting different customers on the same Windows machine) was still running in my previous company as of 4-5 years ago. They had long moved from physical hosts to VM, but were stuck with the legacy CMS/control panel which was more or less unpatchable (as in, the software editor didn’t exist anymore). About once a week, one of the host VMs would be taken over by hackers using one exploit or another. In that case they would kill the VM, boot a fresh one from a clean image, and start serving the customer data again after making sure it was clean. The service was not sold anymore but they had long-running customer contracts. It wasn’t making enough money to justify rebuilding it with modern software, but it was making enough that simply killing it wasn’t an option.
It wasn’t until I started architecting and developing in cloud environments that the true cost of Windows became apparent - when the cost of every project I do can more or less be directly tied to me.
I still development on Windows but I found an appreciation for deploying to Linux.
Unfortunately, shared hosting comes with all the risks described: if just one site on the server gets infected, everything else co-hosted on the box feels the effects, especially when the infection is something resource intensive like a cryptominer, or sends out spam emails en masse and gets the physical box on a blacklist. From an infrastructure standpoint we can only do so much; keeping the OS patched and up to date helps to curb the really nasty infections, but the reseller plays whack-a-mole with their customers, detecting infections and shutting domains down as needed.
It's a bit of a mess really. At the same time though, the economies of scale really seem to favor shared hosting from a pure cost perspective, especially for very small businesses that can't otherwise afford a technical team to manage a VPS. So, I think that market is always going to be there.
I’m way out of my area of expertise here. But from a management perspective, when it comes to managing a lot of VPS’s for something like WordPress, is there a simple service where the underlying OS and plug ins stay patched by the provider? I guess something like Elastic Beanstalk but simpler.
There's a thing called Cloudlinux, which is an additional licensed feature that provides resource fencing, but its a lot less capable than advertised ime.
Moreover, many end users rush to chmod 777 their installation because there's a lot of guides out there telling them to do so. There are also highly rated Wordpress plugins that do this silently because developers read those guides.
Also I don't have to update operating systems or do backups, etc.
Unless you website is serverless, good old shared hosting isn't bad. You have less control, but also less responsibility :)
It would take us time to assess everything and do up contracts for bring-up with these sites. Everything from old revslider and timthumb to more exotic infections. Once you got a file injection or reverse shell on a host, it would spread fast to everything on the server. Only way reliably back was catching when it came in and rolling it back to before then upgrading the vulnerable components.
Offering it as an opt-in service, yes. Doing it to websites that have not agreed to to it, no.
Which is still how it should be done.