This link has been bookmarked by 2 people . It was first bookmarked on 03 May 2007, by Wisely.
-
21 Nov 07
-
Security Vulnerabilities
-
-
03 May 07
-
These days, the biggest threat to an organization’s network security comes from its public
Web site and the Web-based applications found there
-
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.
That's often acceptable, given the alternative—that users who deny cookies wouldn't be
able to use the application at all. It is ironic that many users disable cookies because of
privacy concerns when doing so can actually make them more prone to attack.
-
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? Do you have to choose between making
your application available to all users versus ensuring that it operates securely for all
users? A compromise between the two is possible in ASP.NET 2.0. By setting the
-
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
-
Like the first two application security vulnerabilities described in this list, leaving
debugging enabled is dangerous because you are providing inside information to end
users who shouldn’t have access to it, and who may use it to attack your Web-based
applications. For example, if you have enabled debugging and disabled custom errors in
your application, then any error message displayed to an end user of your Web-based
applications 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.
-
. Custom Errors Disabled
-
2. Leaving Tracing Enabled in Web-Based Applications
-
3. Debugging Enabled
-
Deploying Web-based applications in debug mode is a very common mistake.
-
4. Cookies Accessible through Client-Side Script
-
5. Cookieless Session State Enabled
-
Page Comments
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.