Microsoft Security Summit 2006

Today I attended the Microsoft Security Summit 2006 conference in Novi, Michigan. It's a free conference that Microsoft has been putting on in various cities targeted at both developers and IT folks promoting good security practices.

Keynotes

Both keynote speakers were very good. The opening keynote by Bret Arsenault was information-packed. Bret gave an overview of the history of security challenges in the IT industry along with solid coverage of the challenges facing the industry today. The hour length of the keynote flew by quickly, a sure sign of an interesting session.

The closing keynote by Jesper Johansson, covering security improvements in Vista, was also (to invoke the cliche) entertaining and informative. I've been subscribed to Jesper's blog for a while now, so it was cool to hear him speak in person (particularly since he turned to out be a good in-person presenter as well as a good blogger). I didn't recognize Jesper by sight, as he wasn't wearing his scuba gear. :-) Jesper made a wry observation about why security can be a hard sell to corporate executives: It's a significant financial investment which, when finished -- if done properly -- will result in everything continuing to work as it has before!

Jesper also made a comment which makes good sense from a security perspective, but perhaps not from a "real-world" perspective. He asserted that any application which either requires administrative privileges to install and run, or writes per-user data to shared areas of the filesystem such as under Program Files or the Windows folder, is "broken." Jesper mentioned Adobe's Photoshop as an example of such an app.

I agree that such applications are certainly less than ideal, but for many software shops, the time and money to engineer apps to run well not just on all currently-available versions of Windows but on potential future Windows versions as well is a luxury that can't always be afforded. Not everyone has the cash in the bank to support the delay and re-delay of product releases to ensure that functionality that does not directly impact the user experience is perfect, like Microsoft is attempting with Vista. Still, the ideal of applications that are engineered superbly from both a features and security perspective is a worthy goal for developers.

Break-Out Sessions

One of the afternoon sessions focused on some types of attacks to which web applications are susceptible, such as SQL injection. I had heard variations of this session a couple of times before, including once at the 2003 PDC conference in Los Angeles. This session included one particularly nasty attack which was new to me, though, called a "one-click" attack. (The attack name brought to mind the infamous Amazon patent of the same name, although it turned out to be unrelated.) This attack involves coding a hidden form into a simple .html page which, when visited, invisibly auto-submits a request to another site to which the victim had recently logged in.

The example of the attack demonstrated was an employee visiting a (deceptively) simple "car for sale" web page on the internal corporate site, which modified the target account/routing number for the user's paycheck direct deposit via the recently-visited internal HR site. Dangerous stuff. (The solution involves setting up a key based on the session ID that is required to be submitted along with the change request, using an ASP.NET 1.1 ViewStateUserKey or other means.)

The second afternoon break-out session covered new features in Visual Studio .NET 2005 and SQL Server 2005 that support development of secure applications. One new SQL Server feature mentioned was EXECUTE AS, which uses impersonation to enable subsequent queries or commands to be run under the security context of another user. Impersonation is ended when a REVERT is run.

During the Q&A at the end, I asked whether nested EXECUTE AS operations were supported; in other words, if I do, in order: EXECUTE AS 'Alice' EXECUTE AS 'Bob' REVERT Then who am I running as at that point -- Alice, or the original user? The presenter wasn't sure. I looked into this briefly, and apparently (per this Bob Beauchemin blog post) nesting is indeed possible.

Also during the last afternoon break-out session, developers sitting in the first 5 rows (plus those who were willing to move up to the front from the back) got a free copy of the "Required reading at Microsoft" book Writing Secure Code, 2nd Edition. Happily, I was sitting in the 5th row. :-) I did partially read through a copy of this a couple of years ago, shortly after its release; now, with another couple of years of experience under my belt, I plan to give the book a more thorough read-through.

...And We're Back!

This past Thursday, moderately severe thunderstorms swept through much of the region, including here in Michigan. The power flickered on and off at least twice during the storm. My home web server machine was on at the time, but it seemed to weather the storm okay.

Until Friday, that is. Melissa went to use the machine, and although it appeared to be on (power light on the case on, internal fan audibly running), the monitor was showing its "no signal" graphic.

