Should web applications that are only accessible from a LAN be held to the same security standards as publicly accessible websites?

Question

Many security measures are intended to protect against hostile users who want to abuse the software or get access to content they don't have permission to access. Things like CSRF protection, SQLi protection, TLS and many other security features mainly protect against malicious users. But what if all the users can be trusted?

Suppose you have a fully internal web application that will only ever run on the intranet of the company and will never be accessible from the outside. assume that all the internal users can be trusted, there are no outside users and the data inside the application is of not much use to attackers. This means the threat model is very limited and there is not much sensitive data.

Considering these details, it seems like some of the measures, like TLS and XSS protection, wouldn't be as important. After all, there is very little risk of attackers intercepting traffic, and the users can be trusted to not enter XSS payloads. In this case, would it still make sense to implement security measures against traffic interception or malicious users?

Answer 1

Yes. Absolutely, yes.

Your assumptions about your internal network have issues:

• you assume no attacker would ever gain control of any device in your network, which is a bad assumption to make (see http://www.verizonenterprise.com/verizon-insights-lab/dbir/, https://www.fireeye.com/current-threats/annual-threat-report/mtrends.html). Attackers will go quite some length to gain a foothold in a network, and there is a commercial marketplace for buying compromised hosts within specific companies.
• you assume only users have access, but what about third parties, such as managed service providers, contractors, temporary employees? Also, what happens if someone breaks into wifi? Or gains access to a wired port (e.g. a pwnplug)

More generally, there is also the matter of why have two sets of practice/standards, when surely it is more efficient to have a single standard that applies everywhere?

You might find it useful to read Google's paper on BeyondCorp, https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44860.pdf.

The tl;dr being that in their conception of the network, you make assertions about users and devices, but not about the network - mostly because it is simpler to assume all networks are hostile, than it is to assume some are, and some are not (in part, the cost of misclassifying a network as safe could be very, very high).

One possible reason for such an approach is that the Snowden leaks revealed that previous assumptions about the safety of their network were incorrect - the NSA tapped into fiber in order to tap into (at the time unencrypted) inter-DC data flows.

I think the basic answer to your question is that the boundary/demarcation point for security is no longer at the edge of your network, it is the devices on your network. And as such, it is both simpler, and more realistic, to focus on preventing categories of attacks/abuse, rather than to consider that one network is 'better' than another. You may not need quite such strong controls on an internal DMZ as you would on an external one, but assuming that your network is secure is a dangerous assumption to make.

Answer 2

The attack surface on the internal network and external network is different which means that different security measures are appropriate. That does not mean that the attack surface in the internal network is smaller because on one side users are usually more trusted and on the other side there are more critical data which are often easy to access from inside.

Even if all users can be trusted it is still possible that their system gets infected with malware. Apart from that many of the attacks you've mentioned like CSRF, SQLi or XSS can be done cross-origin, i.e. it is enough for an internal user to visit an external web site which then uses the internal browser as a trampoline to attack internal systems.

In summary: proper protection is needed for internal networks too, even if all users can be trusted. This is especially true if it is possible to access both the internal network and the internet from the same system because this allows cross-origin attacks from the internet against internal systems.

Answer 3

I would say no, mainly due to this quote from the original post specified:

there are no outside users and the data inside the application is of not much use to attackers

The main consideration is that, even in an internal network, hostile actors can still compromise systems that can then be used to gain access to your web application.

Your threat model I think is still an important consideration here, and despite the concerns that an application can be broken into, if all you're protecting is Joe's holiday schedule and Sally's party invitations, it may not be worth implementing HSTS, HPKP and XSS filtering etc.

Most malware that will infect local machines is not likely going to be designed to run a network scan and find intranet webservers. Those that are, probably will be going to be looking for known packages (although some will just look for common names and blast every form it can find with known exploits)

This is similar to security through obscurity, and is definitely bad practice. However, practical concerns will outweigh ideals in many scenarios. I would still recommend at least a self-signed certificate and HTTPS/TLS though.

A system like this can not survive a targeted attack, but since you've eliminated the most common attack surface (public internet access), the bulk of automated misuse will not find your site.

Answer 4

A few additions to the excellent answers:

• a lot of the stuff you should do to protect against XSS (properly encode data when you display it, mostly) is also needed to prevent a variety of bugs that can be triggered by perfectly innocent input (you don't want a text field to be broken just because it contains a < or & in the wrong place). The same applies for SQL injections (you don't want a query to break juste because there's a quote in a field). So you need to do that stuff anyway, even if it's not for security.

• there is a strong tendency for browsers to become more and more restrictive about non-TLS sites, to the point that they might become quite unusable in the near future (or at the very least display so many warnings that it will frighten your users).

• also, even if you are only targeting internal users on an internal network and they could be fully trusted (see other answers for reasons why they shouldn't), things may change in the future. You may need to open up (parts of) the site to external users (partners, suppliers, customers...). It's much easier to take the right measures when you are doing the initial development than to retrofit security at a later time.

Answer 5

Make a Threat Model. Depending on the data stored and the threats you identify, you may find that you need different security standards or that, all things considered, there's not actually any crucial difference.

Answering the question in general terms can go this way or that, depending on the assumptions taken, as you can already see in the answers given. But in the end, LAN or public Internet is only one variable in the set and you can't solve x = y + z with only one of the variables given.