Help Stop Cross-Site Scripting Attacks with HttpOnly Cookies

Did you know that there’s a simple little change you can make in the way you handle cookies that can help prevent your users from falling victim to a cross-site scripting attack? Implementing HttpOnly cookies is quick, easy, and goes a long way towards making your application safer for everyone.

HttpOnly cookies behave exactly like regular cookies with one important difference: they cannot be accessed by client-side script running in the user’s browser. This doesn’t seem like a big difference until you realize that many cross-site scripting exploits depend on this very capability.

As long as you’re running .NET 2.0 or higher, you can enable HttpOnly cookies in a couple different ways. The easiest is to simply edit your application’s Web.config file. Setting the value of the httpOnlyCookies attribute of the httpCookies element to true will convert all the cookies your application sends to the HttpOnly flavor.

You can also do the same thing for individual cookies that you set via code. It couldn’t be much easier as you can see in the following listing:

Dim myCookie As HttpCookie
myCookie = New HttpCookie(“LastVisit”, DateTime.Now.ToString())
myCookie.HttpOnly = True
Response.AppendCookie(myCookie)

Now for the bad news: HttpOnly cookies only work in relatively new browsers. Older browsers will either treat them as regular cookies or ignore them altogether. If you happen to have a user base which is particularly behind the times, you’ll need to do some testing to see how your application behaves in their browser(s) of choice.

For more information, you may find the following links useful:

Mitigating Cross-Site Scripting With HTTP-Only Cookies
ASP.NET Settings Schema: httpCookies Element
.NET Framework Class Library: HttpCookie.HttpOnly Property

Update: HttpOnly Cookies in ASP.NET 1.x and Classic ASP

I’ve gotten a number of email from users anxious to use HttpOnly cookies in their legacy Web projects. Rest assured, you can get the same HttpOnly functionality regardless of your server side tool of choice… it’s just takes a little more work.

For those of you using ASP.NET 1.x, try this code:

Dim myCookie As HttpCookie
myCookie = New HttpCookie(“LastVisit”, DateTime.Now.ToString())
myCookie.Path += “; HttpOnly”
Response.AppendCookie(myCookie)

It’s a little bit of a hack, but it should work in most cases. The only situation I can think of that might cause a problem is if your cookies are flagged as secure.

In classic ASP it’s a little more difficult. You can’t really use the Cookie object to accomplish the task, so you’ll need to resort to brute force and use the Response.AddHeader method to set the cookie.

Response.AddHeader “Set-Cookie”, “CookieName=CookieValue; path=/; HttpOnly”

As you can see, HttpOnly cookies aren’t just for developers lucky enough to be using the latest version of ASP.NET. With a few tweaks you can use you can use them with whichever server-side technology you prefer.

Visual Studio 2008 SP1 and .NET Framework 3.5 SP1

After a healthy run in beta, Microsoft has finally released both Visual Studio 2008 Service Pack 1 and .NET Framework 3.5 Service Pack 1.

The updates are available for download directly from Microsoft via the links below. If you’re curious what the updates provide, I’ve also included the brief description that Microsoft gave for each.

Visual Studio 2008 Service Pack (SP) 1

Visual Studio 2008 SP1 introduces full support for SQL Server 2008, improved performance in the IDE and WPF designers, improved Web development and site deployment, and many Team Foundation Server enhancements.

Microsoft .NET Framework 3.5 Service Pack (SP) 1

Microsoft .NET Framework 3.5 Service Pack 1 is a full cumulative update that contains many new features building incrementally upon .NET Framework 2.0, 3.0, 3.5, and includes cumulative servicing updates to the .NET Framework 2.0 and .NET Framework 3.0 subcomponents.

You can find additional information about each of the service packs on their respective download pages. So… what are you waiting for? Go get em!

ASP Browser Capabilities Component

The ASP Browser Capabilities component creates a BrowserType object that determines the type, capabilities and version number of a visitor’s browser.

When a browser connects to a server, a User Agent header is also sent to the server. This header contains information about the browser.

The BrowserType object compares the information in the header with information in a file on the server called “Browscap.ini”.

If there is a match between the browser type and version number in the header and the information in the “Browsercap.ini” file, the BrowserType object can be used to list the properties of the matching browser. If there is no match for the browser type and version number in the Browscap.ini file, it will set every property to “UNKNOWN”.

ASP Browser Capabilities Example

The example below creates a BrowserType object in an ASP file, and displays some of the capabilities of your browser:

Example & Syntax

ASP.NET version of “Name Tag”

This sample shows you how to load a background image from a file, add some text to the image using ASP.NET’s graphics capabilities, and serve the resulting image to a browser.

