Some of the most common and dangerous application security vulnerabilities that exist in ASP.NET Web-based applications come not from the C# or VB.NET code that make up its pages and service methods, but instead from the XML code that makes up its Web.config files. Incorrect configurations can open Web sites to application security holes such as session hijacking, Cross-Site Scripting attacks, and even allow the disclosure of private data to attackers. 

An additional problem is that Web.config files were designed to be changed at any time, even after the Web-based applications are in production. A well-intentioned system administrator could inadvertently get around application security measures and open the Web site to attack just by modifying the configuration file. And because .NET configuration files operate in a hierarchical manner, a single change to the global Machine.config file could affect every Web site on the entire network.

Part one of this article listed five of the most serious configuration vulnerabilities that are applicable to any ASP.NET Web-based applications. This part will focus on authentication and authorization application security issues, and detail another five vulnerabilities commonly found in ASP.NET Web-based applications using Forms authentication. It will also provide some best practices for application security, including locking down your configuration files to ensure that they are not unintentionally modified by well-meaning (but uninformed) programmers or administrators.

6. Cookieless Authentication Enabled

Just as in the "Cookieless Session State Enabled" vulnerability discussed in part one, enabling cookieless authentication in your Web-based applications can lead to session hijacking and problems with application security.

Vulnerable configuration: <configuration> <system.web> <authentication mode="Forms"> <forms cookieless="UseUri">

Secure configuration: <configuration> <system.web> <authentication mode="Forms"> <forms cookieless="UseCookies">

When a session or authentication token appears in the request URL rather than in a secure cookie, an attacker with a network monitoring tool can get around application security, easily take over that session, and effectively impersonate a legitimate user. However, session hijacking has far more serious consequences for application security after a user has been authenticated. For example, online shopping sites generally utilize Web-based applications that allow users to browse without having to provide an ID and password. But when users are ready to make a purchase, or when they want to view their order status, they have to login and be authenticated by the system. After logging in, sites provide access to more sensitive data, such as a user's order history, billing address, and credit card number. Attackers hijacking this user's session before authentication can't usually obtain much useful information. But if the attacker hijacks the session after authentication, all that sensitive information could be compromised.

The best way to prevent session hijacking with Web-based applications is to disable cookieless authentication and force the use of cookies for storing authentication tokens. This application security measure is added by changing the cookieless attribute of the forms element to the value UseCookies.

Next Page: Failure to Require SSL for Authentication Cookies