A Blog for Graymad

My latest article on the MSDN ASP.NET Developer Center is up. It walks through the process of building a server control that allows simplified registration and login using Forms Authentication against an XML credentials file (of course, you can easily modify the control to use whatever credential store you’d like). Take a look, and if you have any comments, I’d love to hear them.

I’ve also got an article in the editing pipeline on the new caching features in ASP.NET Whidbey, including custom cache dependencies, database-driven cache invalidation, and post-cache substitution. I’ll post another update when that one goes live.

My two favorite people to read on the subject of security are Michael Howard and Keith Brown. In a recent posting, Keith explains the Principle of Least Privilege, and why it’s important. The most important reason for limiting the security privileges your code requires to run is to reduce the damage that can occur should your code be exploited by a malicious user. If your code only runs with basic user privileges, it’s difficult for malicious users to do much damage with it. If you require users to run your code using administrator privileges, then any security weakness in your code could potentially hand control of that machine (and potentially other connected machines) to malicious code that exploits that weakness.

But another important reason to follow the Principle of Least Privilege is highlighted by Brown’s post:

When you ship programs that don't follow these guidelines, your program breaks when users attempt to run with least privilege (under normal, non-administrative user accounts).

I had the misfortune of running into this recently when working with a beta product for a writing project I’m working on (since it’s a beta, and since I’ve been assured that the next release corrects the problem, I won’t harp on which product). When attempting to put together a code sample for one of the cool new features, I was unable to get the code to work as expected. I followed the examples I’d been provided to the letter, and I’d been able to get another code sample (that used an earlier version of the product) to work just fine. After a few emails, I was told that the problem was that the beta product required me to log in with a specific, highly-privileged account in order for the feature I was using to work. Now I had already been logging in with an account that had admin privileges (shame on me), but even that wasn’t enough. Suffice it to say, this simply should not have been the case, and the bug likely existed because the developer working on that feature hadn’t tested with a lesser-privileged account, nor had the person from whom I got the examples I was working with. Had either or both of these developers been following the Principle of Least Privilege, I would have saved several hours of tearing my hair out over why a very simple code sample wasn’t working properly.

This is not by way of beating up on those developers (though I hope that they’ll think about the consequences of developing using highly-privileged accounts) but to highlight the reasons that this principle is important. Fortunately, the above case was pre-release software, so they still have time to fix the problem. But I’ve seen far too many cases where programs require admin privileges for no better reason than the fact that the developer did not follow Windows’ coding guidelines (for example, programs that write user-specific settings to the Program Files tree), and did not bother to test with a non-admin account (in which case they would’ve noticed that such writes fail when run by a non-admin). That’s sloppy programming, and it’s something we all need to work to eliminate.

 Jonathan Goodyear, aka angryCoder, has posted the second article in a series he’s doing on becoming an independent consultant (you can find the first part here). In this installment, Jon talks about marketing yourself, and about how to get your customers to come to you (rather than the other way around).

This is fairly good reading, although his marketing advice may not be quite as applicable to the average developer as he makes it seem. After all, we can’t all be columnists for aspnetPRO magazine, given that the business model doesn’t support that. But his larger point that keeping your name in the public eye, and making sure that when you spend time (or money, though he doesn’t discuss that part) on marketing yourself, you need to make sure that you do so efficiently, that is, in a way that maximizes your exposure while minimizing the effort it takes.

A case in point, and one that’s pretty close to home for me, is writing. I have written several books on web development, as well as a number of articles (see the Articles navigation section), and I can attest to the fact that both books and articles can help get you noticed. But that’s only part of the story. Writing a book, as Jon observes, is a lot more work, and unless your book sells extraordinarily well, will not be read by nearly as many people as a typical magazine article. So if you want to write a book because you want the challenge, or you think it will help you career-wise (it probably will), then go for it. But if your primary purpose is to become a recognized name, you may be better off focusing your attention on articles instead.

Finally, given the topic at hand, I would like to remind any of my readers who might be looking for consulting or training on ASP.NET and .NET that I’m available to help. I’m located in the Washington, DC metro area, but I can travel for short-term training and mentoring, and I’m happy to do remote development and/or debugging, for those who are open to that.

Version 1.2 of the Microsoft Baseline Security Analyzer, an essential tool for keeping up with the latest patches and security settings on your machines, was released today.

For those who haven’t worked with it, MBSA allows you to scan one or more computers to ensure that they have the latest patches installed, and that appropriate settings are used for various applications, such as Internet Explorer, Office, and SQL Server. Once you’ve scanned a machine (or machines), MBSA prepares a report listing the issues that it finds. These range from critical issues (where a critical patch is missing) to simple warnings. The great thing is that almost without exception, the report includes links to instructions for addressing the particular issue that was found, including linking to any relevant KB articles.

Bottom line is that if you haven’t used MBSA, you owe it to yourself to take a look. It can be a big help in keeping your computer(s) secure.

