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.
Summary
Everything you would do for an external-facing application, and then some.
Thought Process
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.
Recommendations
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.
Related
A non-technical, security-paranoid employee at work insists that an effective method of securing a website of ours, is to separate the application in to three parts; a front end, an API, and a backend management area for staff.
Both the API and the management system are on domain names that are just a random set of characters.
The application holds sensitive data, however, all of the applications are on the same server.
The problem I face is that debugging or adding features the application while it is in this state makes work extremely difficult, as it is unclear as to what part of the application does what. (There is no documentation and the previous developer has since left the company.)
He insists that future projects follow the same suite, with their own separate APIs and management areas, which I think will be unnecessary for a relatively simple application.
The second problem is that I know that security through obscurity is not necessarily security, and I don't see the point in using a domain that complicated to host part, or all of a website.
So my questions are this:
1) Is using an API like this going to carry any security benefits? Are there alternative ways that we can ensure the application and it's data is secure so that it does not compromise development speed.
2) Is using an obscure domain necessary to keep an application secure? Again, are there alternative methods that would be just as effective that wouldn't look as odd to future developers?
3) The management system is secured with a username and password. Would having the administration system be just as secure being on website.com/admin rather than randomcharacters.com?
Is using an API like this going to carry any security benefits? Are there alternative ways that we can ensure the application and it's data is secure so that it does not compromise development speed.
An API should be secured by an authentication mechanism such as an OAuth access token (AuthN). Who can do what on that API should then be determined by the claims in the access token (AuthZ). Authentication and Authorization should be thought of in these terms.
'I am this principal, I can prove this because I have a token that you have issued me and you can verify that only you could have issued it. I have a number of pieces of information that you can use to make decisions on what I'm allowed to do'
Is using an obscure domain necessary to keep an application secure? Again, are there alternative methods that would be just as effective that wouldn't look as odd to future developers?
No, using obscure domain names doesn't offer any level of security. They are just letters that are transformed into an IP address by a DNS entry - to use either my-website-address.com or hdsfiuycxzuyecgfr.com, you'd have to communicate that to someone and at that point they are equally secure!
The management system is secured with a username and password. Would having the administration system be just as secure being on website.com/admin rather than randomcharacters.com?
The questions to ask are, who are the users of the different parts of the system and who should have access to what? Is the front end application publicly visible on the internet and can it be used by various clients? Does the management system fall into the same category, or is that more of an internal tool? Identify the use cases for the components and consider whether you will secure them either by application logic, such as OAuth tokens, or infrastructure restrictions (e.g. only computers within a particular IP address range / subnet can access the management tool). It's usually a combination of both application and infrastructure security that provides the best level of protection.
Having the front end application and the management tool hosted as different applications may allow you to apply different security boundaries around them, which could be useful.
However, it's a matter of determining who your threat actors are and designing accordingly.
An obscure domain name just needs to leak once somewhere; as soon as any attacker gets wind of the domain name, it ceases to be obscure and does not provide any benefit whatsoever. If you have a public website which makes API calls to the "obscured" backend, then that domain name is already being well publicised.
No, there's virtually no point in using an obscure name for the sake of security. If your API is insecure and allows unauthorised access, that is your security weak point; not the fact that the domain name might be known.
I've been building a website from scratch, and while I have some background in coding (particularly Python and various flavors of C) I am teaching myself html, php, sql and so on as I go.
I would very much like to be able to add an 'admin view' to my website, so that I can add and modify content more easily. I've spent a good amount of time searching for a way to do this securely, hidden behind a password, but it seems as though this is extremely difficult, or even impossible, to do.
With my incomplete understanding of how internet security works, the only way to do this is to have the login php file include a php file from outside the public_html folder which contains the actual password entry, which itself must contain a randomly generated way to modify the password-entering instructions to prevent anyone who intercepts the password I enter from being able to use it later, and which then decrypts the entered password and sends it to other php files outside the public_html folder that contain the infrastructure for the admin view.
Given that I've used several websites that require entering a username/password that use a much less convoluted scheme for securing them, I'm assuming a better system exists. But the main problem of all information from the client being visible to any sufficiently determined attacker seems to render this impossible. What am I missing?
You are right so far, that it is impossible to protect the transportation of the password between client and server, by your own application. If an attacker can do a ManInTheMiddle attack, (s)he could do exactly the same as your client does, or could just strip away a JavaScript which tries to encrypt or hash the user password before sending it.
So the only thing you can do is using an encrypted SSL/HTTPS connection. Most providers offer to install a SSL certificate, but often this is a bit expensive, and sometimes only available in the professional bundle. There are also hosters which offer it for free though.
The encryption of an SSL connection works, because there is already a shared secret. Browsers will install a list of root certificates, and those certificates can be used to set up an encrypted connection.
This is the most important bit: Use HTTPS.
You should use a hash on the password in javascript, before it is send to the server, and only use the hashed value. That way the actual password is not easy to get at. Remember to salt the hash. The point of hashing on the client side is that that it obscures the original password. (Many users use the same password on multiple sites. this way the original password is very hard to get at)
Here is a good implementation of SHA-256: http://www.movable-type.co.uk/scripts/sha256.html
Hash it again at the server side, before you store it, in case someone gain access to your data. Don't forget the salt.
Remember that security is only a matter of degrees :c)
Where you store the hash is less important. Just make sure it's unavailable to the outside.
Use .httpaccess files to restrict access. here are some examples: http://blog.dreamhosters.com/kbase/index.cgi?area=3083
I'm developing a web site which calls .PHP scripts to inject data into a MySQL database.
Because there is no security on these .PHP scripts, anyone in the world could run them over the web if they knew the proper parameter names and inject data into our database.
I know very little about security so I'm looking for a solution to secure these "web services".
I've read that using SSL may be the way to go but I'm not sure.
If anyone could make a recommendation and point me to a tutorial or website on how to implement this I would be greatly appreciative.
We are using Apache web server by the way if that matters.
SSL will not solve the problem by itself. If someone can hit http://yoursite.com/service.php, they can also hit https://yoursite.com/service.php. SSL simple ensures that the actual data going over the wire is encrypted. But an encrypted injection request will have the same effect as a standard unencrypted one - you'll still have data injected into the database.
What you need is a password system of some sort. A bare bones minimal system would require a secret word to be sent along with each request, and any request without that word gets rejected/ignored. however, then you have to keep this secret word secret, and nothing on the web stays secret for very long.
Next up is assigning a specific key to each authorized user of your service. Nothing would prevent the users from sharing their key with others, but then you've got a per-user key that you can track down and beat up the person who DID share their key.
Past that, you can use HTTP level authentication, coupled with per-user access keys, which should prevent casual poking at the API. Without the http-level password, the API script is not even invoked, and even when it is, the proper API key must be present as well.
I roamed the site for this question using the search engine, and I don't think it's out there. If it is, apologies in advance and feel free to point me to it.
Here is my scenario:
I am setting up a web application, Moodle if anyone is familiar with it, with Apache, MySQL, and php on Windows. Moodle supports enabling SSL for login, but then reverts to regular http after login is established. This is running on an internal network with no connection to the outside world, so no Internet access through this network. All users who use the network have logins, however there are some generic guest type logins with certain restricted privilages. Currently the MySQL database is not encrypted.
My question is this:
If my users do an SSL login, and the system then reverts back to http for the remainder of their session, how vulnerable is the data that is transferred back and forth between the browser interface and the database?
I would perhaps prefer to have all the data encrypted, but I am not sure how bad the performance hit would be to do that, so any suggestions concerning that would be appreciated too. Although I will be extending the functionality in Moodle, I don't necessarily want to have to change it to encrypt everything if already does.
I am new to the world of IT security, and my DBA skills are rusty, so if you give me an answer, type slowly so I can understand! ;)
Thanks in advance!
Carvell
A few things.
The fact that the data in the DB server is not encrypted in no way is a factor in the communication between the User and the Web Server. It is a concern obviously for communications between the web server and the database server.
Your risk point between user and web server is in that packets could be sniffed if a person was able to interject in the middle of the communication chain. However, this risk is mitigated by the fact that your on an internal network.
Therefore, unless you are VERY concerned about the other people in your organization, you are more than likely ok. However, if it is really sensitive data, you might do ALL communications via SSL to ensure that it is transmitted securely. IF you are this concerned, then I would also look at the security of the DB and the communications from DB to webserver.
My concern would be how your authenticated sessions are propagated.
Generally a session works by setting a cookie or appending a session id to any URLs presented by the web site. Once a log-in has been established, often the credentials aren't needed any more, as a session is then linked to the user and deemed to be authenticated, and the existence of the session itself is proof of a successful authentication.
However, as previous posters have mentioned, local network traffic can be available for sniffing. If someone sniffed a session id, they could recreate the cookie or urls using the session id, and simply access the site as that session user, even changing the user's password if that option was available.
I would say that your decision here rests on the security of your sessions. If you have some mitigating factors in place to make sessions difficult to replicate even if a session id is compromised (ie. comparison to ip addresses, etc), or your user accounts are relatively secure from a compromised session (eg. require current password to change account settings), then perhaps SSL after login isn't required. However, if you have doubts and can afford the performance hit, then having SSL throughout the site will guarantee that your sessions can't be compromised (as far as you can guarantee SSL, anyway).
With no internet access to this network, the only thing that could potentially happen is someone else (who is already on the internal network) snooping on another user's HTTP traffic. If someone were to actually do that, and you aren't using SSL, they could read all the data that your website is sending/receiving from that user. But is that actually a concern?
Since you are on an internal network turning on SSL for the whole site should not be that bad performance wise, although it is probably unneccesary.
At the very least, you should encrypt the data in your database.
All sensitive data should be encrypted when transferred over an insecure wire. If you just transfer login details over SSL, all your data is still vulnerable to eavesdropping.
Since the data's not encrypted, anybody with sufficient network access (i.e. physical access) can read the data passing back and forth from server to browser and back. As long as everyone who has physical access to the network also has authorization to read the data, you're probably alright. If any of the information is sensitive, and should be restricted to being viewed by a subset of people who have physical access to the network, then you need to encrypt it.
Anyone on your network would be able to see everyone else's traffic with a network packet sniffer like WireShark. The connection between your web server and MySQL is also in cleartext. MySQL may not actually send passwords in cleartext; it may be a hash, for instance.
If you are really trying to be paranoid, you may not need to run your app over HTTPS. There are other lower-level possibilities like IPSec. Since this is an internal network, you can probably get away with implementing this on all workstations.
Not much to add to the above correct responses. But, one think you can do is use a Threat Modeling tool for your application. That will inform you on the types of threats you are exposing your data to by not using transport level encryption (TLS/SSL). Once you understand the threats, you can decide on an appropriate risk mitigation plan.
I'm in the final stages of implementing a CodeIgniter site which requires a really simple login system. One user, and one password to protect the admin area. I think I will be using one of the many CodeIgniter authentication libraries, which should allow me to ensure that people can't read from the database without being logged in as admin (hopefully).
Are there any glaring holes in a setup like this?
Should I take further measures beyond using a library like this to
ensure the security of the data in the MySQL database?
It will be hosted on a shared server; meaning little, or no server config will be possible.
There is a long discussion about the authentication systems available here: How should I choose an authentication library for CodeIgniter?
The latest version of Redux seems to be the favorite.
http://code.google.com/p/reduxauth/
I have used in the past (with excellent results) DX Auth 1.0.6.
You can find it at http://codeigniter.com/forums/viewthread/98465/
I would create simple form-based authentication and use a strong password.
HTTP authentication has too many problems IMHO:
Easier to brute force hack.
Anyone who sniffs the request can determine the username and password being used, but they don't even need to; they can just use an identical HTTP themselves.
Once that dialog pops up, it's difficult to dismiss, which can be irritating.
Many browsers will ask twice for a password before letting you in.
It's difficult to log out or change users, you usually have to quit the browser.
Easy to forget that you've let the browser save your credentials, which is another potential security risk.
If it is on an apache server, then I would consider just setting up an htpasswd protected directory. Read more about it here.