ASP.Net Security

Concern	Solution	Windows/.NET Solution
Do we know who you are?	Authentication	Windows (Kerberos/ NTLM) ASP.NET Forms-based security Active Directory IIS Passport
Do we know you have permission to do what you’re doing?	Authorization	Windows role-based security Custom roles in ASP.NET Code access security
Can we get the data to you  in a secure manner?	Encryption	Secure Sockets Layer (SSL) Certificate Server, Encryption library in the Framework class library
Can we recover from an attack?		Auditing IIS logs SQL Server logs and backups NT application logs traceability E2E instrumentation (future)
Will this security infrastructure be manageable as we grow?	Integrated security as opposed to a silo-based approach	Security Policy Groups  NT application logs  Windows integrated security Impersonation Active Directory others.

ASP.Net Session Management

1. Allows to store any kind of data in memory on the server.

2. The client must present the appropriate session id with every request. This can be achieved in two ways:
- Using Cookies: Session Id is transmitted in a special cookie called ASP.NET_SessionId. Since this info is stored in memory it can quickly grow to performance destroying levels.
- Using Modified URLs:

3. Session can be lost in the following four ways:
a. If the user closes and restarts the browser.
b. If the user accesses the same page through a different window. Browsers differ on how they handle this situation.
c. If the session times out due to inactivity.
d. If the programmer ends the session in the code.

In the first two cases the session still resides on the server until it expires.


The session should be abandoned in the logoff action clearing and releasing all the memory.

ASP.Net View State - Little Known Facts

1. View State is not encrypted but patched together in memory and converted to a Base64 string. A hash code is added to the end by default and hence protects from changes on the client side. Since the keys used by ASP.NET are not known hence it is secure.

2. View State will not work in cases of a server farm where the machine that intercepts the subsequent request can be different and hence have a different key for hashing. This can be overridden by using same key on all the servers.

3. The hash code is enabled by default. To disable it:
<configuration xmlns="<a href=">http://schemas.microsoft.com/.NetConfiguration/v2.o</a>">

<system.web>

<pages enableviewstatemac="false">

</system.web>

</configuration>

4. The view state can be encrypted on a page basis by using:<%@Page ViewStateEncryptionMode="Always" /> OR can be set in the web.config using The options are Always, Never and Auto. In case of auto the individual controls must call Page.RegisterRequiresViewStateEncryption();

5. Don't encrypt the view state unless you need to because of performance reasons.
6. All objects that needs to be stored must be serializable.


One of the limitations of View State is that it gets lost when the user navigates to a new page. The are two solutions to it:

1. Cross-Page Posting:
The infrastructure that supports cross page posting is PostBackUrl provided by IButtonControl and turns up in button controls like ImageButton, LinkButton and Button. To cross post simply set the PostBackUrl to the new form and when the button is clicked all the values form the user controls on the current page is transferred to the new page.

On the next page you can use the Page.PreviousPage to check the page you came from. In case of a direct access / post back previous page is null.
On the next page you can cast the PreviousPage to the appropriate page and use the values of all the controls.

This problem can also be solved by specifying the previous page type to the .aspx page, right after the page directive. e.g:
<%@ PreviousPageType VirtualPath="CrossPage1.aspx" %> This limits you to a single page class.

Another issue is accessing the values on the new page. Since the controls are protected by default, you should create properties that extract the info from the controls and can be used to access.

The first time the second page accesses Page.PreviousPage, ASP.NET needs to create the previous page object. To do this, it actually starts the page processing but interrupts it just before the PreRender stage, and it doesn't let the page render any HTML output.

This has some side effects, all the page events are fires, including Page.Load and Page.Init and the Button.Click event also fires for the button that triggered the cross-page post back. ASP.NET fires these events because they might be needed to initialize the source page.

2. Query String:
?a=value&b=value
Clear Text, Size Limited to 1 - 2 KB based on browser.

3. Custom Cookies:
Limited to simple strings.
Easily accessible and readable.
Users can disable cookies.

Welcome

Home of Nyasa Technologies.

Watch out this space for all the latest news.