Power was definitely on to both the monitor and CPU, and the video cable was snugly connected. At first I suspected that the video card was fried, but when I tried rebooting the machine, there was no beep from the speaker, and Windows never seemed to boot as I couldn't contact the machine over the network in any way (via ping, http, or Terminal Services). I concluded that the motherboard had been damaged by the storm -- if the problem was with another component, I would expect to at least hear a series of error beeps after the machine powered on.

Fortunately, I was able to disconnect the hard drive and set it up as a slave on my other machine, and get all of the important files transferred onto the machine's primary hard drive. (I also had the important files backed up on an external USB drive, but this saved me the trouble of doing a restore.)

I've set up my remaining machine as the new web server. So, all you legions of jonschneider.com fans (read: the 8 or 10 unique visitors a month that I get coming in mostly from Yahoo! Search to look at my old Warcraft III maps page...) can celebrate -- the site is up and running again.

I also needed to re-register ASP.NET with IIS, set up MySQL as a WinNT service, and install MyODBC to set up a MySQL DSN to restore functionality of an internal web application that I have running on the server.

Melissa and I have decided to wait for now on getting the old server machine repaired or rebuilt. This seems like a good excuse to upgrade the motherboard and processor, but with our son Elijah (13 months old today!) around these days, we've found that we both want to be using a computer simultaneously far more seldom than we used to. And if we wait, when we do get a new motherboard and processor later, we'll be able to get more power for the money. Possibly we'll rebuild the server machine with Vista sometime after it is released.

Fix: "Object doesn't support this property or method" on a Windows Forms control built with VS 2005

At the office recently, I was asked to whip up a simple Windows Forms UserControl with a public method and run it embedded in an HTML page in Internet Explorer. "No problem," or so I thought at the time -- I had created similar simple controls in the past, and one of the components that I have primary responsibility for at work is an Excel-like Windows Forms spreadsheet control that is deployed embedded in web pages and run in Internet Explorer. (More information on running Windows Forms controls in IE in this manner is available at GotDotNet .)

I had the control up and running in a web page in just a couple of minutes:

• I opened Visual Studio 2005 and created a new C# Class Library project.
• Added a new User Control to the project, "SimpleUserControl".
• To ensure that the control would stand out on the web page, changed the background color property of the control to Blue, and added a label to the control with the text "SimpleUserControl".
• Added a simple public method to the control: public string WhatTimeIsIt() {     return DateTime.Now.ToString(); }
• Compiled the project, and copied the generated SimpleUserControl.dll to a folder under my IIS root directory.
• Quickly typed up a simple HTML page in the same folder to show the control and demonstrate a call to the public method: <html> <body> <object id="SimpleUserControl"   classid="http:SimpleUserControl.dll     #SimpleUserControl.SimpleUserControl"   height="150" width="150" VIEWASTEXT> </object> <input type="button" value="What time is it?" onclick="DoWhatTimeIsIt();" /> </body> <script language="javascript"> function DoWhatTimeIsIt() {     alert(document.SimpleUserControl.WhatTimeIsIt()); } </script> </html>

I brought up the web page in IE and the SimpleUserControl displayed correctly, as expected. Unfortunately, clicking the button on the page, instead of returning a string with the current date and time, generated a Javascript error: "Object doesn't support this property or method".

I double-checked everything I'd done. (No, I hadn't misspelled the method name in the Javascript code... Yes, I really had declared the method to be public in the C# class...) Another one of the senior guys on the team plus my boss (who was the lead developer on the team prior to his promotion) also puzzled over this problem for a while without being able to figure it out.

Finally, my boss came up with the solution: In Visual Studio 2005, in the project properties, on the Application tab, in the Assembly Information dialog, the "Make assembly COM-Visible" checkbox (which was unchecked by default) needed to be checked. After doing this (and rebuilding the project, re-deploying the .dll file, and reopening the IE window), the button could successfully call the public method.

I was pretty surprised by not having run across this issue before. Apparently, though, in Visual Studio 2003 there is either no equivalent checkbox or it is checked by default (and thus similar controls which I had previously created, which worked fine, must have been created using VS 2003). Also, Visual Studio's migration wizard which upgrades VS 2003 projects to VS 2005 projects apparently checks the checkbox by default, which is why we didn't run into this issue after upgrading our product to use VS 2005.

