Application Security in n-tier Application on Windows Server

• Download images - 536.35 KB

Table of Contents

1. Why Security
2. Acronyms & Terminology
3. Security Layers Architecture
4. Secure Entities
5. Security Threats
6. Security Context
7. Separation of context
8. Beyond Service Account Framework
9. Conclusion

1. Why Security

Software Applications are built and run in millions nowadays on a variety of platforms. These applications are open to all kind of users ranging from developers, own employees, customers, end users, random users, professional hackers etc. So, applications which are open in internet are more prone to unauthorized uses & malicious threats, which challenge the application every now and then by the process of stealing confidential data from applications, creating junk data, modifying control data, and applying heavy loads, corrupting and brining done systems, or take control of the system remotely. As the old saying goes, prevention is better than cure, so, it is wise to enforce a threat modeling before commencing any system application design and to mitigate such attacks which may exploit configuration weaknesses that prevail in different servers in the application clusters. By means of security, we propose to uniquely identifying the clients of your applications and services. The correct users only are able to process the resources and operations that the authenticated client is permitted to access. Resources include files, databases, tables, rows, and so on, together with system-level resources such as registry keys and configuration data. The audit data are equally important to perform business rule validated actions. For example, if a user is allowed to take a bank statement just once per month, under no circumstance, should he be allowed twice. This also elaborated to keep his data private, no other persons can read it. The data integrity is another form of security threats where no user can accidentally or deliberately do the data modification. There are some thoughts that legal users should never be denied of their information, even if there are some attackers with denial of service attacks to crash an application.

2. Acronyms & Terminology

Term	Meaning/Expression
Asset	A resource of value, such as the data in a database or on the file system. A system resource.
Attack/ Exploit	An action taken by someone or something that harms an asset. This could be someone following through on a threat or exploiting vulnerability.
ACL	Access Control List
Countermeasure	A safeguard that addresses a threat and mitigates risk
OS	Operating System
Threat	A potential occurrence, malicious or otherwise, that might damage or compromise your assets
Vulnerability	A weakness in some aspect or feature of a system that makes a threat possible. Vulnerabilities might exist at the network, host, or application levels.
MDI	Multiple Document Interface
WinForm	Form Application runs on Desktop/Laptop without any help of any supported windows service. They are found in executable form.
ASP.NET	.NET version of application which runs in conjugation with IIS hosted in Window Server
IIS	Internet Information Server is made for windows hosting of an web site
AD	Active Directory

3. Security Layers Architecture

Based on the application architectures, the security layers can be defined and applied in a variety of forms. This paper is based on applying security around a typical n-tier ASP.NET application which is distributed over multiple technologies and platforms and physical networks. The architecture can enforce a layered security approach to mitigate security threats from within the network and outside of the network. The security solution is based on distributed application already implemented on Microsoft technology supported by ASP.NET, ADO.NET, IIS 6.0, WCF, Web Service, COM+, MSMQ, SQL Server 2005, and Windows Server 2003. Though the server and services of future may vary in versions, the implementation of security approach remains same in the place. Let us look at the architecture of the application.

4. Secure Entities

The compromise of security can happen on multiple access points ranging from user interaction to own user who may be a threat to the applications. The malicious intentions are typically applied on a variety of computing resources which includes hardware & software components. User interaction in the form of malicious attack is landed in three categories in a typical ASP.NET application which we would like to make secure and robust. They are as follows:

• A web browser or a third party desktop application

  In modern days, there are several web browsers that have made their presence into the market. The major ones are Internet Explorer, Mozilla Firefox, Opera, Safari. These entities belong to internet users, so we don’t have many options to control them.

• Web Servers

  The current solution is based on ASP.NET web application. The application serves web forms to users who use browsers to read and write the information to the application. Windows Server 2003 enterprise edition with service pack 3 would be an example of the server. Inside the server, there are other resources which need to be secured. For example, Shares folders Auditing and Logging, Services, Files and Directories, Registry, Accounts, MSMQs and other window components like COM+. This component can be remotely administered, so providing an encrypted channel of communication and using IPSec to limit the computers that can be used to minimize any attack on them. We can limit the number of Administration accounts. However, I am keeping this out of the scope of this paper.

