Top 10 Security Vulnerabilities in .NET Configuration Files : Page 4
Developers often concentrate on writing secure code but leave security vulnerabilities in application configuration files. Discover the most common configuration security problemsand how to avoid them.
by Bryan Sullivan
Sep 19, 2006
Page 4 of 5
6. Cookieless Authentication Enabled
Just as in the "Cookieless Session State Enabled" vulnerability discussed above, enabling cookieless authentication in your application can lead to session hijacking.
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 easily take over that session and effectively impersonate a legitimate user. However, session hijacking has far more serious consequences after a user has been authenticated. For example, online shopping sites generally allow users to browse without having to provide an ID and password. But when users are ready to make purchases, or when they want to view their orders, 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 a 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.
7. Failure to Require SSL for Authentication Cookies
Web applications use the Secure Sockets Layer (SSL) protocol to encrypt data passed between the Web server and the client. Using SSL means that attackers using network sniffers will not be able to interpret the exchanged data. Rather than seeing plaintext requests and responses, they will see only an indecipherable jumble of meaningless characters.
You can require your forms to use SSL by setting the requireSSL attribute of the <forms> element to true.
The previous section discussed the importance of transmitting the authentication token in a cookie, rather than embedding it in the request URL. However, disabling cookieless authentication is just the first step towards securing the authentication token. Unless requests made to the Web server are encrypted, a network sniffer will still be able to read the authentication token from the request cookie. An attacker would still be able to hijack the user's session.
At this point, you might be wondering why it is necessary to disable cookieless authentication, since it is very inconvenient for users who won't accept cookies, and seeing as how the request still has to be sent over SSL. The answer is that the request URL is often persisted regardless of whether or not it was sent via SSL. Most major browsers save the complete URL in the browser history cache. If the history cache were to be compromised, the user's login credentials would be as well. Therefore, to truly secure the authentication token, you must require the authentication token to be stored in a cookie, and use SSL to ensure that the cookie be transmitted securely.
By setting the requireSSL attribute of the <forms> element to true, the ASP.NET application will use a secure connection when transmitting the authentication cookie to the Web server. Note that IIS requires additional configuration steps to support SSL. You can find instructions to configure SSL for IIS on MSDN.
8. Sliding Expiration Used
All authenticated ASP.NET sessions have a timeout interval. The default timeout value is 30 minutes. After 30 minutes of inactivity, the user will automatically be timed out and forced to re-authenticate his credentials
The slidingExpiration setting is a security measure used to reduce risk in case the authentication token is stolen. When set to false, the specified timeout interval becomes a fixed period of time from the initial login, rather than a period of inactivity. Attackers using a stolen authentication token have, at maximum, only the specified length of time to impersonate the user before the session times out. Because typical attackers have only the token, and don't really know the user's credentials, they can't log back in as the legitimate user, so the stolen authentication token is now useless and the threat is mitigated. When sliding expiration is enabled, as long as an attacker makes at least one request to the system every 15 minutes (or half of the timeout interval), the session will remain open indefinitely. This gives attackers more opportunities to steal information and cause other mischief.
To avoid this altogether, you can disable sliding expiration by setting the slidingExpiration attribute of the <forms> element to false.