Web Application Security Design Inspection Questions - Authentication

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan


Contents

Authentication Vulnerabilities

Vulnerability

Implications

Weak passwords

The risk of password cracking and dictionary attacks increase.

Clear text credentials in configuration files

Insiders who can access the server or attackers who exploit a host vulnerability to download the configuration file have immediate access to credentials.

Passing clear text credentials over the network

Attackers can monitor the network to steal authentication credentials and spoof identity.

Over-privileged accounts

The risks associated with a process or account compromise increase.

Long sessions

The risks associated with session hijacking increase.

Mixing personalization with authentication

Personalization data is suited to persistent cookies. Authentication cookies should not be persisted.


Examine how your application authenticates its callers, where it uses authentication, and how it ensures that credentials remain secure while in storage and when passed over the network. Vulnerabilities in authentication can make your application susceptible to spoofing attacks, dictionary attacks, session hijacking, and other attacks.


Review the following questions to identify potential vulnerabilities in the way your application performs authentication:

  • Do you separate public and restricted access?
  • Have you identified service account requirements?
  • How do you authenticate the caller?
  • How do you authenticate with the database?
  • Do you enforce strong account management practices?

Do you separate public and restricted access?

If your application provides public areas that do not require authentication and restricted areas that do require authentication, examine how your site design distinguishes between the two. You should use separate subfolders for restricted pages and resources and then secure those folders in Internet Information Services (IIS) by configuring them to require SSL. This approach allows you to provide security for sensitive data and authentication cookies using SSL in only those areas of your site that need it. You avoid the added performance hit associated with SSL across the whole site


Have you identified service account requirements?

Your design should identify the range of service accounts that is required to connect to different resources, including databases, directory services, and other types of remote network resources. Make sure that the design does not require a single, highly privileged account with sufficient privileges to connect to the range of different resource types.

  • Does the design require least privileged accounts?

Have you identified which resources and operations require which privileges? Check that the design identifies precisely which privileges each account requires to perform its specific function and use least privileged accounts in all cases.

  • Does the application need to maintain service account credentials?

If so make sure that the credentials are encrypted and held in a restricted location, such as a registry key with a restricted access control list (ACL).


How do you authenticate the caller?

Review the following aspects of authenticating a caller. The aspects you use depend on the type of authentication your design uses.

  • Do you pass clear text credentials over the wire?

If you use Forms or Basic authentication, or if you use Web services and pass credentials in SOAP headers, make sure that you use SSL to protect the credentials in transit.

  • Do you implement your own user store?

If so, check where and how the user credentials will be stored. A common mistake is to store plaintext or encrypted passwords in the user store. Instead, you should store a hash value of the password and a random salt for verification.

If you validate credentials against a SQL Server user store, pay close attention to the input user names and passwords. Check for the malicious injection of SQL characters.

  • Do you use Forms authentication?

If so, in addition to using SSL to protect the credentials, you should use SSL to protect the authentication cookie. Also check that your design uses a limited session lifetime to counter the threat of cookie replay attacks and check that the cookie is encrypted and tamper-proof.


How do you authenticate with the database?

When your application connects to the database, examine what authentication mechanism you will use, what account or accounts you plan to use, and how you plan to authorize the application in the database.

The following questions help review your approach to database authentication:

  • Do you use SQL authentication?

Ideally, your design should use Windows authentication to connect to SQL Server because this is an inherently more secure approach. If you use SQL authentication, examine how you plan to secure credentials over the network and in database connection strings.

If your network infrastructure does not provide IPSec encrypted channels, make sure a server certificate is installed on the database to provide automatic SQL credential encryption. Also examine how you plan to secure database connection strings because these strings contain SQL account user names and passwords.

  • Do you use the process account?

If you use the process account of the application and connect to SQL Server using Windows authentication, make sure that your design assumes a least privileged account. The local ASPNET account is provided for this purpose, although with local accounts, you need to create a duplicate account on the database server.

Note If you are running ASP.NET with IIS 6.0 on Windows Server 2003 in process isolation mode, the default process identity account is identified in the network as DomainName\MachineName$, You can use this identity to provide access to the database while using Windows authentication.

If you plan to use a domain account, make sure that it is a least privileged account and check that all intervening firewalls support Windows authentication by opening the relevant ports.

  • Do you use service accounts?

If your design requires multiple identities to support more granular authorization in the database, examine how you plan to store the account credentials (ideally they are encrypted using the Data Protection API (DPAPI) and held in a secured registry key) and how you are going to use the service identity.

Note If you are running ASP.NET 2.0 on Microsoft Windows Serverâ„¢ 2003 and are using the Win32 LogonUser API for creating thread-level impersonation tokens, you do not need to grant the "Act as part of operating system" privilege to the Web server process identity.

However, if you are using protocol transition to access local resources, you still need to grant the "Act as part of operating system" privilege to the Web server process identify. For more information, see How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0.

Also examine which process will be used to create the impersonated security context using the service account. This should not be done by the ASP.NET application process on Microsoft Windows 2000 because it forces you to increase the privileges of the process account and grant the "Act as part of the operation system" privilege. This should be avoided because it significantly increases the risk factor.

  • Have you considered using the anonymous Internet user identity?

For applications that use Forms or Passport authentication, you can configure a separate anonymous user account for each application. Next, you can enable impersonation and then use the anonymous identity to access the database. This approach accommodates separate authorization and identity tracking for separate applications on the same Web server.

  • Do you use the original user identity?

If your design requires impersonation of the original caller, you need to consider whether or not the approach provides sufficient scalability because connection pooling is ineffective. An alternative approach is to flow the identity of the original caller at the application level through trusted query parameters.

  • How do you store database connection strings?

If database connection strings are hard coded or stored in clear text in configuration files or the COM+ catalog, it makes them vulnerable. Instead, you should encrypt them and restrict access to the encrypted data.



Do you enforce strong account management practices?

The use of strong passwords, restricted login attempts, and other best practice account management policies can be enforced by Windows security policy if your application uses Windows authentication. Otherwise, the application layer is responsible for this. Review the following aspects of the account management of your application:

  • Does your application enforce strong passwords?

For example, do your ASP.NET Web pages use regular expressions to verify password complexity rules?

Note If you are using the Membership feature of ASP.NET 2.0, you can configure the providers to enforce strong passwords. For more information, see "How To: Protect Forms Authentication in ASP.NET 2.0".

  • Do you restrict the number of failed login attempts?

Doing so can help counter the threat of dictionary attacks.

  • Do you reveal too much information in the event of failure?

Make sure you do not display messages such as "Incorrect password" because this tells malicious users that the user name is correct. This allows them to focus their efforts on cracking passwords.

  • Do you enforce a periodic change of passwords?

This is recommended because otherwise there is a high probability that a user will not change his or her password, which makes it more vulnerable.

  • Can you quickly disable accounts in the event of compromise?

If an account is compromised, can you easily disable the account to prevent the attacker from continuing to use the account?

  • Does your application record login attempts?

Recording failed login attempts is an effective way to detect an attacker who is attempting to break in.

Personal tools