DotNetDoc - Daniel Egan

Security in today's world is evolving at a rapid pace. In the early days(86 -95) the threat was localized to individual workstations or individual LANS.

When the internet took over, things just exploded. Peer to Peer, Social Engineering, root kits, have been proliferated by the ease at which a hacker can transfer his/her virus/worm. This session talked about what has been, and what MS had in mind for the future. I will blog more about this later. He talked a lot about SDL (The security Development Lifecycle) . If you are interested, there is a great book on the subject.

Check it out on Amazon etc…

Happy programming

Doc

I received a question for a blog reader the other day complaining that they could not find the <machineKey> element in their Machine level web.config or their machine.config file. It was quite puzzling to them and thought that someone may have removed it.

Well, they were right and wrong. Someone did remove it, but that someone was Microsoft.

When .Net 2.0 came out, they did some "reconfiguring" of the config files. The first thing you will notice is that they moved most of the items that developers may want to change to a "Machine-Level" web.config file which can be found right alongside the machine.config file in the C:\WINDOWS\Microsoft.NET\Framework\v2.x\CONFIG folder. The second thing they did was remove elements from the machine.config file that were set at their default level. So if you don't want to change the machineKey, it will be set like the following.

You can find these settings in the web.config.comments file in the same directory.

You can of course override the defaults by adding the element to the machine.config, machine-level web.config, or a web.config in your application.

Happy programming

Doc

What it Code Access Security (CAS)? And why is it important to me?

Well, the simplest definition can be found in the name itself, what resources are you code allowed to access (Code Access Security). Will your code be allowed to access local files? The registry? SQL Server? These are questions that you should be asking yourself when you are designing your application but far too often, security is just an afterthought it the design process.

CAS is also sometimes called evidence-based security. To determine the access your code possesses, the Common Language Runtime (CLR) evidence it gathers about assemblies. This "evidence" is determined by a number of factors.

• Where did the code come from?
  • The site, URL, Zone, and Application Directory.
• What does the assembly contain?
  • Evidence Hash (Not the Strong Name Hash)

  The Hash evidence is simply a compact identifier that uniquely identifies a particular compilation of a component. The Hash evidence is added by the assembly loader to all assemblies and allows security policy to recognize particular builds of an assembly, even when the assembly version numbers have not changed.

  A hash value represents a unique value that corresponds to a particular set of bytes. Rather than referring to an assembly by name, version, or other designation, a hash value designates the assembly without ambiguity. Names are subject to collisions in rare cases where the same name is given to completely different code. Different variations of code can accidentally be marked with the same version. However, even changing a single bit results in a very different hash value.

  Hash values are a cryptographically secure way to refer to specific assemblies in policy without the use of digital signatures. A secure hash algorithm is designed so that it is computationally infeasible to construct a different assembly with the identical hash value by either an accidental or malicious attempt. By default, evidence from the SHA1 and MD5 hash algorithms is supported, although any hash algorithm can be used through GenerateHash.

• Who wrote the code :
  • Is the assembly Strongly Named? If so, what is the Strong Name?
  • Who is the publisher of the assembly? Is it digitally signed?

Evidence is where CAS starts. It is the who, what, where and why of your code. Let's talk about the about the different types of evidence.

The assembly loader works with the first four parts of the evidence, the Site, URL, ZONE, and Application directory. All four of these are derived by the CODEBASE URL. The URL evidence is the simplest since it is just be the URI of the assembly. The site evidence is derived from the URL. If the URL of the assembly is http://www.DotNetDoc.com/downloads/samplestuff.dll then the Site evidence will be www.DotNetDoc.com. But if the assembly is file based (C:\MyStuff\AndThings\samplestuff.dll) then this evidence will be blank. The Zone evidence also comes from the URL but is divided into five possible Zones :

• My Computer – All code loaded from local file system
• Intranet – All code loaded off of a remote file system using mapped drives
• Trusted – IE Mapped Trusted Sites
• Internet – All code loaded off the internet
• Not Trusted – IE Mapped Not Trusted Sites

The final location-based evidence is ApplicationDirectory. This evidence specifies the base directory for running the application. This is usually used to grant special permissions to assemblies that are run from the same location as the base application.