I have a web server which supports only the company's Intranet, not the external Internet. There will be about 100 different users who will connect to a web application on this server and they all have their own login accounts. Currently, the web application doesn't support HTTPS because of some design flaws, which take time to fix. So I have two options: 1) Delay installation of the application until it does support HTTPS. 2) Just install the thing because there isn't a huge risk, since it runs on the internal network only. In time, it could be patched and moved to a secure server.
The data managed by the web application has a privacy element, since it's mostly customer information. (But no creditcard or bank account data.) It's still considered sensitive information, though. But not sensitive enough to defend at all costs. And although there would be one or two users with some technical knowledge about computer hacking, most users are not IS specialists but just generic users. (All users use a regular user account, not administrator accounts. Installing additional software by users is made [almost] impossible.)
So, is there a big risk when I install this application internally on a less secure connection?
Add-on: We don't support WLAN. Visitors can plug in to the Network but still won't have access to the Intranet environment. I'm not an expert on this topic, but as I understood, the machine needs to be part of our domain before it can access the Intranet environment. (This has been tested!) Since users can't install additional software, it would be difficult for them to install additional hacker tools. Every system also has a good virus-scanner active which is kept up-to-date. Plus, all outgoing Internet connections will have to pass an additional proxy server which does a few additional checks. The users know that their Internet behavior to outside sites is monitored. And although any computer might be hacked, the system isn't sensitive enough to go to panic mode and make sure everything is secure. Worst-case scenario would be that a hacker deletes all data, which means we have to restore a backup. Or he gets a list with snailmail addresses of customers, their jobs and some financial information but no references to bank accounts or other account information.
Add-on2: I'm asking this simply because the regular administrator is unavailable at this moment. (He had an accident due to the bad weather conditions in the Netherlands. It's not critical but it takes a while for him to recover.) The application is new and will have no data once installed. I was told that it could take up to 2 months before he recovered well enough to continue his work so the decision is mainly about installing it without his support so it can be used already or to wait until he returns, which would probably delay things for as long as he's away or until we've found and trained a qualified replacement.
How should we know whether there is a big risk?
We don't know how secure your border routers are, we don't know whether somebody could walk in and plug her laptop right into the central switch, we don't know whether there is an open WLAN that could be used to sniff for passwords, we don't know whether those "two users with some technical knowledge" have an incentive to cause harm -- in a word: we don't know anything to base an assessment on.
Some general advice: you always have to assume that there is nothing between your service and an attacker. If there are passwords involved, if there is any kind of sensitive information involved, all connections should be encrypted.
There are ways to secure an HTTP-Service even if it doesn't support encryption itself. One possibility is to put it behind a reverse proxy that talks HTTPS in the front and HTTP in the back (has to be on the same machine, of course).
Another possibility is to use some kind of VPN or even SSH to tunnel the higher level protocol (HTTP in this case) through a secure channel.
You can use a reverse proxy. The proxy will have a SSL certificate for client connections and will connect to your application with a non encrypted HTTP connection.
You haven't said what OS you are on. If this is in a windows domain environment domain and server isolation will encrypt the traffic and prevent non domain machines from seeing the system. See this solution accelerator for details. In a non windows environment similar functionality can be set up via IPsec but it's more compicated to implement.
For an internal network, if you don't want to pay for the wildcard cert (or dedicated cert for the server), simply create a self signed certificate. Since it's your company, it shouldn't be too much of an issue for the users to accept the certificate. And depending on how your network works (and your admin friendliness), you might even be able to push it to the users so they won't be bothered.
If you're dealing with any sort of sensitive information, you should be doing it over HTTPS.
It's a balance between
both in terms of money, reputability of the company, personal blame, etc. You can get around most of those things by adding a logging system that monitors who does what and possibly the IP address. Also monitor successful login attempts, not only denied.
Yes, it might be cumbersome, but will offer some protection against a few threats. It's not a 100% safe solution, but will keep you on your toes enough to get a hang of the system and to understand how it is used. After all, if users are required to come up with a 16-chars long password containing unicode chinese characters and punctuation, they might just save it on a post-it. Or on the browser cache. Or on a PASSWORD.TXT file on the desktop.
So, balace losses and gains and DON'T FORGET to inform/tell your supervisors. Have their approval in writing, just to avoid blame.
because your site offers sensitive data as you mentioned, it should be encrypted. Of what type are the design flaws? Is it possible to implement redirect rules for https to overcome the design flaws temporarily?