We have a web application (Apache/PHP) that currently uses username/password authentication and is currently accessible from anywhere. It has server-side SSL enabled.
Our client program is a version of FireFox that we have modified and rebranded. This modified firefox client is meant only to connect to our web application server. Users must use this client program to connect to the web service.
In addition to user authentication, we would like to block access at the server level to anyone who is not using our client program*. So if a user types in a URI using a regular browser, they would be denied outright.
To accomplish this, the client program needs to identify itself to the server so that the server knows the our client program is being used and not a web browser or bot.
*The real goal is to make sure that they are authorized employees of our company before being able to attempt a login, embedding this "proof of employment" into the client program just seems to be the easiest way to do this, since the application is only given to people who have a need to use it..
So far, I've had a few ideas on how to accomplish this.
1.) Embed a tolken into the client application that gets sent when the client does a login (login is handled by a chrome/XUL interface). This wouldn't block at the server level, just at the application level. The key could be stolen as easily as a password, but not guessed by brute force as easily since it could be any length or complexity.
1a.) Add a special tolken parameter to the client browser header on all requests. This is more like security-through-obscurity, but could certainly slow down an attacker trying to brute force passwords if login always fails (even with the right password) when the magic string is missing from the request..
2.) Embed a client SSL certificate into the client program. This seems like it might be a good solution, but good documentation on cleint-side SSL is almost non-existent. We would NOT want to sign a certificate for each user, nor would we want the user to have to create a certificate or be bothered with security dialogues at all. The private key would have to be imbedded into the browser, and would be one key shared among all client programs, and distributed per-installed in our custom browser.
3.) Check the user agent string. I think Apache can restrict based on this. But it seems like a weak measure at best. I would probably do this in addition to other measures.
I'm hoping for a better idea on how to do this?
