Tag Archive | Security

Access and Modify Identity Information

I was evading the topic of security ever since I began posting my notes. It had a good reason: I’ve never worked with it. So I’d like to apologize here and now for the future mistakes in the following series of posts.

The first security-related objective we’ll revise is the accessing and modifying of the identity information. You can access the currently working user account (the entity under the current thread executes. There won’t be any calls to the stack to find an appropriate identity in it.). To achieve this, you’ll consider using two classes: the GenericIdentity and the GenericPrincipal classes. These classes have counterparts designed for using the Windows authentication services (like Active Directory). They are called WindowsIdentity and WindowsPrincipal respectively.

Of course, you can implement your custom Principal/Identity classes. In this case, your yet-to-come classes must implement IPrincipal or IIdentity. Let’s see a code sample on how to access the current user:

WindowsIdentity theIdentity = WindowsIdentity.GetCurrent();
  Console.WriteLine(“Good news, you are authenticated!”);
GenericIdentity myCustomIdentity = new GenericIdentity(theIdentity.Name, theIdentity.AuthenticationType);

Read More…

Compression and Isolated Storage

In this post we’ll examine the topics of compressing data, and the usage of the Isolated Storage feature of the .NET Framework. The namespaces are System.IO.Compression and System.IO.IsolatedStorage.


That’s an easy one, you’ll need to know two classes and an enumeration, namely: GZipStream, DeflateStream and CompressionMode. Even better GzipStream and DeflateStream can be used in the exact same way. The main difference, as you’d guess is the compression method. Both classes derives from Stream, so you can call the Read, Write and Seek methods. Both of them provides two constructors: the first one accepts a stream and a member of the CompressionMode enumeration. The second extends the first with a Boolean that indicates whether or not the stream should be kept open.
Read More…

ASP.NET AJAX Application Services

In this post, we’ll examine the built-in services in ASP.NET AJAX. You call these services in a same way as you’d call any custom web service from script, but there are some differences.

There are three built-in services in ASP.NET AJAX, namely:

  • Authentication service
  • Role service
  • Profile service

To use these services, you must take two steps: first, configure that you’d like to call these services in your web.config file, then call the configured services from script in your pages. Both the configuration and the calling code is different for the three services, so lets get started with authentication.
Read More…

User Input Validation in ASP.NET

HTML forms exist to collect data from the user. And this data, like every piece of user input, needs to be checked first for both security and logical reasons (what could we do with irrelevant data). There are two ways of checking the validity of user input: on the client side, and on the server side. Client side validation is swifter and more elegant, then posting back the data to the server, and the send back and error message. But we must implement both validation techniques, because a crafty attacker can bypass our client-validating methods, and send for example scripts or SQL commands back to our page to process them.

Implementing these two different approaches is quite tedious by hand, because client-side validation usually takes place in javascript, while server-side logic could be PHP, or in our case C#, and they are very different by their nature. And there come the ASP.NET validation controls in the picture.
Read More…

Configuring Session State

Session State:

Session State enables you to store information, which is persisted during page changes. It’s stored server-side, and is essentially a collection like ViewState, or Application state. The syntax is straightforward: Session[“Key”] = Value;

Session state is not shared between clients, like application state. Every user has his/her own session ID, which guaranteed (statistically) to be large enough not to be guessed or reverse-engineered.

To access his or her private session information, the user must provide the session ID. It can be stored two ways (just like the authentication information): in a cookie (ASP.NET_SessionId is the name) or in a modified URL, serving clients who don’t support cookies.

Using Session State:

To store a datatable in a user’s session, just type the following:
DataTable dt = new DataTable();
Session[“Cart”] = dt;

Retrieval is quite easy, too:

Dt  = Sesion[“dt”] as DataTable;

Session state can be used in every page of your application, but it’s not immortal. Session information can be lost if:

  • User closes/restarts browser.
  • May be lost when the user requests the same page on a different browser window. The original page will have the session, but the new may not. This behavior depends on the browser.
  • Timeout, due to inactivity. By default, it lasts 20 minutes.
  • If you call Session.Abandon();

Sessions lost when the hosting application domain is recreated (e.g.: change a configuration file, recompile application). For a workaround for this situation, you can use out-of-process session management.

Read More…

ASP.NET Authorization

ASP.NET Authentication/Authorization

ASP.NET Authorization:

There are two main authorization types: File Authorization and URL Authorization. Let’s start with the latter:

URL Authorization:

Specified in web.config files, with a declarative syntax. URL Authorization only interested in the security status of the user, and the URL resource being requested, hence the name. If the page is forbidden for the requesting user, and forms authentication is used, then the user will be prompted to log in, thus redirected to the login page. If windows authentication is active, the user will receive a 401 – access denied page. It can be customized in web.config customErrors tag, if needed.
Read More…

Forms Authentication

 ASP.NET Authentication/Authorization

There are four types of authentication in ASP.NET:

  • Windows authentication
  • Forms authentication (used by the membership API)
  • Passport authentication (mostly obsolete, consider Windows Live instead)
  • Anonymous access

Forms Authentication:

Forms Authentication is a token-based auth method. After login, the user gets an encrypted cookie with the login information. This token can also be stored in the query string, but more of it later. The process is simple:

  1. The client makes a request.
  2. IIS (if configured properly for Forms Authentication) passes the request to ASP.NET.
  3. ASP.NET checks for an authentication cookie (or info). If found it, proceeds to step 7.
  4. Redirects the user to the login page (default Login.aspx in machine.config).
  5. User enters credentials, ASP.NET authenticated. If authentication fails, access will be denied.
  6. If authentication succeeds, a cookie will be attached.
  7. ASP.NET tests the authorization settings and the current user.
  8. If fails, access will be denied, else access granted.

Pros to use Forms Authentication:

  • Full control over the authentication code, via Membership API.
  • Full control over the appearance.
  • No browser-incompatibility issues.
  • Enables to decide where and how to store user information.
  • Read More…