As an example we’ll be using an image of one of those “Hello My Name Is” name tag stickers that we’ve all seen at conferences and get togethers. We’ll load the image, add a name to the tag and send the image to the browser. The name will be pulled from the QueryString so it can easily be changed.

Here’s a zip file of the code along with the sample background image (13 KB).

Here are a couple of links to the script that pass in different names for reference:

John
Fred Q. Smith

Play with the running version.

View the live source code.

Read-Only Session State

The fact that ASP.NET maintains a user’s session state for us is a great thing. It allows us to program applications for the Web and rarely give a second thought to the fact that we don’t actually maintain a connection to our users. That being said, session state does come at a cost and disabling it when you’re not using it is a standard tip for improving application performance. But what if you are using it?

There’s a little known option that can serve as a happy medium. Instead of setting your page’s EnableSessionState attribute to “True” or “False”, you can set it to “ReadOnly” instead. The resulting page directive should look something like this:

This only works on pages that need access to a user’s session state information, but do not modify it. If you take a close look at your application, you’ll probably find that the majority of the pages that use session state fall into this category.

Using this setting won’t give you the same performance benefit you’d get by disabling session state altogether, but then again you don’t have to give up using sessions in order to use it.

Instantly Find Sub and Function Declarations

Trying to quickly make sense of unfamiliar code can be quite frustrating. This tip will show you how you can instantly jump from the usage of any subroutine directly to its definition using any flavor of Visual Studio. This huge time saver lets you easily locate code that you might otherwise have spent hours trying to find.

Assuming you’ve already opened the Web site or application with Visual Studio, the first step is to find a usage of the subroutine whose definition you’re trying to find. Then simply place your cursor on the Sub or Function name and press the “F12″ key on your keyboard. The code window will instantly move you to the declaration of the algorithm in question. This works even if the source code is located in a different file altogether.

Once you’ve examined the code or made any changes you may need to, you’ll most likely want to return to your original location. Luckily Visual Studio provides a simple shortcut for this as well. Use the “Ctrl+-” keyboard combination and you’ll end up right back where you started.

Jumping around unfamiliar code this way can take a little getting used to, but once you get used to using “GoToDefinition” (“F12″) and “NavigateBackward” (“Ctrl+-”), you’ll wonder how you ever got along without them.

Be Sure to Handle Errors to Continue Script Execution

I recently spoke with a developer who was upset that the redundancy he built into his Web application had failed him. As a safeguard against database failure, he had written a script which wrote new entries to a log file on the local file system as well as adding them to the database. It was a good idea… unfortunately the implementation wasn’t so good.

The fact that he was writing to the log file first gave him a false sense of security. You see, every time there was a problem with the database he’d always gone to check the log file and found the missing entries there waiting. The problem didn’t become apparent until someone accidently changed the permissions on the log file and his script threw an ‘access denied’ error which halted execution. It never even tried to write to the database and the new entries were lost completely. So what did he do wrong?

He never added any error handling to the script. If he had simply added a “Try… Catch… Finally” block around each of the operations, the script would have achieved the desired result. Even if he didn’t take the time to do anything to actually handle the errors, execution would have continued and the script would have at least tried to write the new entries to the database instead of coming to a dead stop when it ran into the permission problem.

For those of you who aren’t familiar with “Try… Catch… Finally”, here’s a short sample script which illustrates my point. This script attempts to write to a log file and send an email. I’ve wrapped both operations with a “Try… Catch… Finally” block so if either (or both) fail, as they probably will if you try and run the script as is, execution will still continue to the end of the script. For illustration I’ve included status messages which the script will display as it runs. It’ll also output the text message of any errors it encounters at the bottom of the page.

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
‘ Try to write to a logfile and send an email, writing status messages as we go…
litPageProgress.Text = ”

Page_Load sub started execution at: ” & _
Now().ToString & “

” & vbCrLf

litPageProgress.Text = litPageProgress.Text & ”

Attempt to write to log file… “
Try
File.AppendAllText(Server.MapPath(“logfile.log”), Now())
litPageProgress.Text = litPageProgress.Text & “Succeeded!”
Catch exLogFile As Exception
litErrors.Text = litErrors.Text & exLogFile.Message & “
“
litPageProgress.Text = litPageProgress.Text & “Failed!”
Finally
litPageProgress.Text = litPageProgress.Text & “

” & vbCrLf
End Try

litPageProgress.Text = litPageProgress.Text & ”

Attempt to send email… “
Try
Dim mySmtpClient As New SmtpClient(“localhost”)
mySmtpClient.Send(“FROM_ADDRESS”, “TO_ADDRESS”, “Message Subject”, “Message Body”)

