Programmering, juridik, punkrock och andra trivialiteter
This time, it’s about the recently discovered flaws in WinZip 9.0’s AES support and the importance of knowing exactly what it is that a security solution protects against.
Read it here (as always, in Swedish) Update: Better yet, read it
here, with nicer formatting and the possibility to comment.
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:
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.
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 (
[RegExAttribute("[a,e,i,o,u]",RegexOptions.None)]
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.
It looks like google has been cracked!
(Well, as long as your browser handles IDN, Internationalized domain names, at least :-))
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.