Debugging problems with IE Security Zones

Internet Explorer has quite a complex security model compared to other browsers. One unique feature is the infamous Security Zone. Zones apply different policies to code based on the URL. By default, you have the following zones: Internet, Local Intranet, Trusted Sites, Restricted Sites, and My Computer.

Each of these zones has a slightly different con­fig­u­ra­tion depending on the intended usage. For example, the Internet zone is designed to handle untrusted code from the internet. The settings are locked down tightly, and recent versions of IE run this code in a sandbox with Protected Mode.

Compare this to the Intranet zone which has a more relaxed con­fig­u­ra­tion. If a URL is included in this zone it is considered to be trusted to a greater degree than one in the Internet zone. IE will even respond dif­fer­ent­ly to au­then­ti­ca­tion requests for sites in the Intranet zone to support Windows Au­then­ti­ca­tion (see IWA, NTLM, Kerberos, and SPEGNO.)

Everything is fine and dandy when your ap­pli­ca­tion has code that only loads from URLs belonging to a single zone. However, things will start to go pear-shaped when you have code loading from different zones. The exact behaviour will depend on your ap­pli­ca­tion, but you'll often see in­con­sis­tent behaviour between en­vi­ron­ments. The ex­pla­na­tion for this is often the ap­pli­ca­tion of group policy resulting in different con­n­fig­u­ra­tions across machines.

So how do you go about debugging these issues? My approach is to start with the following:

1. Make sure the problem only happens in IE. Doing this will save you a lot of pain as debugging with the Chrome developer tools is often a more pleasant experience than using the IE tools.
2. Identify all of the domains hosting your code. Understand what zones contain your host page, and which ones contain other scripts or code that you are pulling in.
3. Tem­porar­i­ly move all of the code into a single zone. If you move all of your code into a single zone for testing you can confirm whether Protected Mode issues are at the heart of your problem. You may need to tweak some IE zone settings to get the features you need, but it's a good start.
4. Disable com­pat­i­bil­i­ty view. Sites in the Intranet zone use this feature by default, and it can cause problems. Tem­porar­i­ly turn it completely off for the Intranet Zone so that that things are consistent across zones.
5. Use IE Zone Analyzer. This tool allows you to review the con­fig­u­ra­tion of zones in great detail, and help with bugs that only appear in certain en­vi­ron­ments. It is available for free from Microsoft.

At this point you'll be in a better position to debug specific code in IE, but how do you remediate the problem? Well you have to make a change somewhere. It is common for admins to add wildcards like *.domain.com to the Intranet zone. Naturally this will not dis­crim­i­nate between Intranet sites, and cause a lot of problems if you have modern code that doesn't run well under Com­pat­i­bil­i­ty View. Try to educate your admins on the ap­pro­pri­ate con­fig­u­ra­tion so that your en­vi­ron­ment will be more secure, and you'll also spend less time debugging!

Tagged with internet-explorer, javascript and debugging.

Production Debugging talk at Code Camp Philly

Thanks to everyone who attended my talk on Production Debugging. You can now download my slides and code samples from the talk. I have listed some questions and answers from the talk at the bottom.

Where can I get Reflector?

It is a free download on Red Gate's site. You don't have to buy the Visual Studio in­te­gra­tion. When it starts up you are asked for the version of .NET to use. I always select the latest version as .NET backwards com­pat­i­bil­i­ty is good. Of course this can be changed later.

How do you stop someone from de­com­pil­ing your code with Reflector?

The truth is that you cannot stop a determined hacker from getting at your code. Your best option is to make it harder by using an ob­fus­ca­tion tool such as PreEmptive Dot­fus­ca­tor, Red Gate Smar­tAssem­bly, Remotesoft Salamander, Xheo Code Protection, or one of the many other .NET ob­fus­ca­tors.

You should be aware that ob­fus­ca­tors can make your life more difficult. One way they make code harder to read in Reflector is through method renaming. This can result in the stack traces from the obfuscated code being out of sync with your code.

Can I use ELMAH with Windows apps?

Not easily. ELMAH relies on various features of ASP.NET to do a lot of it's work. Some people have make their own mod­i­fi­ca­tions, but it not something that a beginning developer might want to attempt.

I wrote a sample ages ago called BugBack that works for WinForms. It is old and in need of some love but it is a starting point. If you want an off the shelf solution you should look at Red Gate Smar­tAssem­bly.

Tagged with asp-net, codecamp, debugging, fiddler, http, philadelphia, presentation, sharepoint and talk.

Crash reporting in Windows

Microsoft have been collecting crash data using a system known as Windows Error Reporting ("Dr Watson") since the release of Windows XP (and possibly earlier). When a usermode error occurs in an ap­pli­ca­tion, a minidump and other pertinent is extracted. The user is then prompted as to whether they wish to report this in­for­ma­tion. After the reboot that follows a kernal mode error (bugcheck) you are prompted to send this in­for­ma­tion to a secure Microsoft server.

If the in­for­ma­tion is reported, a back end process does some analysis to see if it matches other error messages and might offer you some feedback. I've certainly benefited from this in the past, as a buggy D-Link driver caused numerous bugchecks (blue screens) and WER pointed me to a source of newer drivers.

I've observed the use of this feature by many people and there seems to be a fairly even split between those that send the crash data and those who cancel out. It appears that many people don't provide feedback because they fear Microsoft getting getting access to private in­for­ma­tion. This fear is jus­ti­fi­able, but I think that Microsoft could encourage more people to submit bug reports if they improved their UI design and branding.

The current im­ple­men­ta­tion on Windows XP and 2003 has these faults:

• The UI is simplistic. Although it offers some in­for­ma­tion on why you might submit, it fails to reinforce the benefits.
• Technical in­for­ma­tion cannot be easily copied to the clipboard. It would also be good to be able to save this to a file.
• There is little help provided to help decipher the technical in­for­ma­tion provided.
• Lack of Windows UI in­te­gra­tion. If you are using a shared computer, an ad­min­is­tra­tor cannot see all of the issues which have been submitted to spot problem ap­pli­ca­tions. The settings for crash reporting are hidden away from most users in the system applet.
• If you are offline you cannot submit a report.

Tagged with debugging, error-handling and windows.