Quickies of the day

  • Google being irrational in the best of ways: Google expects to bring in $eB ($2,718,281,828) in their IPO. If you ask me, they’re worth at least $πB.
  • There has been a lot of buzz about the newest publication from Microft’s Pattern and Practices group, ”Improving .NET Application Performance and Scalability”. Since I’m not finished with ”Improving Web Application Security” yet, I’ve only skimmed this one, but it seems to approach it’s subject with similar throughoutness. However, can I ask for a PDF version?
  • Keith Pitty gathers introductory links to Java Server Faces, which for me as a .Net developer seem to correspond nicely to ASP.NET WebForms. While I really only focus on the .Net platform in my day-to-day development, I make a point of staying somewhat in touch in what happens in the Java community, if for no other reason to be able to contrast the platforms and knowing the strength and weaknesses in their differing approaches. Since I’ve been looking into Code access security, I should probably read up a little on the Java security manager. After all, the Java camp has been thinking about these issues for ten years now.
  • Omar Shahine tells how to get PDF’s to open in Acrobat Reader instead of in the browser. As added bonus, he gives pointers on how to make recent versions of Acrobat Reader start quicker.
  • L-G from Entombed is apparently a guest on Eurodisco star E-Type’s new record. E-Type has already enlisted Motörhead drummer Mikey Dee, at least for performances, but I still don’t think this is going to get him respect in heavy metal circles.

Quickies of the day

  • Anil John writes about developing ASP.NET applications that run under Partial Trust. The whole Code Access Security framework in .Net is a complex beast, and I fear that most developers never will learn enough to actually use it properly, leaving them with applications that appear to be secured against malicious in-process code, but still can be vulnerable to ”luring attacks”. And if you let a single malicious assembly run with FullTrust, it’s Game over for your entire host process, as explained by Keith Brown in Beware of Fully Trusted Code. As Anil says, chapter 6-9 in Improving Web Application Security: Threats and Countermeasures is recommended reading. As a sidenote, are there any MVP’s that specialize in Code Access Security?
  • Tim Bray writes about the higher level web services specifications, and how the law of leaky abstractions work against them. ”[…]; applications that try to abstract away the fact that they’re exchanging XML messages will suffer for it”
  • Anil Dash warns against yet another scenario where Word’s ”Track Changes” feature can come back and bite you in the ass. I once recieved a press release in .doc format that had Track Changes enabled in such a way that they didn’t show up on screen, but did when you printed it. Oops indeed.
  • Jon Udell observes that developers still have a lot to learn when it comes to internationalizing applications, and compares us with 13-th century French Artisans. I don’t think I have linked to Joel Spolsky’s excellent Unicode primer yet, and even if I have, its such a recommended reading that I should do it again. I did a small project involving UTF-8 to Windows-1256 (Arabic) conversion on a low level a while ago, and it was most illuminating.
  • My column on the Smalltalk heritage on IDG has spawned a small debate about ”industry languages” such as Java and C# compared to more dynamic, ”cutting edge” languages like Smalltalk and Python. My take on the debate is that if you want to get stuff done togheter with other developers that may not be on the same level as you, C# and Java will get you there with the lowest amount of risk. For single-developer projects, or for small projects that everyone involved are really bright, Python and similarly dynamic languages (including Smalltalk, Lisp/Scheme, and even Perl) can get you there faster, while allowing you to have more fun along the way.
  • Ted Neward (By the way, it’s cool that a MVP’s RSS feed URL ends in .jsp :-)is involved in a debate over a set of security guidelines (subscription required) published in Java Developers Journal. Ted observes that for many of threats that the guidelines seek to guard against to even be theoretically exploitable, the attacker already must have greater access than he stands to gain by exploiting the vulnerability. This observation is similar to Peter Torr’s that VBA and Outlook’s object model does not really increase the attack surface, since, for an attacker to make use of them, he must already have full access to the machine: ”The problem isn’t that you have knives or saucepans or shoes in your house; it’s that the burglar keeps getting inside!”
  • Cedric Beust puts his money where his mouth is; disappointed by JUnit, he writes his own testing framework, TestNG.
  • Brad Adams gets DDJ to allow republising Steven Clarke’s article on Measuring API Usability.

Quickies of the day

  • Jiri has an interesting comparison between the state of infrastructure security as opposed to application security.
  • Michael Howard has the slides from what appear to be an excellent presentation about Secure coding issues up (by way of Sergey Simakov
  • The widely-talked-about paper from Paul Watson on the TCP reset vulnerability that threatened to destroy the internet last week is now online.
  • Charles Miller discusses where bugs come from, and why unit testing only will catch a part of them.
  • Mr Ed from Hacknot asks all developers to spare a thought for the next guy that will change your code — it could be you.

Also, with all the recent book reviews all over the .Net blogosphere, I broke down and went crazy on Amazon. The following books should soon be here:

Microsoft PAG on ”Improving Web Application Security”

Anil John points me to the Microsoft Pattern and Practices site. I’ve stumbled over the ”Application blocks” examples that they have up once or twice, but I never went to their front page to see what it’s all about. I took a glance at the ”Improving Web Application Security: Threats and Countermeasures” guide, and… godDAMN this is a comprehensive guide (900+ printed pages, not much filler) to just about everything you need to know about secure web development on the Microsoft platform, including how to harden the base services (like IIS and MS SQL Server) your application uses. Much of the stuff (like the chapters on Code Access Security and Data access) is useful in non-web development as well. So far I’ve only skimmed through it, but it looks to be a must-read.

Interesting validation framework

The most important part of developing secure (and robust) systems is to validate all input that comes from the outside (and for large systems, even between components). However, writing validation code isn’t usually very fun, and so like many other good practices, validating your input sometimes is neglected. If you develop in ASP.NET or Winforms, there are some validation controls that help you a little bit, but they don’t provide out-of-the box protection against XSS attacks, SQL injection, UTF-8 canonicalization problems and so on. To guard against things like that you need to write your own validation code.

In this article, Mathew Nolton describes a validation framework that lets you use custom attributes to do most of the heavy lifting, essentially providing declarative validation. This stuff is very cool, and another fine example of just how useful custom attributes in .Net can be.

I think the following method signature gives you an idea of how it works:

public void SomeMethod ( 
                   string someParameter)

Together with some boilerplate code (which could be autoinserted by your editor), this ensures that if someParameter ever contains anything but the letters a,e,i,o,u, a ValidationException is thrown.

Keith Brown on managed code security

This is
an interesting article about code security in the CLR, and how little teeth the declarative
security features in the CLR have when it’s running fully trusted code. I did know
that some naughty things (like calling private methods) was possible using reflection,
but I was under the assumption that IStackWalk.Deny() trumphed
most anything. In the article, Keith shows how to malicious code can get around that
and also AppDomain separation — if the assembly it’s in is marked as FullTrust.

Fully trusted code can get around all of the CLR’s built-in security
features. That’s why it’s called fully trusted – it must be trusted to do the
right thing.