• Corporate Client Application

  They are the desktop version of application. They can be MDI or a dialog based WinForm/WPF application. They are executable and directly run from Laptop or a Desktop. No browser is needed.

• Network & Firewalls

  The client computer, web servers, proxy servers, applications, database servers are connected by networks and thus insulated by firewalls. The computers belong to a domain for which there will be an Active Directory. The given users and computer can exist in on domain. Typical example is “web01.domain.net”, a machine “web01” can be called as “web01.intranet.domain.net” and person “user1” can be called as “user1@intranet.domain.net”. Protocol and port are major examples to be secured for router, switch, firewalls.

• Database

  Typically, database is used to store data related daily customer transactions or master data that control the applications. There are many good databases available in the market like SQL Server 2005, Oracle 10g, and MySQL 5.0, etc. In the solution, we will be referring to SQL Server 2005 enterprise edition. Database contains most valuable data which belongs to the client. Data are spread over multiple files over the networks. The data must be kept physically and logically secured, so that no unauthorized person can access it.

• Application Servers

  They are again 32 bits Windows Server 2003, though this can be upgraded in for other performance issue. For simplicity, we will be continuing the solution with Windows Server 2003. They are typically installed with IIS, MSMQ, and Security Alerts, etc.

• Application Itself

  The application is first contact and major concern of attack. So, any user request in any form to the application must pass the security check. There are several areas which can be targeted by hackers or malicious users.

5. Security Threats

The users with malicious intent can access resources or data which do not belong to them. With the architecture in the above diagram, the application looks unsecure enough to break into. (There are some links that exist, which are not depicted in the diagram. For example, a link exists from internet user to application server or database server.) The person who gained the access of web server can easily break into data layer of application and can access SQL Server from there.

There are many tools and proven technology employed in the IT infrastructure in the software application deployment. The perceptions are that these work very well to cut down any security threats. This is true by all means, but due to adherence of usage policy, the security is breached and loops and holes are revealed.

The most known model to understand where a security lap happens is STRIDE. Security Threats of an application can be categorized based on the goals and purposes of the attacks. Providing the brief of these attacks which can be mitigated by ASP.NET application by support from the framework itself. However, a detailed discussion is out of scope of this paper.

• Spoofing. Spoofing is providing a false identity to gain access on behalf of others. After the attacker successfully gains access as a legitimate user or host, elevation of privileges or abuse using authorization can begin. The service account implementation can take care of majority of this attack either from the internet as well as intranet/local machine code.
• Tampering. Tampering is the unauthorized modification of data. These portions of attack are handled by ASP.NET native implementation. ASP.NET has employed various mechanisms like UI validation, XSS validation, View State encryption, one-way hashing of configuration data to curb those attack.
• Repudiation. Repudiation is the ability of users (legitimate or otherwise) to deny that they performed specific actions or transactions. Authentication & authorization matrix will be very good implementation for these kind of attacks.
• Information disclosure. Information disclosure is the unwanted exposure of private data. Web pages that contain database connection strings and connection details, and weak exception handling that can lead to internal system level details being revealed to the client. Any of this information can be very useful to the attacker. This is implemented through global.asax error handling modules and interpreting actual exception to a user specific error message. Do not reveal internal system or application details, such as stack traces, --- SQL statement fragments, and so on. Ensure that this type of information is not allowed to propagate to the end user or beyond your current trust boundary. Fail securely in the event of an exception, and make sure your application denies access and is not left in an insecure state. Do not log sensitive or private data such as passwords, which could be compromised. When you log or report exceptions, if user input is included in exception messages, validate it or sanitize it. For example, if you return an HTML error message, you should encode the output to avoid script injection.
• Denial of service. Denial of service is the process of making a system or application unavailable. We can make sure the TCP/IP stack configuration on your server is hardened to protect against attacks such as SYN floods. So, configure ASP.NET to limit the size of accepted POST requests and to place limits on request execution times.
• Elevation of privilege. Elevation of privilege occurs when a user with limited privileges assumes the identity of a privileged user to gain privileged access to an application. So, service account implementation is the backbone of this architecture to provide security over the system.

