If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

It was embarassing.. but I quickly found my mistake - an unescaped GET value if you must know.
I was about to apologise to the site owner, when she said she'd just had her laptop stolen and figured the perps had logged on from it.
So I figured I'd keep quiet..

I haven't personally, but I have had to clean up a lot of websites that were hacked. None of them was due to sloppy coding (except for vulnerabilities in WordPress) but instead were attributed to social engineering/compromised credentials, etc. Things like that. The worst one I think I have talked about on here in the past was due to a vulnerability in a specific version of Apache.

I've never had a compromised credential break until very recently, and no code injection in any of my code; however, I'm responsible for "legacy" code and the folks upstairs aren't always are security-conscious as they should be in regard to policy; now that I've experienced both, all I can really say is *neither* is fun, both are potentially business-damaging and I'm sure glad I had a nice vacation, 'cause it's definitely *over* now ;-)

/!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade!/!!!\ ereg() is deprecated --- don't use it!

I had a phpBB site hacked by the santy virus some years ago. I ended up working on it over Christmas 'vacation' and writing a script to detect its signature to help other folks who were infected. More seriously, I found a compromised sshd binary on a server a couple of years ago. This was a pain to fix but as things turned out, we ended up moving to a much better arrangement in the Amazon cloud -- where if your server is compromised you can throw it away and fire up a brand new one without the hacks installed -- provided, of course, that you keep a nice, clean image of your healthy server around to launch it from.

I've also been mightily impressed by a few tricks that lend me a lot of confidence when I have the leeway to use them on a project:
* public key authentication for server access only (no passwords). This usually requires some re-educating of other people who need to access the server.
* SSH File Transfer Protocol only. FTP is not secure.
* iptables so you can limit access via SSH to just a few trusted subnets. This can be tricky as it is easy to lock yourself out.
* fail2ban which continually sniffs your system log and your apache log and bans IP addresses that are trying to login over and over or who are asking for non-existent scripts trying to hack your PHP application
* samhain which continually monitors the integrity of your file system and sends you a notification when one of your source files changes.

When writing PHP code, I would not pretend to write fool-proof code, but I have a healthy natural paranoia about security and I tend to use a lot of validation when reading from POST-GET-COOKIE or from the file system. I do a lot of validating and a lot of exception throwing and a lot of file system path validation.

I enact all of those except samhain whenever I can (thanks much for that tip ... I will investigate.

samhain runs as a daemon and continually watches over certain directories and is highly configurable into types of watching. Some files can grow (e.g., log files) other files should not change (like sshd executable, for instance. You can configure it to write a write-only log to a remote database so that even a local compromise cannot conceal activity or alter your log file. You can configure it to send an email when something happens.

Originally Posted by dalecosp

I was under the mistaken impression on one of our boxen that FTPD was tcp-wrapped. It wasn't :-(

It's now turned off ... SCP/SFTP don't need it (only SSH).

You can configure FireFTP (firefox plugin) to use certs for SFTP access. There are probably other sftp clients, but I don't know them. I do most of my work via SSH or via SVN/GIT. Version control is also a good way to maintain the integrity of your source. If your server gets compromised, you might be able to completely wipe your PHP source and re-deploy it from your repository. Beats the hell out of searching all your source code for exploits.

Originally Posted by dalecosp

I do wrap and/or firewall off all access to most of our boxen from the 'Net at large.

I couldn't claim to be any sort of firewall expert, but iptables is awesome (and required by fail2ban). It's also one step better than a firewall inasmuch as it is on the machine handling the traffice and thereby protects against traffic inside your firewall too. The downside is that you can easily lock your own bad self out of the server if you aren't careful.

Originally Posted by dalecosp

I use public-key myself; I need to do the re-education of the rest of the shop, I guess. As no one else here is a programmer type, I'm thinking it may be an uphill battle.

Depending on what FTP client they may have gotten accustomed to, this can be easy or hard. Generating the keys can be just a matter of a couple of terminal commands on a max or *nix or just downloading putty and putty gen for windows. I find that it really really helps to do a step-by-step recording of the steps using camtasia or some other screen capture program.

I'll also reiterate that Amazon EC2 is pretty darn awesome if your system has been compromised. You can make a freeze-dried image of your production server when you feel like it's running well. If it gets compromised, you can just throw it away and fire up a new one from the image.