Fix: IE Closes When Debugging a Windows Forms Control in Visual Studio .NET 2003

After my development team at work switched to developing using Visual Studio 2005 and the 2.0 .NET Framework, we encountered a problem trying to debug older versions of our Windows Forms controls running embedded in web pages viewed with Internet Explorer with Visual 2003. We would open our project or solution in Visual Studio 2003 and start the debugger to launch Internet Explorer, but shortly after the page with the Windows Forms control would start loading, Internet Explorer would just close with no error message, and the debugging session would end.

Another symptom of the same problem occurred when we instead would try to first open an Internet Explorer window normally and navigate to the web page containing our Windows Forms control, which would load correctly. Then, when trying to attach Visual Studio 2003 to the iexplore.exe process for debugging, Visual Studio would just fail with the error message "Unable to attach to the process."

We eventually determined that the problem was because Visual Studio 2005 along with the 2.0 .NET framework was installed on the development machine, Internet Explorer would load the Windows Forms control using the 2.0 framework (instead of the 1.1 framework as it had previously). Then, when Visual Studio 2003 (which uses the 1.1 .NET framework) tried to attach to the managed code in the iexplore.exe instance for debugging, it would (apparently) get confused and just fail.

The solution we came up with was to use a special iexplore.exe.config file to force IE to load controls using the 1.1 version of the .NET framework. To use this solution, open up a new text editor window and paste in the following text:

<configuration>
  <startup>
    <requiredRuntime version="v1.1.4322"/>
    <supportedRuntime version="v1.1.4322"/> 
  </startup> 
</configuration>

Then, save the file as "iexplore.exe.config" in your Internet Explorer folder (typically C:\Program Files\Internet Explorer). Finally, close and reopen any open Internet Explorer windows.

This will force Internet Explorer to use the version of the .NET framework specified in the file (in this case, 1.1.4322, the version number of the commercial release of the 1.1 framework) for any Windows Forms controls it loads.

To have IE revert to the original behavior of using the default version of the framework to load Windows Forms controls, just delete or rename the iexplore.exe.config file. (On my dev machine, I leave a copy of the file in my IE folder named "iexplore.exe.config_forcev11" for easy access when I need it.)

C# String Literals and the '@' Character

Specifying Windows file paths in C# code can result in some messy-looking string literals, due to the need to specify "\\" as each backslash character to avoid having a single backslash character be interpreted as the beginning of an escape sequence. For example:

string myAppPath = "C:\\Program Files\\MyApp";

(For the purposes of this post, I'm ignoring the fact that assuming that "myApp" will always be located at "C:\Program Files\" may not be a good idea.)

A way to make this look cleaner (and possibly be less confusing) is to use a '@' character prior to the string literal. The '@' character makes C# skip looking for any escape characters in the string (with the exception of the \" escape sequence). This use of the '@' character before a string literal is called a verbatim string literal. The file path declaration above, revised to use a verbatim string literal, would be:

string myAppPath = @"C:\Program Files\MyApp";

For more details on verbatim string literals, see the string literals page in the C# Language Specification.

Also, the Visual Studio IDE supports displaying verbatim string literals in a different color than standard string literals, for further clarity. I have my Visual Studio installations configured to display standard string literals in off-white and verbatim string literals in red.

Tip: Search file/project history in Visual SourceSafe

Microsoft's Visual SourceSafe (VSS) version control utility does not offer a built-in way to search the history of a file or project/folder. For example, you can't directly search on the check-in comments of a particular file for a bug number to find the file version where that bug was fixed.

However, it is possible to generate a report of all changes to a file or project, open that report in a text editor (such as Word or Notepad), and then perform the search in the text editor application.

To generate the report, first bring up the History dialog for the file or project to search (specifying date and user constraints if desired). Then, click the Report button on the History dialog to bring up the History Report dialog. (It doesn't matter what file(s) are selected in the left pane of the History dialog; the report will be generated based on all items present in the dialog.) On the History Report dialog, you can select the items you want to appear in the report. I typically choose only "Include details", since the "Include differences" option can make the report take a long time to generate (even for a fairly small file/project history). I also typically use the "Clipboard" output option to make the output easy to paste into my text editor.