6. Security Context

The job of architecture is to provide component to component service strategy to resolve a business workflow with high level of scalability, integrity, stability & availability but without compromising security. By this means, it roughly means to execute each line of code in that executing component under a known the user account who owns the activity. So, if the surface area is reduced in application, we can always ensure no more applications run on the server in unknown account. So the scope of unknown code remains a least possibility. There is a need to carry the user context in every bit of component and access check in the code side will ensure no unauthorized code executes on legitimate account.

6.1. Flow of Security Context

The security context flows from existence of a user of the system to his data store. User Identity is mapped to a security context which is carried with call whenever executions take place in the applications. By that means, data or computer resources should be operated by valid users who have derived logical rights to access the data or resources. Else the user can do harm to data or resources which do not belong to him at all. The security context is created when a user exists and he or she starts interaction with the system. The security context is initiated from user interface which is then by authenticated by a program and authorized by another program to access a set of resources. Authentication and authorization of such user actions are handled by application security framework which can be a placed centrally within a system or an external providers or in a mix mode. ASP.NET framework provides the mechanism to do the authentication and authorization part. They can be extended by Membership providers which are pluggable. The logical stack of context flow would go like this diagram provided below:

The context will then follow with the user data from among heterogeneous components within the applications. The code at the application will always execute in some user context. If it is a desktop environment, the user context is a logged in user who is local to the system or has an access to login to the system. If it is a window service or batch job, the service or job always configured while creating the services. However, a code can always impersonate to other users which can pose a great risk to security. So, configuration of such code is made highly secured by configuring service account (Described in section 6.4). The security context communication between two components can happen in two ways.

6.2. Synchronous Call

In distributed applications, most of the participant components communicate with each other with a synchronous call. So, a security context flows from one component to other in the form of domain trust, certificates, headers or method parameters. So, the client reaches to the server component with security context, and server responds to the client immediately if the security context does not match the requirement. So, server can impersonate the call or map the client user context with server user context. Since the internet has grown to a vast number of users, the current solution will go for second one and, impersonation will be used when building an intranet application. The mapping of user will be per service basis where domain account will be used to run those services so that the user can be controlled by administrator remotely and no local user can penetrate in the server and execute any code there.

To ensure any external user goes into the web server; remove all the access to local user, inbuilt users on the machine. So, request from internet to a sever goes via security context by invoking some request to the applications by some user interface, e.g., a Browser. With the example given above security context, when a user exists, he can browse the ASP.NET application which is hosted in web server. User logs in at terminal like desktop/laptop/mobile, etc. The OS on the client machine then create a security context on his behalf and the context travels on the wire to reach web server where ASP.NET application resides. The web server is running in another security context, on behalf of another trusted users, typically as the user is a local user created in the web server. Typically, this is run on anonymous account for form based ASP.NET application. So, every call from a browser will run ASP.NET code in user IUSER_MachineName user which is inbuilt on the server. To eliminate any unknown user invokes any code in web server; create new the security context in defined service account which is typically a domain user with least privilege. For default privileges of web account, refer to http://support.microsoft.com/kb/812614. The account is configured at IIS level.

So, the intention is to run the user code in context of user who operates on his data, resources on which he has permission. An unauthorized system access will break the rule and is an exception. Every action is to be performed with context of defined set users.

The system resources are configured with service account at IIS level for low level access.

For more fine tuning of every low level resource, Web Site permission can be granted or revoked.