DevDays 2004 is coming in March to a venue near you! This year’s DevDays focuses on two tracks, both oriented around best practices. The Smart Client track will speak to best practices for development, security, and deployment of Windows client applications, while the Web Development Trackwill focus on security in Web applications.

I’ll be speaking on the Web development track at the Washington, DC DevDays:

Washington, D.C.—Thursday, March 4, 2004
International Trade Center and Ronald Reagan Bldg.
1300 Pennsylvania Ave NW
Washington, D.C. 20004

So sign up, and make sure to come by and say “hello”.

Probably one of the best reasoned arguments I’ve heard in a long time…would that I could argue stuff half as well. And it’s not even about politics (unless you count XML validation as political…oh, never mind).

[via Critical Section]

If you haven’t seen Chris Brumme’s explanation of AppDomains, you owe it to yourself to take a look. It’s an older link (posted in June of last year), but well worth re-posting:

An AppDomain is a light-weight process.  Well, if you actually measure the costs associated with an AppDomain – especially the first one you create, which has some additional costs that are amortized over all subsequent ones – then “light-weight” deserves some explanation:

 

A Win32 process is heavy-weight compared to a Unix process.  A Win32 thread is heavy-weight compared to a Unix thread, particularly if you are using a non-kernel user threads package on Unix.  A good design for Windows will create and destroy processes at a low rate, will have a small number of processes, and will have a small number of threads in each process.

 

…[lots of good stuff]…

 

But even I think this blog is getting way too long.

[cbrumme's WebLog]

The first 1 terabyte (you read that right!) external drive. Firewire 400/800, USB 2.0/1.1 compatible. Whoa.

http://www.lacie.com/products/product.htm?id=10118

[via Mike Gunderloy]

Over the last couple of days, I’ve been spending a good deal of time reviewing the security of the web sites I host. I run my sites on a server sitting on a fractional T1 in my office (I like to have physical access to my web server, which is why I don’t use a hosting service). Originally, my web server had been sitting behind my wireless router which simply passed all port 80 traffic to the public IP address to the web server. But I found that for a variety of reasons, I wanted more direct control over how traffic is routed to various sites that I host. So I moved the web machine from the wireless router to directly connect to the T1 router using its own IP address. The dilemma was that since I leave the T1 router relatively open (filtering NetBIOS ports, but not much else) and lock down traffic at the second router, connecting the web server directly would leave it open to port scans and attacks, right?

Wrong. Because the good news is that Windows Server 2003, which I’m using for the Web server, comes with the same Internet Connection Firewall that Windows XP provides. So it’s very easy to limit traffic to just the services you wish to provide access to, in my case HTTP.

So what’s the bad news? Well, there are a couple of shortcomings that I think are unfortunate. One is that it would appear (though I haven’t found any documentation to back this up) that ICF only works for the first IP address on a given network connection. I had originally tried configuring two IP addresses on the same NIC, and though I was able to ping both addresses (if I allowed ICMP echo in ICF…it’s disallowed by default), I could not connect to a web site on the second (higher number) of the two IPs. My solution was simply to add a second NIC, since I had one sitting around that I wasn’t using, and enable ICF on both. While this worked for my situation, it’s obviously not a scalable model. I’m not going to complain too much about this shortcoming, however, since it’s pretty clear that ICF was provided as a home/small business user solution. If I really wanted to have a bunch of IPs on this machine, I could use the more sophisticated filtering on my router, albeit at the cost of much more complicated configuration (and with it, more likelihood of making a mistake that leaves something open).

A more serious shortcoming, from my perspective, is that ICF is not included on Windows Server 2003, Web Edition. What’s up with that? Did Microsoft decide that Web servers require less security? Or is it simply that because Web Edition is substantially cheaper, ICF is one of the features that got cut? Either way, for a company that’s trying to convince people that it takes security seriously, the absence of a tool that can make that job much simpler is really a bad decision, in my opinion. Particularly since it seems to me that the very people who are most likely to buy the Web Edition are the same people who are least likely to be willing to spend money on additional hardware or software firewall solutions.

I hope that Microsoft will reconsider this decision and, through a Win2K3 service pack perhaps, add this feature back to the Web Edition, just as they’re planning to turn it on by default in XP. It’s hard enough for us developers (most of whom are poor-to-middling admins at best) to keep our machines secure. The last thing we need is to find security features crippled in certain OS versions. I’m sure there are other places Microsoft can look to remove features that will encourage folks to consider the Standard or above editions of Server 2003. Security shouldn’t be one of them.

UPDATE: I want to be clear that in terms of best practices, I would absolutely agree with those who've commented that a web server should ideally not connect directly to the Internet, and should be behind a hardware firewall, ideally with another firewall between it and any internal network it's connected to. There are, however, cases where what's ideal isn't practical. What's most important is that the solution you choose to use is selected with an understanding of the tradeoffs in terms of cost, risk, and difficulty of implementation, so that in the end you have a sufficient level of security for your purposes at an acceptable cost.