designing secure intranet (ASP.NET) application

Question

I am wondering if i need to add any other kind of security on this asp.net application - web forms (available only on network domain and through VPN connection)?

Application Environment: Asp.net 4.0, Vb.net, Oracle 10g, Web Services, Window server 2003 or 2008, Hosted on domain

User Authentication Mode : Window (Not using asp.net membership)

Authentication Scenario:
Application is accessible via intranet site and system authenticates user with his system user name. On the default page system will first get the current user name (HttpContext.Current.User.Identity.Name) and then match it in the user table (oracle DB), if it is matched then store procedure will return all the access permissions (menu details) relevant to this user group. There is a user group and permission table in the oracle DB. In the store procedure, system will also check the user permissions before any DML transaction.

Main security concern

Major: restrict people to access the information depends on their permissions. Normal user shouldn't get access to other's data.

Minor: We don't want anyone to get into our system outside office network.

Answer 1

As Joachim says, this arrangement only supports Windows systems running on the local network. Shifting to basic authentication will allow more clients to connect but exposes the passwords on the network (effectively in clear text) without HTTPS. Forms authentication is similar.

Without server authentication, users could be redirected to a similar server without their knowledge or suffer a main-in-the-middle attack. HTTPS gives you this with the server certificate. This may not be a concern on a local network but users' hosts (in c:\\windows\\system32\\drivers\\etc) files are often vulnerable.

Without encryption, any user can sniff the information sent back and forward over the network assuming they are on the same subnet. This may be an acceptable risk for most applications but not if the information is sensitive, eg contains sensitive or personal information.

Consider replay attacks (see How do I prevent replay attacks? for an example) if people are performing important operations like approvals.

Consider auditing access to the database, particularly the user group and permission tables. Someone could add themselves or move them into a group, perform an operation then remove themselves. Check your pages for SQL injection and similar attacks which could accomplish this.

In summary, how likely are people to compromise or interfere with the system and how much are you willing to invest to protect it? Assuming the server can handle the load, HTTPS is a hard to go past as a first step.

Answer 2

Unsure what kind of ASP.Net technology you are using (MVC/Razor/Web Forms).

If you are using Web Forms , then you can immediately take advantage of ASP.NET Login Controls like LoginView Control . They work with ASP.Net Forms Authentication (with or without using ASP.net Membership). You can also take advantage of Roles .

Your intranet server should be "protected" if it's not exposed in your network publicly (in any way). Of course that's a bold statement that depends entirely on your network implementation - eg subnetting, internal net/no nat/route/no port forwarding, no dns, etc. This makes VPN as your only point of exposure from the outside, then you must enforce proper security policies for your VPN infrastructure - eg one-time passwords, client inspection, etc.

---

Update:

If you are using Active Directory, you can create users/groups in AD to provide access accordingly (eg Finance AD group can only access "finance" folder). I haven't kept abreast with browser support for NTLM outside of Internet Explorer however.

You did mention user data is in an Oracle db however(?). I'm not familiar with solutions that allow no login screen access (to network resources) using a db/Oracle.....

Also, that would mean one-time passwords for VPN access may not be available. Look into token based VPNs so users can still use their AD credentials but need a new token each time - this will help mitigate the "passwords in yellow sticky notes" (because you can have tighter control over tokens).