If the IIS even allows the security context flow to the system / code, service account still needs little more access to execute the code. So, a malicious intent user security context will be eliminated at this level. And next challenges remain with proxy users who are valid users either authenticated previously or it is a UI level attack. For UI level application attack, validations of user inputs are best solutions. These parts of security are managed by ASP.NET form authentication, authentication and authorization module. These discussions on Input validation, Authentication, Authorization, Configuration Management, Sensitive Data, Pen Test, XSS attack, SQL injections are not in the scope of this paper. Though there are several improvements in IIS7 / Window Server 2008 to minimize surface area risk to security to the system, still we want to safeguard our application from malicious user inputs.

A window service is configured in a different way. The install utility or MSI creator defines the service accounts to be use. This is optionally also available in verbose mode of MSI installation. If these account configurations are not available during installation, they are configured in service console.

To configure user account in any window service (for example: Google Update Window Service), locate the service in Service Console and right click on that to pop-up configuration console.

Then go to Log on tab, there are two options available in user accounts. A local System account is already configured which we don’t want. The account is a privileged account and local user. The same user cannot be controlled by Active Directory as well. So, we configure a newly created account mydomain\myaccount in active directory with Run as a Service Privilege. Service Accounts are described in Section 6.4.

6.3. Asynchronous Call

These calls are executed in workflow. Queuing Process does not depend on user interaction immediately. The user context is abstracted and confined in a self extracting token which is used by serving component. The system job or services invokes on behalf of the users. Under no circumstance, the code runs in context of generalized users where the actions is performed by authorized roles or users.

On asynchronous operations, greatly MSMQs are preferable choice as these objects provide the good amount of durability, scalability, resilience and stability over transactional operations. Since these can exist in distributed components and endure the breakdowns and recover, we go for these kinds of solutions. The risk is, an unknown user can read/write messages from the MSMQs. To minimize the attack, service accounts are placed in queue management console. Public queues are domain controlled and thus they are configured through Active Directory. So, a system administrator can easily detect and change the behavior of the MSMQs. However, private MSMQs service account are bit tricky and need manual configuration on the local machine.

So, the application reading the MSMQs are configured with service account only can read the messages and everybody else just be denied the access. So, no unknown/unauthorized person can read/write any messages there in the MSMQ.

6.4. Service Accounts & System Users

The context flows from one component to another component in the form of user identity. So, to minimize unknown or anonymous user to do that, our first policy is to name the user who is making the request either synchronously or asynchronous in either from outside of the system or from within the system itself. So, define the user identity which is visible from all the physical server and networks.

Active Directory would be best place to keep the user information. Service accounts are created as domain users a system administrator can enter, modify and drop them. This is the most critical nerve center of all security of this design. So, physical security is must for this kind of environment and must be periodically audited. A system administrator will keep a watch on services accounts, and in case of any defaulter service account, the account is deleted. The service will suspend its execution if it tries to execute any code on behalf of this account. The information is available immediately to all servers in the network, e.g., web servers/app servers/db servers.

6.4.1. NT Users

NT users are nothing but active directory users with limited access to local computers. They are used to run the code on behalf of actual actor/user. Service accounts are defined with limited service rights to execute the database operation. No user of these service account categories should have administrative privilege or login privileges. With this policy, the user code does not do many things itself to reduce the risk.

6.4.2. Database users

NT users are also valid DB users if logins are created in Database Servers. Some of the service accounts can access database for read/write operations. These logins are created and maintained in SQL databases. This can greatly help to restrict SQL injection. However, in some scenarios, we do not need a user to be trusted user. So, as an exception, a SQL user can be created in SQL server, so can be strictly used in restricted manner when no security threats are expected.

7. Separation of Context

To achieve high degree of security on distributed application which is over multiple domains, several web servers, application servers, and database servers, the system needs careful planning of vulnerable resources and threat assessment. The key resources are listed and specific users are identified who can access those resources. Even though a hacker can place a piece of code on the server by some unfair means, still the code will not be to do much because of unknown security restriction. There are several access matrixes which are applied on the architecture to ensure no unauthorized user executes his code on the systems. The Matrix contains operation name, user name and access rights. The matrixes are to be prepared in line with functional domain so that transition among actual system user becomes smooth. There are few of matrixes used in solution placed here. They are self-describing.

