What is the best way to secure an intranet website developed using
PHP from outside attacks?
That’s a stunningly thought-provoking question, and I’m surprised that you haven’t received better answers.
Everything you would do for an external-facing application, and then some.
If I’m understanding you correctly, then you are asking a question which very few developers are asking themselves. Most companies have poor defence in depth, and once an attacker is in, he’s in. Clearly you want to take it up a level.
So, what kind of attack are we thinking about?
If I’m the attacker and I’m attacking your intranet application, then I must have got access to your network somehow. This may not be as difficult as it sounds – I might try spearphishing (targetting email to individuals in your organisation, containing either malware attachements or links to sites which install malware) to get a trojan installed on an internal machine.
Once I’ve done this (and got control of an internal PC), I’ll try all the same attacks I would try against any internet application.
However, that’s not the end of the story. I’ve got more options: if I’ve got one of your user’s PCs, then I might well be able to use a keylogger to gather usernames and passwords, as well as watching all your email for names and phone numbers.
Armed with these, I may be able to log into your application directly. I may even learn an admin username/password. Even if I don’t, a list of names and phone numbers along with a feel for company lingo gives me a decent shot at socially engineering my way into wider access within your company.
- First and foremost, before all technical solutions: TRAIN YOUR USERS IN SECURITY
The common answers to securing a web app:
- Use multi-factor authentication
- e.g. username/password and some kind of pseudo-random number gadget.
- Sanitise all your input.
- to protect against cross-site scripting and SQL injection.
- Use SSL (otherwise known as HTTPS).
- this is a pain to set up (EDIT: actually that’s improving), but it makes for much better security.
- Adhere to the principals of “Segregation of Duties” and “Least Priviledge”
- In other words, by ensuring that all users have only the permissions they need to do their jobs (and nobody else’s jobs) you make sure they have the absolute minimum ability to do damage.
If it is on an internal network, why is it even possible to get to the app from the outside? Firewall rules should be in place at the very least.
The best way? Disable direct external access!
If employees need to use it (like an extranet-style site), you should make them VPN in. Through VPN you have a lot more authentication options and most of them are a great deal more secure than leaving your intranet server accessible from the internet.
Another option, and this only works if the data is public-safe, is scheduling your intranet server to push the data to another server that is externally accessible. I say push because you really don’t want this server to have access to your network. Let your network server do the work.
The best way to secure it? Don’t connect it to a network. Make your users physically enter a guarded room with a single console, running Mosaic.
Oh, you want it to be easy to use?
- Always verify every single input that can come from an untrusted source.
- Don’t trust any data sources.
- When storing passwords, ALWAYS store an encrypted hash of the password.
- When storing passwords, NEVER store passwords directly.
- Never collect or store any data that you don’t actually need.
- Never allow yourself to be tempted into adding additional bells & whistles.
- Read everything that Bruce Schneier has written on security and encryption.
If you forget these simple rules, you could find your application starring on the front pages of newspapers everywhere, just like Yahoo mail.
I would echo @Oli and favour the VPN method if possible. However, if for any reason you need more arbitrary access than this, you should use SSL to secure any authentication. And in addition to password authentication / IP address authentication it would be well worth looking at using SSL with client side certificates.
You could only allow access from internal IPs from the php app itself. Also dont ignore the usual security and best practices. Input validation and output encoding(whitelisting only), user accounts with hashed passwords etc.