litPageProgress.Text = litPageProgress.Text & “Succeeded!”
Catch exLogFile As Exception
litErrors.Text = litErrors.Text & exLogFile.Message & “
“
litPageProgress.Text = litPageProgress.Text & “Failed!”
Finally
litPageProgress.Text = litPageProgress.Text & “

” & vbCrLf
End Try

‘ Note that this line will still run even if errors occur above.
litPageProgress.Text = litPageProgress.Text & _
”

Page_Load sub ended execution at: ” & _
Now().ToString & “

” & vbCrLf
End Sub

Try… Catch… Finally Error Handling Example

Errors Encountered:

web application – DHTML or Silverlight?

I want to develop a web application and I am not sure whether I should do it in DHTML or Silverlight.

I could use the rich UI capabilities of Silverlight, but on the other hand
Silverlight is heavy on the client and not many users installed it.

Are there any solutions or suggestions ..?

 

So why not Flash? Richer than DHTML and it’s pretty much universally installed by users.

Why stick with MS tech-not-logies?

Help Stop Cross-Site Scripting Attacks with HttpOnly Cookies

Did you know that there’s a simple little change you can make in the way you handle cookies that can help prevent your users from falling victim to a cross-site scripting attack? Implementing HttpOnly cookies is quick, easy, and goes a long way towards making your application safer for everyone.

HttpOnly cookies behave exactly like regular cookies with one important difference: they cannot be accessed by client-side script running in the user’s browser. This doesn’t seem like a big difference until you realize that many cross-site scripting exploits depend on this very capability.

As long as you’re running .NET 2.0 or higher, you can enable HttpOnly cookies in a couple different ways. The easiest is to simply edit your application’s Web.config file. Setting the value of the httpOnlyCookies attribute of the httpCookies element to true will convert all the cookies your application sends to the HttpOnly flavor.

<system.web>
    <httpCookies httpOnlyCookies="true" />
</system.web>

You can also do the same thing for individual cookies that you set via code. It couldn’t be much easier as you can see in the following listing:

    Dim myCookie As HttpCookie
    myCookie = New HttpCookie("LastVisit", DateTime.Now.ToString())
    myCookie.HttpOnly = True
    Response.AppendCookie(myCookie)

Now for the bad news: HttpOnly cookies only work in relatively new browsers. Older browsers will either treat them as regular cookies or ignore them altogether. If you happen to have a user base which is particularly behind the times, you’ll need to do some testing to see how your application behaves in their browser(s) of choice.

For more information, you may find the following links useful:

• Mitigating Cross-Site Scripting With HTTP-Only Cookies
• ASP.NET Settings Schema: httpCookies Element
• .NET Framework Class Library: HttpCookie.HttpOnly Property

Update: HttpOnly Cookies in ASP.NET 1.x and Classic ASP

I’ve gotten a number of email from users anxious to use HttpOnly cookies in their legacy Web projects. Rest assured, you can get the same HttpOnly functionality regardless of your server side tool of choice… it’s just takes a little more work.

For those of you using ASP.NET 1.x, try this code:

    Dim myCookie As HttpCookie
    myCookie = New HttpCookie("LastVisit", DateTime.Now.ToString())
    myCookie.Path += "; HttpOnly"
    Response.AppendCookie(myCookie)

It’s a little bit of a hack, but it should work in most cases. The only situation I can think of that might cause a problem is if your cookies are flagged as secure.

In classic ASP it’s a little more difficult. You can’t really use the Cookie object to accomplish the task, so you’ll need to resort to brute force and use the Response.AddHeader method to set the cookie.

    Response.AddHeader "Set-Cookie", "CookieName=CookieValue; path=/; HttpOnly"

As you can see, HttpOnly cookies aren’t just for developers lucky enough to be using the latest version of ASP.NET. With a few tweaks you can use you can use them with whichever server-side technology you prefer.

Basic authentication vs. NT Challenge and Response

When you password protect a web page using Internet Service Manager, you have the option of choosing either Basic authentication or NT Challenge and Response (aka: Integrated Windows authentication). The difference in the two methods is in the way the username and passwords are transmitted over the Internet. NT Challenge and Response encrypts the password so malicious snoopers can not intercept and use the information. Basic authentication sends the password as plain text. While it would be great to use NT Challenge and Response for all secured web pages, the only web browsers that currently support this protocol are Internet Explorer 3 and higher. If you might have users with other web browsers, your only choice is Basic authentication.

If you would like to have a secure website take advantage of using encrypted usernames and passwords but still want to be compatible with Netscape browsers, you can use Basic authentication over SSL. Using Secure Sockets will encrypt the user name and password but at the same time will still let Netscape browsers use your site, the best of both worlds