1. Application vs. Operation Resource Matrix
2. Application vs. System Resource Matrix
3. Service Account vs. System Services
4. Service Account vs. Low Level System Resource Access
5. Service Account vs. Database Access

Example of Application vs. Operation Resource Matrix

SL	Name of the Operation	Content Users
		Writer	Reviewer	Publisher	Reader	Troubleshooter
1	Add Content	Yes	No	No	No	No
2	Review Content	Yes	Yes	No	No	No
3	Publish Content	No	No	Yes	No	Yes
4	View Content	Yes	Yes	Yes	Yes	Yes

Example of Application vs. System Resource Matrix

SL	Name of the Operation	Users
		svc_web1	Svc_db1	Svc_quque1	DBA	Administrator
1	Run a Service	Yes	No	Yes	No	Yes
2	Logon on a Terminal	No	Yes	No	No	Yes
3	Read/Write to Disk	No	No	Yes	No	Yes
4	Send a Mail	No	Yes	Yes	No	Yes
5	Write a MSMQ	Yes	No	Yes	No	Yes
6	Access Database	No	Yes	No	Yes	No

Example of Service Account vs. System Services

SL	Name of the Service	Users
		svc_web1	Svc_db1	Svc_quque1	DBA	Administrator
1	Website (http://www.serverdomain/)	Yes	No	No	No	No
2	ContentServerHandler Service(WCF) No	Yes	Yes	No	No
3	ContentComponent (COM+)	No	No	Yes	No	No
4	Mail Component	No	Yes	Yes	No	No
6	Database Service	No	No	No	No	Yes

Example of Service Account vs. Low Level System Resource Access

SL	Name of Low Level System Resource	System Users
		svc_web1	Svc_db1	Svc_quque1	DBA	Administrator
1	Disk IO	Read	Read/write to specific folder	Read/write to specific folder	No	Yes
2	System Registry	No	Yes	Yes	No	Yes
3	Event Viewer	No	Yes	Yes	No	Yes
4	Remote Login	No	No	No	No	Yes
5	Log on as A Service	No	Yes	Yes	No	Yes
6	Log on as Batch	Yes	Yes	Yes	No	No

Example of Service Account vs. Database Access

SL	Name of the Database	Database Users
		svc_web1	Svc_db1	Svc_quque1	DBA	Administrator
1	Login to DB Server	No	Yes	No	Yes	No
2	Execute Stored Procedure	No	Provide SP Name	No	Yes	No
3	db_owner	No	No	No	Yes	No
4	Database Reader	No	Provide table name	No	Yes	No
5	Database Writer	No	No	No	Yes	No
6	Sys_admin	No	No	No	No	No

This matrix will be the basis one and can be extended in a given project. Fine tune of the security should not be hindrance to other n-bility of the architectures. However, for optimization and maintenance, these are extended with role management. They are described in next sections.

7.1. Role Management

When the user base grows, they sometimes become unmanageable with their access rights, especially with domain level access. So, a role mapping with user can serve the purpose. The user / role mapping matrix is not a new concept, so I will not discuss it here. However, they can inherit from database point of view, application point of view and OS point of views. Role management can be beneficial to control the access.

7.1.1. Window Authentication or NT Roles

There are some inbuilt groups available in the OS level; they can be used to the scenario. We can add more groups like DiskReaders, DBReaders and add user into these groups. The Services running for a web handler would not access databases at all. The users belong to AD of the target domain of deployment of production environment.

7.1.2. Application roles defined within application domain

Application related roles can be grouped around domain operations like ContentWriter, ContentPublisher, WebSiteUser, FeedbackProviders, etc. Configure server applications to run using least privileged accounts. For services, Roles are either implemented with AzMan providers or at Enterprise level by enabling COM+ role-based security, and enforce component-level access checks. To secure the traffic passed to remote serviced components, use IPSec encrypted channels or use remote procedure call (RPC) encryption. Restrict the range of ports that Distributed COM (DCOM) dynamically allocates or use static endpoint mapping to limit the port range to specific ports.

7.1.3. Database roles

There are some inbuilt roles available in the database level like db_owner, db_datareader, db_datawriter, etc. These roles can be used for the scenario or can be extended by application roles where a user can do some reads and cannot perform some writes. These can be inherited from Application roles as well and then can be extended. Like ContentWriter cannot execute publish sorted procedure, FeedbackProviders can read execute Read stored procedure. The grouping of all StoredProcedure and mapping between roles are prepared in advance while designing the system.

7.2. Access Control List Optimization

Edit access control list of OS resources with role and service account to allow certain number of permissions. These can reduce and impact large number security attack on the system and eliminate the attack. For example: SQL injection. They are inevitable even if there are rigorous amounts of UI validations. So, service account access control list can restrict access to component level task and DB level operations.

7.2.1. File System Resource & Share folders

Write least privileged code, regardless of the account used to run the code. Use code access security to constrain the resources and operations that your code is allowed to access, either by configuring policy or how you write your code You can use code access security to constrain an assembly’s ability to access areas of the file system and perform file I/O.

7.2.2. Network resources & Ports

User profile can easily restrict network resources & proxy fire walls. The domain boundary will ensure the security so that appropriate user can get an access to the system. Cross domain access is restricted and only known users can be allowed to read/write remote systems. Use Internet Protocol Security (IPSec) or SSL to secure the communication channel between the Web server and the application server, and between the application server and the database server. Restrict the range of ports with which clients can connect to the application server, and consider using IPSec restrictions to limit the range of clients.

7.2.3. System Registry

System registries are only writable by local user, so application running on domain user would not be able to read write and system registry values. So, careful planning of accounts and registry node to be accessed matrix would give fine grain access to the system.

7.2.4. Active Directories

Active Directory is managed by system administrator, so not facing to internet. However, a physical security has been in place and company policy would be strong enough to audit its working. All these service accounts, servers, networks, MSMQs must belong to this directory. Resources outside of these directories would not be allowed to execute anything on the physical servers.

7.2.5. MSMQ & other OS Resources

MQMQ and other resources used in the system should be registered in Active Directory. However, if there is a private MSMQs, the domain users must be added to its access control list and anonymous & everyone access must be removed.

7.2.6. Logs & Audits

Logs are Audits are kept highly encrypted and secured all the time. The frequent audits are to be done to ensure proper security policy is never compromised.

8. Beyond Service Account Framework

The paper does not conclude any significant usage unless we have some third party assurance and testing. For writing code, it is just a code review tool that can certify if any security exceptions is reported. No amount of code review can eliminate fully vulnerability of code, deployment, hosting and maintenance. You can restrict what code can do regardless of the account used to run the code. You can use code access security to constrain the resources and operations that your code is allowed to access, either by configuring policy or how you write your code. If your code does not need to access a resource or perform a sensitive operation such as calling unmanaged code, you can use declarative security attributes to ensure that your code cannot be granted this permission by an administrator.

The building up of trust and high level of work ethics can minimize the security threats. The physical securities, Anonymization of database are major concern of data security, and thus can dangerous if not handled properly. More importance is given to Session Management, Cryptography, Parameter Manipulation, Exception Management in such a way that no domain or application related information is presented to anonymous user. A testing tool is always preferable to run a test. HP-Web Inspect can do a great job to identify the security holes in the systems. No amount of security constraint proved sufficient so far, still we hope to stop all the loop holes on the applications. I have covered most of the areas where threats might land onto. However, if any unfair element finds a place his/her code to execute his program inside any place of this architecture; I would like to seal those. So, any assessment is welcome.

9. Conclusion

This is robust security framework applied to the enterprise level system. The optimizations have to be taken care of to ensure that there is no degradation of application performance. If any risk is taken in favor of performance, these must be audited & logged periodically and discussed in maintenance meetings.