First thing which comes to mind when one connects to internet is am i secure.....?... Is somebody watching me? .Nobody has an answser to it but all one can do is use best practices to be on a safe edge of the wall. Listed below are some of the security misconfigurations, and demonstrates their potential impact on your applications.
1. Web.Config
Web.config files operate in a hierarchical inheritance manner. All Web.config files on the system inherit from the global configuration file called Machine.config located in the .NET framework directory. The effect of this is that the runtime behavior of your application can be altered simply by modifying a configuration file in a higher directory .
To keep your application-specific settings from being unexpectedly modified, the solution is to never rely on default setting values. For example, debugging is disabled by default in configuration files. If you're examining the configuration file for your application and you notice that the debug attribute is blank, you might assume that debugging is disabled. But it may or may not be disabled—the applied value depends on the value in parent configuration settings on the system. The safest choice is to always explicitly set security-related values in your application's configuration.
1.1 Custom Errors Disabled
When you disable custom errors as shown below, ASP.NET provides a detailed error message to clients by default.
Looking at the error page, an attacker can see that the application is using the .NET framework version and ASP.NET version Knowing that, he can search the Web for known security advisories concerning these specific product versions. The hacker can also determine that the application is using Microsoft SQL Server as its database, because the exception type thrown was a SqlException, which is specific to Microsoft SQL Server. The more information a hacker can gather about a Web site, the more likely it is that he will be able to successfully attack it.
You can prevent such information leakage by modifying the mode attribute of the element to On or RemoteOnly. This setting instructs the Web application to display a nondescript, generic error message when an unhandled exception is generated.
Another way to circumvent the problem is to create your own custom error page and redirect users to that page when errors occur.
1.2 Leaving Tracing Enabled
The trace feature of ASP.NET is one of the most useful tools that you can use to debug and profile your applications. When the element is enabled for remote users (localOnly="false"), any user can view an incredibly detailed list of recent requests to the application simply by browsing to the page trace.axd .
An hacker would find the form variables, request and response and various other useful information; these might include email addresses that could be harvested and sold to spammers, IDs and passwords that could be used to impersonate the user, or credit card and bank account numbers. Even the most innocent-looking piece of data in the trace collection can be dangerous in the wrong hands. For example, the APPL_PHYSICAL_PATH server variable, which contains the physical path of the application on the server, could help an attacker perform directory traversal attacks against the system .
The best way to prevent a hacker from obtaining trace data is to disable the trace viewer completely by setting the enabled attribute of the element to false. If you must have the trace viewer enabled, either to debug or to profile your application, then be sure to set the localOnly attribute of the element to true. This setting allows users to access the trace viewer only from the Web server and disables viewing it from any remote machine.
1.3 Leaving Debugging Enabled
Deploying a Web application in debug mode is a very common mistake. If you have enabled debugging and disabled custom errors in your application, then any error message displayed to an end user will include not only the server information, a detailed exception message, and a stack trace, but also the actual source code of the page where the error occurred .
To disable debugging, set the value of the debug attribute of the element to false. This is the default value of the setting, but as we will see, it's safer to explicitly set the desired value rather than relying on the defaults.
1.4 Cookies Accessible Through Client-Side Script
In Internet Explorer 6.0, Microsoft introduced a new cookie property called HttpOnly. While you can set the property programmatically, you can set it generically in the site configuration.
Message board or forum pages are also often vulnerable to cross site scripting. An attacker, rather than posting about the current topic, will instead post a message such as script code in its page code—and the browser then interprets and executes it for future site visitors. Usually attackers use such script code to try to obtain the user's authentication token (usually stored in a cookie), which they could then use to impersonate the user.
When cookies are marked with the HttpOnly property, their values are hidden from the client, so this attack will fail .
1.5 Cookieless SessionState Enabled
In the initial 1.0 release of ASP.NET, you had no choice about how to transmit the session token between requests when your Web application needed to maintain session state: it was always stored in a cookie. Unfortunately, this meant that users who would not accept cookies could not use your application. So, in ASP.NET 1.1, Microsoft added support for cookieless session tokens via use of the "cookieless" setting.
Web applications configured to use cookieless session state now stored the session token in the page URLs rather than a cookie. For example, the page URL might change from http://mysite/default.aspx to http://mysite/(123456789ABCDEFG)/default.aspx. In this case, 123456789ABCDEFG represents the current user's session token it had the side effect of making those applications much more vulnerable to identity theft whereby using a network monitoring tool (also known as a "sniffer") or by obtaining a recent request log, hijacking the user's session becomes a simple matter of browsing to the URL containing the stolen unique session token and hence impersonates a legitimate user by stealing his session token.
The most effective way to prevent these session hijacking attacks is to force your Web application to use cookies to store the session token. This is accomplished by setting the cookieless attribute of the element to UseCookies or false. But what about the users who do not accept cookies? By setting the cookieless attribute to AutoDetect, the application will store the session token in a cookie for users who accept them and in the URL for those who won't. This means that only the users who use cookieless tokens will still be vulnerable to session hijacking.
1.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.
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.
The best way to prevent session hijacking is to disable cookieless authentication and force the use of cookies for storing authentication tokens. This is done by changing the cookieless attribute of the element to the value UseCookies.
1.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.
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.
By setting the requireSSL attribute of the element to true, the ASP.NET application will use a secure connection when transmitting the authentication cookie to the Web server.
1.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. .
To avoid this altogether, you can disable sliding expiration by setting the slidingExpiration attribute of the element to false.
1.9 Non-Unique Authentication Cookie Used
As strange as it seems, an improperly chosen cookie name can create a security vulnerability just as dangerous as an improperly chosen storage location.
The default value for the name of the authentication cookie is .ASPXAUTH. If you have only one Web application on your server, then .ASPXAUTH is a perfectly secure choice for the cookie name. In fact, any choice would be secure. But, when your server runs more than one ASP.NET application, it becomes critical to assign a unique authentication cookie name to each application. If the names are not unique, then users logging into any of the applications might inadvertently gain access to all of them.
The best way to ensure that each Web application on your server has its own set of authorized users is to change the authentication cookie name to a unique value.
1.10 Hardcoded Credentials Used
A fundamental difficulty of creating software is that the environment in which the application will be deployed is usually not the same environment in which it is created. In a production environment, the operating system may be different, the hardware on which the application runs may be more or less powerful, and test databases are replaced with live databases. This is an issue for creating applications that require authentication because developers and administrators often use test credentials to test the system. The question is: Where do the test credentials come from
For convenience, to avoid forcing developers from spending time on creating a credential store used solely for test purposes (and which would subsequently be discarded when the application went to production), Microsoft added a section to the Web.config file that you can use to quickly add test users to the application. Storing login credentials in plaintext in a configuration file is simply not secure. Anyone with read access to the Web.config file could access the authenticated Web application. It is possible to store the SHA-1 or MD5 hash of the password value, rather than storing the password in plaintext.
The most secure way to store login credentials is to not store them in the configuration file. Remove the element from your Web.config files in production applications.
1. Web.Config
Web.config files operate in a hierarchical inheritance manner. All Web.config files on the system inherit from the global configuration file called Machine.config located in the .NET framework directory. The effect of this is that the runtime behavior of your application can be altered simply by modifying a configuration file in a higher directory .
To keep your application-specific settings from being unexpectedly modified, the solution is to never rely on default setting values. For example, debugging is disabled by default in configuration files. If you're examining the configuration file for your application and you notice that the debug attribute is blank, you might assume that debugging is disabled. But it may or may not be disabled—the applied value depends on the value in parent configuration settings on the system. The safest choice is to always explicitly set security-related values in your application's configuration.
1.1 Custom Errors Disabled
When you disable custom errors as shown below, ASP.NET provides a detailed error message to clients by default.
Looking at the error page, an attacker can see that the application is using the .NET framework version and ASP.NET version Knowing that, he can search the Web for known security advisories concerning these specific product versions. The hacker can also determine that the application is using Microsoft SQL Server as its database, because the exception type thrown was a SqlException, which is specific to Microsoft SQL Server. The more information a hacker can gather about a Web site, the more likely it is that he will be able to successfully attack it.
You can prevent such information leakage by modifying the mode attribute of the element to On or RemoteOnly. This setting instructs the Web application to display a nondescript, generic error message when an unhandled exception is generated.
Another way to circumvent the problem is to create your own custom error page and redirect users to that page when errors occur.
1.2 Leaving Tracing Enabled
The trace feature of ASP.NET is one of the most useful tools that you can use to debug and profile your applications. When the element is enabled for remote users (localOnly="false"), any user can view an incredibly detailed list of recent requests to the application simply by browsing to the page trace.axd .
An hacker would find the form variables, request and response and various other useful information; these might include email addresses that could be harvested and sold to spammers, IDs and passwords that could be used to impersonate the user, or credit card and bank account numbers. Even the most innocent-looking piece of data in the trace collection can be dangerous in the wrong hands. For example, the APPL_PHYSICAL_PATH server variable, which contains the physical path of the application on the server, could help an attacker perform directory traversal attacks against the system .
The best way to prevent a hacker from obtaining trace data is to disable the trace viewer completely by setting the enabled attribute of the element to false. If you must have the trace viewer enabled, either to debug or to profile your application, then be sure to set the localOnly attribute of the element to true. This setting allows users to access the trace viewer only from the Web server and disables viewing it from any remote machine.
1.3 Leaving Debugging Enabled
Deploying a Web application in debug mode is a very common mistake. If you have enabled debugging and disabled custom errors in your application, then any error message displayed to an end user will include not only the server information, a detailed exception message, and a stack trace, but also the actual source code of the page where the error occurred .
To disable debugging, set the value of the debug attribute of the element to false. This is the default value of the setting, but as we will see, it's safer to explicitly set the desired value rather than relying on the defaults.
1.4 Cookies Accessible Through Client-Side Script
In Internet Explorer 6.0, Microsoft introduced a new cookie property called HttpOnly. While you can set the property programmatically, you can set it generically in the site configuration.
Message board or forum pages are also often vulnerable to cross site scripting. An attacker, rather than posting about the current topic, will instead post a message such as script code in its page code—and the browser then interprets and executes it for future site visitors. Usually attackers use such script code to try to obtain the user's authentication token (usually stored in a cookie), which they could then use to impersonate the user.
When cookies are marked with the HttpOnly property, their values are hidden from the client, so this attack will fail .
1.5 Cookieless SessionState Enabled
In the initial 1.0 release of ASP.NET, you had no choice about how to transmit the session token between requests when your Web application needed to maintain session state: it was always stored in a cookie. Unfortunately, this meant that users who would not accept cookies could not use your application. So, in ASP.NET 1.1, Microsoft added support for cookieless session tokens via use of the "cookieless" setting.
Web applications configured to use cookieless session state now stored the session token in the page URLs rather than a cookie. For example, the page URL might change from http://mysite/default.aspx to http://mysite/(123456789ABCDEFG)/default.aspx. In this case, 123456789ABCDEFG represents the current user's session token it had the side effect of making those applications much more vulnerable to identity theft whereby using a network monitoring tool (also known as a "sniffer") or by obtaining a recent request log, hijacking the user's session becomes a simple matter of browsing to the URL containing the stolen unique session token and hence impersonates a legitimate user by stealing his session token.
The most effective way to prevent these session hijacking attacks is to force your Web application to use cookies to store the session token. This is accomplished by setting the cookieless attribute of the element to UseCookies or false. But what about the users who do not accept cookies? By setting the cookieless attribute to AutoDetect, the application will store the session token in a cookie for users who accept them and in the URL for those who won't. This means that only the users who use cookieless tokens will still be vulnerable to session hijacking.
1.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.
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.
The best way to prevent session hijacking is to disable cookieless authentication and force the use of cookies for storing authentication tokens. This is done by changing the cookieless attribute of the element to the value UseCookies.
1.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.
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.
By setting the requireSSL attribute of the element to true, the ASP.NET application will use a secure connection when transmitting the authentication cookie to the Web server.
1.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. .
To avoid this altogether, you can disable sliding expiration by setting the slidingExpiration attribute of the element to false.
1.9 Non-Unique Authentication Cookie Used
As strange as it seems, an improperly chosen cookie name can create a security vulnerability just as dangerous as an improperly chosen storage location.
The default value for the name of the authentication cookie is .ASPXAUTH. If you have only one Web application on your server, then .ASPXAUTH is a perfectly secure choice for the cookie name. In fact, any choice would be secure. But, when your server runs more than one ASP.NET application, it becomes critical to assign a unique authentication cookie name to each application. If the names are not unique, then users logging into any of the applications might inadvertently gain access to all of them.
The best way to ensure that each Web application on your server has its own set of authorized users is to change the authentication cookie name to a unique value.
1.10 Hardcoded Credentials Used
A fundamental difficulty of creating software is that the environment in which the application will be deployed is usually not the same environment in which it is created. In a production environment, the operating system may be different, the hardware on which the application runs may be more or less powerful, and test databases are replaced with live databases. This is an issue for creating applications that require authentication because developers and administrators often use test credentials to test the system. The question is: Where do the test credentials come from
For convenience, to avoid forcing developers from spending time on creating a credential store used solely for test purposes (and which would subsequently be discarded when the application went to production), Microsoft added a section to the Web.config file that you can use to quickly add test users to the application. Storing login credentials in plaintext in a configuration file is simply not secure. Anyone with read access to the Web.config file could access the authenticated Web application. It is possible to store the SHA-1 or MD5 hash of the password value, rather than storing the password in plaintext.
The most secure way to store login credentials is to not store them in the configuration file. Remove the element from your Web.config files in production applications.
Sphere: Related Content
2 comments:
Nice and informational article!!!
This article is an excellent reference source! It reads like documentation for a client server networked corporate systems admin, rather than a home user, yet the information is relevant for home PC's.
Nice grammar and readability too. Was someone a tech writer in the distant past? Hope to see this blog active once again.
Post a Comment