We are building a webservice that will only be queried by other servers on our private network. I was suggesting that we put that webservice over https and use either client ssl authentication or a password that we would send with every request to protect unauthorized access to the webservice.

The webservice is able to make modification to the data in our databases so if an attacker could access it, he would be able to alter our important data. So, I thought it was important to protect it properly but when I talked to the network admin, he dismissed my concerns as paranoia and said that the webservice will be on http without any authentication. His argument is that the webservice is on our private network and behind a firewall so we don’t need any other protection.

I’m not sure what to think… Should I worry that we will have a webservice over http without any authentication?


Would using a password without TLS be enough since it's on a private network? The "issue" really seemed to be around wasting time to setup TLS for "nothing".

  • Google "defense in depth" and show it to your myopic admin. Oct 29 '15 at 4:25

Short answer is "yes - you should worry".

Modern attacks almost always target clients; and once an attacker has a toehold in your network he/she can pivot to any resource the client has access to. He/she may also be able to "man in the middle" traffic on your LAN; or better yet - gain credentials to the switches/routers and sniffers in your network.

So I'd suggest you definitely should use https (TLS 1.2 or better) on the web service. Sessions should also be authenticated: for user convenience you may need to use some kind of session cookie or "single sign on" with Kerberos or similar.

In addition: your database server should be protected. Is there any reason for clients to directly connect to it? Probably not. So use some kind of firewall in front of the database server to limit inbound connections: only your web/application servers and systems management servers need access!

Firewalls on the perimeter are important but they are far from being the only defense you need. For background consider some of the high-profile breaches we've seen in the news recently! Access wasn't obtained by breaking through a firewall - almost always it was obtained by compromising a client that is already inside the network.


Should I worry that we will have a webservice over http without any authentication?

Yes, you should!

Your worst enemy could very well be inside your network. We'll show you how to prevent insiders from sharing/destroying your critical data.

Since your database will be accessible from everyone inside your network you better have to have them authenticated so you will be able to determine who did what ...

In many companies have the following best practices for internal only exposed web services / web applications:

  • HTTPs shall be enforced by default. The cost of supporting https is negligible. The only pitfall is the SSL cert but since it's internal you could craft your own ca and distribute the root CA cert on your machines internally.
  • AAA (Authentication, Authorisation & Accounting). You should always have some sort of IAM/UAM solution for your web services in order to comply with the least privileged principle. If people don't need to have access to the data, don't let them ! Accounting (log, monitoring ...) can provide important data when something bad happened. Don't give to much trust on your employees / coworkers. report

If there are users which can reach these internal web service with the same browser as they do requests to external sites then a visit to an external page could trigger requests to your internal site, i.e. CSRF. While the attacker could not read data directly this way (s)he could at least write data and with an additional DNS rebindung attack maybe even read data too.

Note that TLS alone will not help in this case. What will help is the use of client certificates with TLS or with a password, so that only authorized clients (i.e. your other servers) can access the web service. I will assume that these servers will not run normal browsers but only programs to access only your web service, so that it will not be possible to use mount a CSRF attack with these server side programs.

If your private network is instead completely separated from the rest of the system (no direct or indirect access) than you probably need not to worry that much for now. But note that network structures change and what today is an isolated network might be connected to some other network tomorrow and often without deeper analysis of the security implications.

The "issue" really seemed to be around wasting time to setup TLS for "nothing".

If you can guarantee that nobody in your network is able to sniff the traffic then TLS might not be necessary. Of course this is easy said but hard to control: there might be malicious users but more dangerous are probably compromised systems. Since your comments show that the users of your network can access the internet than chances are high that sooner or later a client system will be compromised. And unless your network is really protected against all the ways of sniffing the password might probably be detected (see also What are the risks of running Team Fundation Server on HTTP?).

  • Yes, with our current setup, nearly every employee could access it using their browser so CSRF is a valid concern. Would just using a password without TLS be enough (he seemed really against TLS as it was "too much" trouble to setup...)
    – Gudradain
    Oct 28 '15 at 20:44
  • @Gudradain: as long as the password is only known to the server applications CSRF from the browser will not work because the user can not authorize with the browser. This is true at least as no system in the network is compromised and might be used for sniffing data. See also security.stackexchange.com/questions/103804/…. Oct 28 '15 at 20:50

You can process by steps and replicate them for each server.

You can protect the environment of your server: forbid physicals access by unauthorized personals

You can filter the IP adresses which are permitted to acces the server (maybe the database server dialogue only with the web server and the admin's pc)

You can limit the opened ports on yours servers and limit the running services.

For each service you can apply security policies, for example for your webservice:

  • force https, force authentification with strong password or certificats
  • limit tries of connection
  • control connections with with fail2ban or ohter
  • apply the rights on yours databases most strictely as possible (which user can read and/or write in which table), forbid the user root to connect on your database from the network.

The idea behind that is to apply the good policies on each aspect of your network and yours servers.

In your case,

the webservice is able to make modification to the data in our databases so if an attacker could access it, he would be able to alter our important data.

it seems important to apply these essentials security policies.

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.