Recently I found one of my web servers hacked with malicious code injected to websites hosted there. It wasn't exactly my fault, as I shared the server with other people and someone put some unsafe script/website on the server. Luckily to me there was no damage or data loss. But it got me thinking. I found out about the breach totally by accident. I simply tried to pull a some updates to another script from my Git repository and it returned an error about uncommited modified files in my working copy.

In most cases there is no access to shell on web servers (shared hosting) and you update websites by uploading them via FTP and simply overwrite files. How to detect Code Injection is such situation?

And what about the situation where you have access to shell on your web server. Are there any other (and better) ways/tools to detect Code Injection?

2 Answers 2


Summary. The best defense against code injection is to prevent it in the first place. Generally speaking, once malicious code has gotten onto your system, there is no reliable way to detect it. I know that you were asking about detection, but I recommend that you focus on prevention, not detection.

Prevention. So, how do you prevent code injection? Generally speaking, through access control, good security hygiene, and secure software development processes.

  • If you have a web server, don't share it with other people. It is easy enough to use virtualization to provide isolation between multiple tenants. For instance, if you buy shared hosting from a commercial shared hosting service, they will use some form of virtualization to isolate their customers from each other. (This has nothing to do with FTP access vs shell access. As long as the customers are isolated from each other, it doesn't matter whether the hosting provider provides shell access or FTP access. They just need to make sure that other customers get access only to their virtual containers, and not to yours.) Similarly, don't share your passwords or cryptographic keys with others.

  • Practice good system administration practices, to prevent compromises of your server. Keep your software fully updated and patched. Use firewalls to limit access to only those services you want to expose. Use SSH with public-key authentication for remote login. If you need to use passwords, make sure you choose long and strong passwords, never share them, and only send them over encrypted channels.

  • Practice good software development processes. Avoid introducing security vulnerabilities into software you write. Entire books have been written about how to go about doing that, so I won't try to explain in detail here; I'll simply flag it as something that's important, to ensure the software is free of security vulnerabilities.


In part, I agree with D.W., prevention is greater than detection but only when it works. Once your machine is compromised, you'll kick yourself for not having better (or any!) detection mechanisms in place. In general, I try to split my focus on both, and at some points detection may get a little more attention.

Someone with your risk profile (small business owner with basic shared hosting provider etc), usually doesn't have the ability to spend the time, money and effort or make the required changes to fully invest in a security solution. I would recommend a 3 prong approach consisting of prevention, detection, and recovery.

Note, this is not an exhaustive discussion on each of these 'prongs', but rather are here to get your thinking juices going. I would love to hear what you decide to implement, along with anyone else's!


I won't spend to much time on prevention, there is just to much to cover. D.W. pointed out some starting points in his post, and there are a ton of resources online regarding secure coding. I suggest you start with the OWASP and Mozilla guides:






Some modern malware (and intruders) have the ability to root themselves so deeply into the innards of the victim OS that verifiable removal approches impossible. However, I would not suggest putting all your eggs in one basket e.g., only focusing on prevention. Focusing on only prevention leaves a lot of room post-compromise that could have been gathering artifacts and evidence.

Shared hosting environments are not always the best for their customizability in terms of what needs to happen for a security initiative, so it is very dependent on the provider. (see How to keep a shared web hosting server secure?)

Your incident was mostly likely part of a mass compromise, e.g., SQL injection of a site on your shared host that lead to OS compromise. That script then searches for *.php's to inject itself into. Once infected, the worm/attacker moves onto the next host(s). While this may not be exactly what happened, it's a common case, and demonstarts a common attack pattern that is hardly a sophisticated attack or an impossible task to detect and clean up.

Depending on what are able to deploy locally, your best bet maybe use a 3rd party service that looks for signs of infections, e.g.,



Another option is to use a simple script to compare checksums of all your files and send you an email when it's different. You could then use git hooks to update your script config with the current 'good' checksums. I've had good luck with simple scripts like this for other things as well, e.g., SSL cert checking, verification of headers, etc.


Now that you have a detection mechanism in place, what happens when you get that dreaded email at 3am? Having a clear process in place will greatly reduce downtime and grey hairs.

As you mentioned git in your question, I will assume you are a current user. There are a few good posts on how to use Git to manage a website. I would recommend using a process similar to one detailed in:




Remember, that is only your code, not necessarily all your data, e.g., databases and uploaded content.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .