Hi All,

Security is one of the primary concerns for both developers and application architects. As there are lots of different types of website with varying security needs, the developers need to know how the security works and choose the appropriate security model for different applications. Some websites collect no information from the users and publish the information that is available widely such as search engine. Meanwhile, there are other sites that may need to collect sensitive information from their users (e.g. credit card numbers and other personal information). These websites need much stronger security implementation to avoid malicious attacks from external entities.

We can share our authentication based issues , questions, tips & tricks.... in this thread...


thnx...

Hi,

If you are designing a server application, your design specification should contain a section that addresses security issues. You should consider and possibly address the following items in the application's functional specification:

Security goals. Understand what you are securing and make sure that you can describe it.
Security risks. Understand your application's vulnerabilities. You must also understand the significance of potential threats as they relate to your business.
Authentication. This is the process of accepting credentials from a user and validating those credentials against a designated authority. The user's (or potentially an application's or computer's) identity is referred to as a security principal. The client must provide credentials to allow the server to verify the identity of the principal. After the identity is known, the application can authorize the principal to access resources on the system. Various criteria, which help you choose the appropriate authentication mechanism, are presented in the next section of this document.
Authorization. This is the process of determining whether the proven identity is allowed to access a specific resource.
Securing data transmission. By encrypting your data as it crosses the network, you can ensure that it cannot be viewed or tampered with while in transit. You must consider the degree to which your data needs to be secured while in transit.
Impersonation. This mechanism allows a server process to run using the security credentials of the client. When the server is impersonating the client, any operations performed by the server are performed using the client's credentials. Impersonation does not allow the server to access remote resources on behalf of the client. This requires delegation.
Delegation. Like impersonation, delegation allows a server process to run using the security credentials of the client. However, delegation is more powerful and allows the server process to make calls to other computers while acting as the client.
Operating system security. This refers to the establishment of appropriate Access Control Lists (ACLs), and network security to prevent intruders from accessing secured resources. You must set the appropriate ACLs on the appropriate resources to allow access by only the relevant principals.
Securing physical access. This refers to locating your server computer in a secure room. You should not overlook this fundamental issue.
Code access security. This allows code to be trusted to varying degrees depending upon where it has come from and from other aspects of the code's identity. You should be aware of how to create your own access permissions.


thnx...

hi deeban,

Relationship Between IIS and ASP.NET

You should understand the relationship between Internet Information Services (IIS) authentication and the Microsoft® ASP.NET security architecture when designing your application. This will allow you to authenticate your users appropriately and obtain the correct security context within your application. You should note that ASP.NET application security configuration and IIS security configuration are completely independent and can be used independently or in conjunction with each other.

IIS maintains security related configuration settings in the IIS metabase. However, ASP.NET maintains security (and other) configuration settings in XML configuration files. While this generally simplifies the deployment of your application from a security standpoint, the security model adopted by your application will necessitate the correct configuration of both the IIS metabase and your ASP.NET application via its configuration file (Web.config).


thnx...

Hi Ramesh,

ASP.NET Authentication Providers and IIS Security:

I heard some information about types of authentication.

ASP.NET implements authentication using authentication providers, which are code modules that verify credentials and implement other security functionality such as cookie generation. ASP.NET supports the following three authentication providers:

Forms Authentication. Using this provider causes unauthenticated requests to be redirected to a specified HTML form using client side redirection. The user can then supply logon credentials, and post the form back to the server. If the application authenticates the request (using application-specific logic), ASP.NET issues a cookie that contains the credentials or a key for reacquiring the client identity. Subsequent requests are issued with the cookie in the request headers, which means that subsequent authentications are unnecessary.
Passport Authentication. This is a centralized authentication service provided by Microsoft that offers a single logon facility and membership services for participating sites. ASP.NET, in conjunction with the Microsoft® Passport software development kit (SDK), provides similar functionality as Forms Authentication to Passport users.
Windows Authentication. This provider utilizes the authentication capabilities of IIS. After IIS completes its authentication, ASP.NET uses the authenticated identity's token to authorize access.
To enable a specified authentication provider for an ASP.NET application, you must create an entry in the application's configuration file as follows:

Copy Code
// web.config file
<authentication mode = "[Windows/Forms/Passport/None]">
</authentication>

In addition to authentication, ASP.NET provides an impersonation mechanism to establish the application thread's security token. Obtaining the correct token relies upon you configuring IIS authentication, ASP.NET authentication providers, and ASP.NET impersonation settings appropriately.

cheers...

Hi friends,

If you plan to authenticate users using accounts maintained by a Microsoft Windows NT® domain controller or within Microsoft Windows® 2000 Active Directory™, you should use IIS Authentication coupled with the Windows Provider for ASP.NET, as illustrated in Figure 2. By using this approach, you do not need to write any specific authentication code. When authentication happens using this method, ASP.NET constructs and attaches a Windows Principal object to the application context based on the authenticated user. As a result, the ASP.NET thread can run as the authenticated user and can obtain the user's group membership.

In some cases, you may want to bypass IIS authentication and implement a custom solution. This is also possible with ASP.NET. For example, you can write a custom ISAPI filter that checks the user's credentials against Active Directory and the creation of the Windows Principal object would be performed manually. There are other methods besides this one that will work, but they all require more code than using the .NET provider directly.


cheers...

__________________
J.Saravanan

Hi All,

Authentication using non-Windows accounts

If you are planning to authenticate users at the application level, and the users do not have Windows accounts, you will typically configure IIS to use Anonymous authentication. In this configuration, consider the following .NET authentication modules:

None: Use when you are not authenticating users at all, or developing custom authentication code.
Forms: Use when you want to provide users with a logon page.
Passport: Use when you are using Passport services.


cheers....

Hi all...

Impersonation and delegation

With impersonation, ASP.NET applications can optionally execute with the identity of the client on whose behalf they're operating. Impersonation is usually performed for resource access control. You should carefully consider whether or not impersonation is required, as it consumes additional server resources. Delegation is a more powerful form of impersonation and allows remote resources to be accessed by the server process while acting as the client.

If impersonation is enabled, ASP.NET will receive the token to impersonate from IIS. You have more granular control of impersonation in a Web application when using ASP.NET in comparison to traditional Active Server Pages (ASP). This is controlled by specifying a value in the application's Web.config file.

You have the following three options when specifying the required impersonation setting:

Impersonation enabled. In this instance, ASP.NET will impersonate the token passed to it by IIS, which will either be an authenticated user or the anonymous Internet user account.

<identity impersonate="true"/>

Impersonation enabled, with a specific impersonation identity specified. In this instance, ASP.NET will impersonate the token generated using the configured identity. In this case the client token, if applicable, is not used.

<identity impersonate="true" name="domain\user" password="pwd"/>

Impersonation is disabled. This is the default setting for backward compatibility with ASP. In this instance, the ASP.NET thread will run using the process token of the application worker process, which by default is the IIS system account, regardless of which combination of IIS and ASP.NET authentication have been used.

<identity impersonate="false"/>

If the application resides on a UNC share, ASP.NET will always impersonate the IIS UNC token to access that share unless a configured account is used. If an explicitly configured account is provided, ASP.NET will use that account in preference to the IIS UNC token.

thnx...

Hi Deeban,

looks good Can you explain impersonation little more, with an example.


cheers...

Hi Sundaram,

Impersonation is one of the most useful mechanisms in Windows security. It's also fragile and easy to misuse. Careful use of impersonation can lead to a secure, easy-to-administer application. Misuse can open gaping security holes.

After an application authenticates a user, the application can take on that user's identity through impersonation. Impersonation happens on a thread-by-thread basis to allow for concurrency, which is important for multithreaded servers as each thread might be servicing a different client. In Figure 31.1, the server process is configured to run as Bob. It contains five threads, two of which are impersonating in order to do work on behalf of authenticated clients.



In this scenario, if one of the three normal threads tries to open a file (or any other secure kernel object), the operating system makes its access-checking and auditing decisions by looking at the process token. If Bob has the requisite access, the call will succeed and any audits will show that Bob opened the file. On the other hand, if the thread impersonating Alice tries to open the same file, the operating system makes its access-check decision based on Alice's token, not Bob's, so Alice, not Bob needs to be granted access to the file in this case. As for auditing, the operating system cares about both identities and will record that Bob was impersonating Alice when the file was opened. Of course, auditing must be enabled for any audits to be generated at all (Item 10)!

It may seem surprising that Bob can impersonate his client and actually become more privileged than before. This (and the reverse) is true. Bob might have very little privilege and have access to very few resources on his own, but think about the benefits of this model. If the server process is somehow hijacked by a bad guy, perhaps via a buffer overflow (Item 1), the bad guy won't immediately obtain access to lots of valuable resources. Instead, he'll immediately be able to use only the few piddly resources that Bob can access. Either he'll have to exploit another hole in the system to elevate privileges or he'll have to wait around until a client connects and use the client's credentials to access those resources (via impersonation!). And unless the client is highly privileged, the bad guy won't immediately have access to all the resources but rather only to the ones that that client can access. This can slow down an attack, giving your detection countermeasures (Item 2) time to kick in and allowing you to react and cut off the attack.

Imagine the opposite scenario, where the server runs as SYSTEM and impersonates incoming clients. If the server process is hijacked, it's pretty much over as far as any local resources go. And you should be aware that impersonating a low-privileged account, even the null session (Item 35), won't stop an attacker from simply removing the impersonation token by calling the Win32 function RevertToSelf before doing his evil deeds. This call requires no special privileges and no arguments. It simply removes the impersonation token from the thread, reverting the thread back to the process's identity.

You see, in the first scenario there's a trust boundary between the server process and the resources it's accessing. The resources won't accept Bob's credentials but rather want proof that an authorized client has connected. There's also a trust boundary between the server process and the operating system. There's none in the second scenario! These trust boundaries become even more important when impersonation turns into delegation (Item 62).

None of this is perfect. Even when Bob is untrusted, he can still do bad things. He can collect client tokens (Item 16), which never time out and so effectively elevate the overall privilege level of his process over time. When Alice connects and asks to read resource A, Bob can instead choose to misuse her credentials and write to resource B. But don't let that dissuade you from running your servers with least privilege (Item 4). Security is a balancing act, and least privilege usually gives the defender an advantage.


thnx..

Hi Deeban,

You are advised to run the ASP.NET application worker process (aspnet_wp.exe) using a specifically configured account, with weaker privileges than the default System account. This is for two main reasons. Firstly, if security is breached, the intruder does not have administrative access. Secondly, it allows Application Service Providers (ASPs) to run applications using weaker accounts, so hosted applications cannot compromise the integrity of the server computer or perform actions that require administrative privileges.

To run the ASP worker process using a specified account, add a <processModel> element to the root configuration file (machine.config), located in the \WINNT\Microsoft.NET\Framework\Version\Config folder, as shown below:

<system.web>
<processModel enable="true" username="domain\user" password="pwd"/>
</system.web>

In addition to specifying a particular user account, you can also set the username attribute to one of two specially recognized values, "SYSTEM" and "MACHINE". In both cases, the password attribute must be set to "AutoGenerate", as specific credentials are not required. The "SYSTEM" setting runs the worker process using the System account, while "MACHINE" (which is the default) causes the worker process to run with a special account named with an ASPNET prefix. This account is similar to the IWAM_MACHINENAME account, used by IIS for running instances of dllhost.exe when hosting regular ASP applications. The ASPNET account is created during .NET installation.

If you use a custom account, that account must have the necessary access rights to the following directories.

Read/write access is required to the %installroot%\ASP.NET Temporary Files directory. Sub-directories beneath this root are used for dynamically compiled output.
Read/write access is required to the %temp% directory. This is used by the compilers during dynamic compilation.
Read access is required to the application directory.
Read access is required to the %installroot% hierarchy to allow access to system assemblies.
Note that the relevant ACEs are defined during the installation process for the ASPNET account.

If you use a specifically configured process account, you should be aware of a restriction that this places on the use of impersonation. While you can still impersonate the identity of the client, you can't use the extended form of impersonation where a specified impersonation account is defined within the application's Web.config file. This is because this option requires that the worker process has the SE_TCB_NAME ("Act as part of the operating system") privilege, which the weaker process identity generally won't have. Per request impersonation still works, because IIS creates the logon session and passes the impersonation token directly to the worker process. Note that this restriction only applies to Windows 2000 and Windows NT 4. Microsoft Windows XP contains enhancements that allow specific logon sessions to be generated without requiring this privilege.


cheers...