Tips for developing secure Microsoft apps
- By Jack Vaughan
[ADT's PROGRAMMERS REPORT, January 14, 2003] --
Microsoft's in-house development groups last year took a well-publicized
sabbatical to try to better ensure the security of the company's software. Best
practices developed during and since that ''trip to the woodshed'' have now led to
guides and suggestions the company offers to all developers working on its
Windows -- now .NET -- platform.
Mike Kass, product manager for Microsoft's .NET
Framework, recently spoke with Programmers Report about some early conclusions
Microsoft has reached about best developers' practices for security. Some arise
from work the company did as it prepared its entry for the popular
OpenHack security contest staged by eWeek
Kass said much effort has been addressed at a new code-access security
architecture. Developers, he said, should also begin to better acquaint
themselves with a whole series of cryptographic library elements Microsoft has
recently made available.
''The crypto [components] give you a broad, intuitive array of algorithms for
encrypting such things as database data, credit information or signing XML SOAP
messages with digital signatures,'' said Kass.
An important over-arching design element to consider, he noted, is
Microsoft's unfolding concept of ''role-based security,'' which defines how
developers implement important authorization and authentication functions.
Many readers are now familiar with the hurtful memory overruns that nefarious
hackers have instigated in unsafe Web-enabled systems. Kass points to ''type
verification processes,'' an important tool on the workbench of the developer who
must guard against such events.
Microsoft software builders, like others, have learned the importance of
careful input validation in a networked world. ''You must validate all input
data,'' advises Kass. ''You don't want to allow a script fragment to be accepted
when you are in fact looking for a social security number.
''In the past, you were on your own to make sure someone wasn't going to cram
128 bytes down your throat when you expected six [bytes],'' he added.
The .NET Common Language Runtime takes care of much of this effort now. ''It
will not load code if it exposes itself to this type of attack,'' said Kass.
Kass indicated that the new Microsoft philosophy will be clear to system
administrators. Microsoft has often put ease of use before security in the past.
''We're resetting the dial between ease of use and security,'' said Kass. They are
setting that imagined dial on security, he added. ''The system is now locked down
by default.'' Security before, in fact, was a selected function, rather than a
Microsoft recently released a whitepaper detailing the best security
practices as they are applied in the OpenHack security contest. See the link
''Building and Configuring More Secure Web Sites,'' a Microsoft
whitepaper, Dec. 2002, http://msdn.microsoft.com/library/en-us/dnnetsec/html/openhack.asp
''Building Secure ASP.NET Applications, Authentication, Authorization, and
Secure Communication,'' a Microsoft technical article, Nov. 2002, http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp
''Security and the Microsoft .NET Framework,'' a Microsoft technical article,
May 2002, http://msdn.microsoft.com/netframework/techinfo/articles/security/foundstone.asp
For other Programmer Report articles, please go to http://www.adtmag.com/article.asp?id=6265
Jack Vaughan is former Editor-at-Large at Application Development Trends magazine.