ASP.NET Session State Error

Recently I’ve been working on an ASP.NET web app which uses membership and session state, however came across an error whilst setting it up:

“Unable to use SQL Server because ASP.NET version 2.0 Session State is not installed on the SQL server. Please install ASP.NET Session State SQL Server version 2.0 or above.”

Ever see this before?

I must’ve read every tutorial on installing and configuring session state and none seemed to mention this. After a little further digging, it turns out that using aspnet_regsql from the wrong location was the problem. Usually when you’re installing membership you open up the Visual Studio Command Prompt. When working with ASP.NET 3.5, it seems to generate an older session state database though.

The fix?

Open up command prompt and change directory to: “C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727″
Then simply run your install arguments:

aspnet_regsql.exe -ssadd -sstype c -d [DATABASENAME] -E

Afterward, don’t forget to open up Sql Management Studio and assign the appropriate permissions to the user account / session state database we just installed.

Your web config file should have the following setting of course:

<sessionState cookieName=”[CHOOSEACOOKIENAME]” mode=”SQLServer” sqlConnectionString=”Data Source=localhost;database=[SESSIONDATABASENAME];User Id=[USER];Password=[PASS];” timeout=”30″ allowCustomSqlDatabase=”true”  />

Don’t forget to set: allowCustomSqlDatabase=”true” if you set the ‘-sstype’ to ‘c’

Advanced Splash Screen Component for .NET

Hello again!

This quick post is a follow up article to my previous installment regarding my .NET Splash Screen component.

The original app can still be found over at: CodeProject

After writing that article, I realised I wasn’t happy with how the component turned out. It was missing quite a few important features that a solid splash screen should have. For starters, it was in bad need of stronger OOD. So I took off coding, what I now think, is an excellent product for all WinForm developers.

Improved OOD was accomplished through the addition of encapsulation. This new version adds several new functionality including:

• Dynamic form/control creation and updates
  • Create controls on the fly, access their properties, and update them at runtime. Access the splash screen from anywhere in your code.
• Multi-threaded
  • All methods are handled by the component itself so no cross-thread exceptions will occur.
• Customizable effects
  • Fading in and out, speed.
• Clean Code
  • The component has been coded with strict, clean naming conventions; re-factored, and fully documented.

Download

Forging HTML Forms with FireBug

It’s incredible how insecure most sites are. Even little things like HTML Forms. Most developers don’t even think about this while writing an application. They’ll include some small server-side script to cleanse inputted data before it gets sent to a database, but fail to see if anything has been tampered with; and if the information is legitimate. To illustrate my point, we’ll take a look at a first hand example I conducted this past week.

So this past weekend I get a notice from my water utility company saying we owe a balance and water will be shut off at any moment. This isn’t news to me, as living with broke college students is common catalyst for unpaid bills.

My roomates and I get together, go to the online services to pay the bill, only to find that the utility company requires us to pay in full … and not only that, restricts the payment form so that you must pay the entire bill in one single transaction! (Retarded I know.)

Well none of us have that much money to spot everyone, so I get to thinking. The form basically looks like this. (I’ve edited it for security purposes obviously.)

As you can see they’ve listed the balance, and disabled the Payment Amount field so I cannot adjust how much to charge to my card. Well here comes FireBug.

One feature of FireBug is that it allows us to inspect html elements and make edits to them in real-time. No page refresh is needed as it inserts it directly into the browser window.

I decided to examine the form elements and take out the <input> attribute: “disable” which has prevented me from entering my custom payment amount. Voila! The field become now editable. I then take a look further as I suspected there might be a hidden input element which tells the server-side processing how much it really should be…

And what do you know, I was right! So I edit that element’s value to reflect my newly inserted payment value. Submit the form and without a hitch, it takes my payment. I do this for the rest of my roommates using their own card and we pay the bill in separate payments successfully.

Now what did we learn from this?

Possibly that any kind of data inserted by a user MUST be processed extremely carefully. Obviously, if the utility company’s script made another check to see if my bill was unpaid and had to be paid in full, it would have thwarted this hack. It’s imperative that you NEVER place any security reliance on an interface that a user has access to. Hope we learned something!