I'm developing an application over an intranet and is used only by an internal employee. There wouldn't be any external parties involved here and no external communication would be used by the application.
Does it need secure software design in this case? If so, will it be enough to follow the guideline of OWASP?
While Kyle Fennell's answer is very good, I would like to offer a reason as to why it is recommended for internal applications to be designed securely.
There are many different versions of this factoid. "50% of all successful attacks begin internally", "Two thirds of all data breaches involve internal actors", etc.
One statistic I could find was Verizon's 2019 DBIR, in which they claim:
34% [of the analyzed data breaches] involved internal actors
Whatever the exact number may be, a significant amount of attacks involve internal actors. Therefore, basing your threat model on "it's internal, therefore it's safe" is a bad idea.
The reason why I bring up misuse is because not everything that damages the company is done intentionally. Sometimes people make mistakes, and if people make mistakes, it's good if machines prevent those mistakes from having widespread consequences.
Imagine an application where all users are allowed to do everything (because setting up permissions takes a long time, wasn't thought of during development, etc.). One user makes a mistake and deletes everything. This brings the entire department to a grinding halt, while the IT gets a heart attack and sprints to the server room with last week's backup.
Now imagine the same application, but with a well-defined permission system. The user accidentally attempts to delete everything, but only deletes their own assigned tasks. Their own work comes to a halt, and IT merges the data from last week's backup with the current data. Two employees could not do any productive work today, instead of 30. That's a win for you.
Some companies are technically one company with multiple teams, but they are fractured in a way that teams compete with each other, rather than working together. You may think this does not happen, but Microsoft was like this for a long time.
Imagine writing an application to be used internally by all teams. Can you imagine what would happen once an employee figures out you could lock out other employees for 30 minutes by running a script that he made? Employees from "that other team" would constantly be locked out of the application. The help desk would be busy for the 5th time this week trying to figure out why sometimes people would be locked out of the application.
You may think this is far-fetched, but you would be surprised how far some people would go to get that sweet sweet bonus at the end of the year for performing better than "the other team".
Now, in 2020, your application will only be used by a small group of people. In 2029, the application will be used by some people internally, and some vendors, and some contractors as well. What if one of your vendors discovered a flaw in your application? What if they could see that one of their competitors gets much better conditions?
This is a situation you do not want to be in, and a situation that you could have prevented.
You write an internal application that does some database access stuff. It works fine for years, and nobody ever complained. Now you have to write an application that accesses the same data, but externally. "Easy!", thinks the novice coder. "I'll just re-use the code that already exists."
And now you're stuck with an external application in which you can perform SQL injections. Because all of a sudden, the code that was created "for internal use only", no pun intended, is used externally. Avoid this by making the internal code fine in the first place.
The answer to this question is another question "Enough for what?". This may sound nitpicky at first, but it illustrates the problem. What exactly do you want to protect?
Define a threat model for your application, which includes who you think could possibly be a threat for your application in what way, then find solutions for these individual threats. OWASP Top 10 may be enough for you, or it might not be.
Yes, internal applications should be secured with due diligence and yes OWASP can be a good guide for securing your application. Also look over Microsoft's Security Development Lifecycle (SDL), It is a security assurance process that is focused on software development.
Why?
Others already mentioned some good points about evil employees, infiltration, defense in depth... but it's much more practical than that. I can attack your internal intranet application from a random web page.
People click links all day. Sometimes because a colleague saw something they want to share, sometimes from search results (or ads), sometimes a cute cat picture with a thousand upvotes from a site like reddit, sometimes from phishing emails.
There are a lot of ways an attacker can get you to click a link. Let's pick the cat picture: For those thousand other people that upvoted the cute cat picture, it was harmless. Until someone clicks whose company uses the amazing intranet website that doesn't follow the OWASP guidelines.
Clicking links to malicious pages should be mostly harmless: the regular updates for your browser keep it secure and don't allow the website to access the rest of your computer. That's why it's so easy to make you click a link, because it is "mostly harmless". But that doesn't mean that having a page, that runs JavaScript code, inside the target company network is not an advantage to the attacker.
The page with the cat picture could contain something like this:
1. <img src=cute_cat.jpg>
2. <iframe name=hiddenframe style='display:none'></iframe>
3. <form action='http://intranet.local/addUser.php?username=joseph&password=123456' id=myform target='hiddenframe'>
4. <input type=submit style='display:none'>
5. </form>
6. <script> document.getElementById('myform').submit() </script>
Upon opening the page, completely invisibly, this will be able to call the addUser.php page on your intranet application. If you are logged in (as you typically are while at work), the browser will happily add your login cookie (containing the session token by which the intranet recognizes that you are you). The attacker now has an account on your system. For people without the intranet application, it will just do nothing.
This is an example of a Cross-Site Request Forgery (CSRF) attack (plus a few other bad practices), which following the OWASP guidelines would prevent. A brief overview of what this code does:
addUser page with some username and password, picked by the attacker.submit() on the form, so that the submit button triggers.If the addUser.php page does not have (or check) anti-CSRF tokens, this attack is 100% possible and lots of sites were vulnerable to this in the past. One example? My school's intranet where grades were registered. I could have sent a teacher a link to a digital hand-in, and the page could (aside from showing my hand-in) have changed my (or anyone else's!) grades in the background.
It's still common today. Here is another, much simpler (and less harmful) example:
1. <img src='cute_cat.jpg'>
2. <img src='http://intranet.local/logout.php'>
This just calls the logout page. The browser expects an image from that logout.php page, but if there is no image (because it's a logout page), it just discards the result. Meanwhile, the intranet application logs you out. If the attacker manages to trigger this every 2 seconds from a tab that you keep open for a while, you might not be able to use the intranet because you keep being logged out.
Remember the giant Capital One breach in August 2019?
The root cause was a server-side request forgery (SSRF) vulnerability in an internal Capital One app.
So Yes, you need to worry about secure design on internal apps.
What platform? Before I retired, I had to make sure anything I wrote could not fail to handle all exceptions. any unhandled exception would present to the user a pop-up begging them to send data to Microsoft which could contain personal information that Microsoft promises to not use.
Of course, most users will promptly click OK without reading. And whether or not Microsoft honors that promise, sending the data would make the hospital liable to prosecution under HIPAA. And HIPAA requires Microsoft to report us if they detect any patient information.
MacOS has a similar pop-up, and if the user doesn’t turn it off in settings in advance, IOS sends the data without asking.
And then there’s Android, coded by one of NSA’s biggest competitors.
So, the answer is “yes” for any of those platforms.
Absolutely 100% yes.
For all the reasons given and one very important practical one: You never know on which day someone in management decides to put that thing on the Internet. "It works so well, our external contractors should use it." or some other reason.
You want to completely refactor it when that happens?
A very common thing to happen in a company is for people to like using an internal tool, mention it to a partner or customer, and then there's clamoring for the tool to be made available to external users.
Yes, use some security precautions on the tool, and don't lock yourself out of securing it in the future. The simplest things go a long way, like "create a dedicated user instead of root for this process" and "restrict the user's and process' visibility only to things that the tool needs".
I am going to post somewhat of a blanket statement here, but if your application is professionally coded and follows best practices, it should be already fairly secure out of the box. At least the most common vulnerabilities such as SQL injection should not be exploitable.
And the development frameworks available nowadays actually make the job easier for you. On the other hand, if you prioritize speed of development over quality, if you are stuck with coding guideline from the 1990s, if you don't use parameterized queries... then you're asking for trouble.
At the very least you should pentest your application to make sure the most obvious mistakes are not present in your code, and that a script kiddie cannot compromise your system by launching an automated attack.
Like Tom says, stuff that is isolated today could be exposed on the Internet tomorrow, due to a management decision, or a router/firewall misconfiguration. The application might be exposed by accident, without you being aware, or after you left the company.
And you would be surprised at how bored employees spend their free time. I once found a port scanner on the workstation of some administrative clerk who is definitely not computer-literate. The tool didn't land there by accident. Too often, employees are the weak link in any organization.
Then the appropriate level of paranoia depends on which kinds of assets your intranet is giving access to. If the assets are rather sensitive, and the application gets hacked one day, your job could be on the line if the forensic investigation shows that your code was sloppy and did not comply with the bare minimum security practices. Worst case scenario is that you get sued by your employer/client for malpractice - it surely must happen from time to time.
I am wondering what happened to the IT guys who worked at Equifax ?
Consider the network topology too. If the intranet is hosted in-house and directly connected to your LAN, then it is a gateway to your LAN and other resources. If I am an attacker and I want to get into your system, I will be looking for weak spots, indirect but overlooked routes.
So I would rephrase the question like this: Under which circumstances one does not need secure software design ?
Think about your employer/client, but also think about your reputation. There is a good chance that one day, somebody else will look at your code. For example another IT guy who is tasked with migrating the application in the future, anything. Somebody who is maybe more knowledgeable than you are, and will not have anything nice to say when looking at your code.
