DataReader and Dataset

In one of the project that I was working on there was a Time Out exception happened while navigating through lot of records. It was causing the whole application to crash. While examinig the application closely and running the sql profiler and using the below query to get all the processes that are active or getting created.

Query Analyzer:

EXEC SP_WHO2

SELECT [sql_handle],stmt_start,stmt_end,loginame,[program_name],hostname,* FROM MASTER..SYSPROCESSES WHERE [program_name]='.Net SqlClient Data Provider' ORDER BY SPID DESC

SELECT * FROM MASTER..SYSDATABASES
SYSDATABASES will give the database name that is being used.

SQL Profiler:

In the Sql profiler we can examine for which database and for what processes the queries are executed.

***********************************************************************************

While closely examining the code I found out that the datareader was cauing the issue. And also I noticed that the sp_reset_connection Stored procedure was not getting called after the datareader performed its operation.
Changing this to dataset really resolved the issue and unnecessary connection was not getting opened and also sp_reset_connection was getting called.

Bin Scope Binary Analyzer: Mini Fuzz Tool

Bin Scope Binary Analyzer:

The BinScope Binary Analyzer is a Microsoft verification tool that analyzes binaries to ensure that they have been built in compliance with Microsoft’s Security Development Lifecycle (SDL) requirements and recommendations. BinScope checks that SDL-required compiler/linker flags are being set, strong-named assemblies are in use, and up-to-date build tools are in place. BinScope also reports on dangerous constructs that are prohibited or discouraged by the SDL (e.g. read/write shared sections and global function pointers).
This below article has a small demonstration video.

http://blogs.technet.com/security/

It can be run standalone or integrated with the VS IDE.

Download:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=90e6181c-5905-4799-826a-772eafd4440a


Mini File Fuzzer:


A testing technique that can help find denial of service and security vulnerabilities in software.

Technique:
1. Force application to malformed data.
2. If crash occurs, identify where and how.
3. File a security bug.
4. Investigate underlying code for security risk.

This below article has a small demonstration video.
http://blogs.technet.com/security/

Download
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b2307ca4-638f-4641-9946-dc0a5abe8513

Protecting Web.Config file

Sensitive information should not be kept as clear text. At times we need to store sensitive information into web.config file. We store the database connection string in unencrypted format also. Some of the vulnerability in doing so..

1. Client changes things they shouldn't change in the web.config file.

2. An employee of your ISP can read your sensitive data when your site is hosted in a shared hosting environment

Since Web.config may contain sensitive data such as connection strings, it is important that the contents of Web.config be kept safe and hidden from unauthorized viewers. By default, any HTTP request to a file with the .config extension is handled by the ASP.NET engine, which returns the “This type of page is not served” message.

But what if an attacker is able to find some other exploit that allows them to view the Web.config file’s contents? What could an attacker do with this information, and what steps can be taken to further protect the sensitive information within Web.config? Fortunately, most sections in Web.config do not contain sensitive information. What harm can an attacker perpetrate if they know the name of the default Theme used by your ASP.NET pages?
Certain Web.config sections, however, contain sensitive information that may include connection strings, user names, passwords, server names, encryption keys, and so forth. This information is typically found in the following Web.config sections:
• appSettings
• connectionStrings
• identity
• sessionState
Refer the following link to read more on this article by.. Scott Mitchell

http://www.asp.net/Learn/data-access/tutorial-73-cs.aspx

Form Authentication and Session State

Form Authentication and Session State

Form Authentication with default configuration is next to impossible to create a forged forms authentication ticket. The problem with depending on session state as an indicator of a logon session is that unlike forms authentication, it is trivial to create a valid session identifier.
A session identifier is nothing more than a 120-bit random number encoded using letters and numbers (this works out to a 24-character cookie value due to the way session state encodes the random number), there is a chance that we can easily create a perfectly valid session identifier. Of course, if we send such an identifier to Asp.NET, there probably isn’t going to be any session data associated with it. (We have 2^120 possible combinations to guess if you were actually trying to grab someone else’s session).
The configuration options for session state, unlike forms authentication, don’t include options for setting a cookie domain or a cookie path.
Another flaw of using session state for tracking logon status is the inability to set the secure property of the session state cookie. Unlike forms authentication, the session state cookie always flows across the network regardless of the state of any SSL security on the connection. If we think about it, this makes sense for a feature like session state because many applications break If the data in session randomly became unavailable when a user surfer between secure and insecure pages.
The whole point of a logon session is that it requires authentication to obtain a session, and once established there is persistent association between an authenticated user and the actual session data. Please check the image for a security feature comparison of forms authentication and session state.

The best way to think about session data is to treat session state as if it were data stored in forms variables on a page. Session state acts as a server-side store for this type of information.
Protecting Session Cookies
As with forms authentication in ASP.NET 2.0, the session state feature explicitly sets the HttpOnly property on the cookie to true. Because applications store interesting information inside of session state, ASP.NET protects the session identifier from client-side cross-site scripting(XSS) attacks.
The likelihood of an attacker ever guessing a live session cookie is astronomically low (with 120 bits in the session identifier, that works out to an average of 2^60 guesses required.
HttpOnly property prevents cookie hijacking.
Why SessionID is not encrypted like forms authentication ticket ?
The default session state cookie is a cryptographically strong 120-bit random number, there didn’t seem to be much point in layering the overhead of encryption and signing on top of it. Furthermore, not only is the session identifier a strong random number, because the session state identifier is stored in a session based cookie, the session ID changes from browser session to browser session.
With session state the only time we can really someone else’s session state is while that user’s session is still active. There is no such thing as an offline brute force decryption attack or hash collision attack with session state. With session state, an attacker must successfully guess (incredibly unlikely) or hijack (possible but difficult to accomplish) a session identifier while that session is still active somewhere in an application. Although an attacker could theoretically stumble across a session identifier associated with an expired session, this isn’t of any use because an expired session means that the data associated with that session is no longer available.
When you abandon a session, the session ID cookie is not removed from the browser of the user. Therefore, as soon as the session has been abandoned, any new requests to the same application will use the same session ID but will have a new session state instance. At the same time, if the user opens another application within the same DNS domain, the user will not lose their session state after the Abandon method is called from one application.
Sometimes, you may not want to reuse the session ID. If you do and if you understand the ramifications of not reusing the session ID, use the following code example to abandon a session and to clear the session ID cookie:
Session.Abandon();
Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));
This code example clears the session state from the server and sets the session state cookie to null. The null value effectively clears the cookie from the browser.

Reference: Asp.Net security book related to roles, authentication by Stephan Schakow. Its a great book.

Protect Forms Authentication in ASP.NET 2.0

http://msdn.microsoft.com/en-us/library/ms998310.aspx