1

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?

  • What on earth led you to needing to distribute your own browser for a web app??? – Grant Sep 8 '13 at 19:09
  • @Grant: we do the same; this ensures that any client can work with our webinterface, even those who run ie7. it's easier to maintain a webapp if you have to test only one browser.if you have organisations as customers, not hipsters, what would you suggest? – that guy from over there Sep 9 '13 at 20:40
  • @Nick: i'd opt-in for solution 2 too. regarding documentaion on "apache ssl client authentication": take that – that guy from over there Sep 9 '13 at 20:47
2

Including a client SSL certificate with the modified browser would be easiest and probably more secure.

If you are using the same key for everyone you lose many of the advantages of client certificates, but its better than checking useragent. And I assume you will still require a username and password to login.

0

Have you thought about VPN? That sounds like exactly what you really want.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.