Should I be worried about SQL Injection for Internal Web Apps?

Question

I've been working a lot lately with writing report generating forms at work. The reports sometimes require input provided by a drop-down list and sometimes require data to be entered by key.

My question is more about practice.
Is it common practice to implement SQL injection safeties in all cases? Or given that these are internal apps it's not worth the time and effort to worry about it? Reason behind this is that it is generally accepted that the intended users are using the system without malevolent intentions.

Or is this question too specific to be applied to such a broad case and one should seek answers from management?

Answer 1

Protections are in place to address risk - protections have a cost (time/effort to code, in your case) and those costs need to be compared to the benefits/costs of implementing them. If the cost of the realized risk is lower than the cost to implement protections, then it doesn't make sense to to implement protections.

Answer 2

I don't allow SQL injection flaws on our internal web pages. The reasons I offer are:

• Protect your web sites from malicious insiders.
• There is no such thing as an internal web site. When a user of the internal web site has a browser that also is used for external web sites, you can't say the internal web site is segmented from the outside internet. My internal site trusts my browser and if my browser is compromised by Cross-site scripting, malware, clickjacking, Cross-site request forgery, a bad extension, a java exploit, a flash exploit, or any other common web attack, then the attacker can use my browser to attack internal sites.
• SQL injection flaws on a low value target can give a toehold in attacking a high value target.
• Protecting from SQL injection, especially if you are doing it as you develop your apps, is a low cost practice with high rewards.

Answer 3

Short answer: Yes! Implement security best practices in any application storing sensitive data, or capable of accessing other servers with sensitive data, regardless of it being public-facing or not.

Explanation

It is an all too common practice for companies to invest in securing their perimeter only. This means that access from and even to the internet is highly restricted and secured, but within the internal network security is much more lax.

Hackers know this. Thus, they often try to get within the internal network and then conduct attacks to increase the scope of their access throughout the network. As a first step in an attack, hackers often have been successful in sending "beachhead" malware (meaning malware that lets them connect to one machine on an internal network to establish a foothold) via phishing attacks, web exploits and other means.

This is how breaches end up occurring -- e.g. the Anthem breach. Once inside their internal network, hackers found it easy to pull up databases with lots of private data since they were poorly secured. The assumption that "it's on the internal network -- it's safe" proved to be a grand folly in this instance.

In the end, you have to determine what you think the risk is of having your internal network accessed by a third party; and then how detrimental the compromise of that data will be. If it even makes you a little worried, I'd recommend implementing SQL injection and other exploit protections on your internal application.