Application Security Testing: An Integral Part of DevOps
This article is a sample chapter (Chapter 1) from ASP.NET Professional Secrets, written Bill Evjen, and published by Wiley.
If you are new to .NET—Welcome!
If you are a .NET Framework 1.0 veteran—Welcome to .NET version 1.1!
.NET 1.0 was introduced with tremendous excitement. It was original, answered many developers' problems, and truly leap-frogged any of the other technologies out there—especially in the realm of browser-based Internet application development—or ASP.NET.
.NET 1.1 and ASP.NET 1.1 are minor releases and should not be considered substantially different versions from 1.0. The next major revision of .NET and ASP.NET will come with the release of version 2.0.
This chapter introduces the .NET Framework 1.1 and also shows you what's new in ASP.NET 1.1.
Welcome to .NET
Every so often, a technology company needs to step back from itself, look at what it is trying to achieve, and then determine whether it needs to try a different approach. Microsoft did this as it stood back from the COM world it had created and asked itself, "Is there a better way?" The .NET Framework is this better way.
.NET is confusing to many people because the Microsoft marketing folks took hold of the name and started applying it to every product that Microsoft produced. .NET had almost nothing to do with many products that acquired the .NET moniker. This problem is slowly being corrected. More products are now coming from Microsoft without .NET in their titles.
Microsoft's short definition of .NET is Microsoft's platform for building XML Web services. But the .NET that I am talking about (and the .NET that you should be focused on understanding) is the .NET Framework itself.
Microsoft's .NET Framework is a new computing platform built with the Internet in mind, but without sacrificing the traditional desktop application platform. The Internet has been around for a number of years now, and Microsoft has been busy developing technologies and tools that are totally focused on it. These earlier technologies, however, were built on Windows Distributed InterNet Applications Architecture (DNA), which was based on the Component Object Model (COM). Microsoft's COM was in development many years before the Internet became the force that we know today. Consequently, the COM model has been built upon and added to in order to adapt it to the world of the Internet.
The .NET Framework enabled Microsoft to build everything from the ground up with the Internet in mind. Therefore, the .NET Framework focuses heavily on Internet-enabling your applications, whether these applications are thin-client or thick-client applications. Building a new platform from the ground up also allowed Microsoft to take a close look at how developers developed. Even more importantly, Microsoft began examining how to correct the problems developers experience and how to make them more productive in this new environment.
.NET is a collection of tools, technologies, and languages that all work together in a framework to provide the solutions necessary for easily building and deploying truly robust enterprise applications. These .NET applications can also communicate with one another and provide information and application logic, regardless of platforms and languages.
Figure 1-1 shows an overview of the structure of the .NET Framework.
Figure 1-1: The .NET Framework.
You might have seen this simple diagram of the .NET Framework before, but take a closer look at it now. Consider the .NET Framework as something that sits on an operating system. Presently, the operating systems that can take the .NET Framework include Windows Server 2003, Windows XP Professional, Windows 2000, and Windows NT.
Note: Support for the .NET Framework on Windows NT is limited to functioning as a client. Windows NT does not support the Framework as a server.
At the bottom layer of the .NET Framework is the Common Language Runtime (CLR). The CLR is the engine that manages the execution of the code, takes care of object management, provides security, and so much more.
The next layer up from the CLR is the .NET Framework Base Class Libraries (BCL). The BCL layer contains classes, value types, and interfaces that are often used in the development process. The many classes in the BCL are organized into a series of namespaces.
The third layer of the .NET Framework includes the Windows Forms model (more on that shortly), along with the area that is the primary focus of this book—ASP.NET. Don't think of ASP.NET as the latest version of Active Server Pages—the one that comes after ASP 3.0. Instead, think of it as a dramatic new shift in Web application development. Using ASP.NET, it's now possible to build robust Web applications that are even more functional than Win32 applications of the past, a difficult feat because of the stateless nature of the Internet. ASP.NET offers a number of different solutions to overcome the traditional limitations on the types of possible applications. The ASP.NET section of the .NET Framework is also where the XML Web services model resides.
As I mentioned a moment ago, ASP.NET shares the top layer of the .NET Framework with Windows Forms applications. These are the traditional .exe applications, or Win32 thick-client applications. The programming models of the ASP.NET world and the Windows Forms world are quite similar, and these two models use the same objects from the Framework to accomplish their tasks. If you become a good ASP.NET programmer, you also become a good Windows Forms programmer. Interestingly enough, because the models are so similar, you can build a class that you can use in either your ASP.NET application or in a Windows Forms application.
Looking to the future
The .NET Framework is focused on how people will use technology in the future. One view (held not only by Microsoft) says that all devices and applications will one day be connected to the Internet. When this day arrives, people won't use the Internet just for the browser-based applications as they currently do, but also for telephones, televisions, microwaves, Xbox and PlayStation units, and much more (see Figure 1-2). All these devices connected by the Internet can't possibly be built on a single platform. The world will continue to have multiple platforms and languages at its disposal for a long time to come. Consequently, we need a common language that can communicate with the various platforms, applications, and devices.
XML and SOAP are the common languages now facilitating communication among platforms, applications, and devices. By using these languages, devices can communicate over the Internet in an easy and straightforward manner.
Microsoft enables you to start bringing this disparate but connected vision to reality with the .NET Framework. By building XML Web services, you are expressing objects and using XML and SOAP to communicate the object's data or the application logic that it might provide.
Cross-Reference: XML Web services are considered part of the ASP.NET model and are covered in Part VI of this book.
You can also use your ASP.NET applications to consume data or application logic from other Web services on the Internet, regardless of the language or platform used in the creation of these Web services. Over time, more and more connections of applications with remote objects will use the XML Web services model in the .NET Framework.
Figure 1-2: One Web service for multiple clients.
Microsoft's .NET solution
Because of the prospect that the universe of devices and applications will be placed on the same medium and will be able to communicate with one another using a common language, Microsoft developed the .NET Framework. Developers using this platform can build their applications to take advantage now of this vision of the future.
Before the .NET Framework came along in 2002, Microsoft offered quite a number of tools and technologies for building a wide variety of applications. As a developer, you could choose the environment, language, or tool appropriate for what you were trying to accomplish.
For example, if you wanted to quickly build a thick-client application, you used Visual Basic. If you wanted to build low-level applications that gave you granular access to the platform, you used C++. If you wanted to build browser-based applications, you used Active Server Pages (ASP).
With the .NET Framework, Microsoft has taken the best of all these different worlds and merged them into a single environment—the .NET world, as shown in Figure 1-3.
Figure 1-3: A unified model.
Because of this new unified model, you need only one environment, one platform, and any .NET language to build any .NET application. It doesn't matter if the application is a desktop application, a browser-based application, a component, or even a driver. You now have a single environment to do all this work.
One of the main objectives of the Framework is to provide a simplified development model that eliminates a lot of the plumbing required to develop in the past. The .NET Framework gives developers more power over their applications. This framework uses the latest in Internet standards such as XML, SOAP, and HTTP. The applications that you build on this platform are easier to deploy and maintain.
Instead of multiple development environments for building various types of applications, Microsoft provides a single development environment to build any type of .NET application. This development environment is Visual Studio .NET. It's the development environment that I recommend you use with this book as you build and work with your .NET applications.
Visual Studio .NET enables you to build your ASP.NET applications in a code-only manner (writing code directly) or by dragging and dropping objects onto a design surface. You can also use Visual Studio .NET to build thick-client applications or Windows Forms and to build your classes, components, and everything else you need.
Another development environment offered by Microsoft is the ASP.NET Web Matrix. This free tool is available from the ASP.NET Web site at www.asp.net. It is a great tool to help you get a feel for building Web applications. Unlike Visual Studio .NET, however, the ASP.NET Web Matrix limits you to building only ASP.NET applications and XML Web services. You can't build any Windows Forms applications using the Web Matrix.
Cross-Reference: You learn about the Visual Studio .NET environment in Chapter 2 and the ASP.NET Web Matrix environment in Chapter 3.
Note: Besides these two Microsoft IDEs, other IDEs are capable of building .NET applications. One of the more popular development environments is Macromedia's Dreamweaver MX. This IDE enables you to build ASP.NET applications as well as many other types, such as PHP and ColdFusion applications.
You can also build ASP.NET applications by using Notepad and the compilers provided with the .NET Framework. In fact, you can type much of the code from this book into Notepad to build your ASP.NET applications.
The .NET languages
When developing on the Microsoft platform in the past, you chose the development language based on the type of application you wanted to build.
The .NET Framework has completely changed this scenario for us. The .NET Framework enables you to build any type of application or object that can be used in the .NET platform, and you can also use any of the .NET languages to build these applications.
For a language to be part of the .NET Framework, a language has to follow certain rules. The biggest and most important rule for inclusion is that the language must be an object-oriented language. Microsoft provides five languages with the .NET Framework: Visual Basic .NET, C#, C++.NET, JScript .NET, and now J#.
You now have a choice of which language you are going to use to build your ASP.NET applications. For instance, you are not limited to just using Visual Basic .NET to build your browser-based applications; you can also use C#, JScript .NET, or even J# to build a Web-based application.
Whenever this idea is presented, people always ask: Which is the better language to use? Does one language provide better performance than another?
The answer to both these questions is an emphatic NO. There isn't one language that is better than another. They all have access to the same classes and capabilities that are provided with the .NET Framework. If there is no difference in which language you can use to build your .NET applications, it then becomes simply a matter of style when deciding which of the languages to use.
In addition to the languages that are provided with the install of the .NET Framework 1.1, quite a number (more than 40) of third-party languages are capable of being used in the .NET platform to build your .NET applications. For instance, you can also build ASP.NET applications using COBAL or Perl. To use either of these applications, however, you must install the language yourself because neither is provided with the default install of the .NET Framework.
This book focuses on the two most popular .NET languages: Visual Basic .NET and C#.
A Closer Look at the .NET Foundation
The foundation of the .NET platform is the .NET Framework, which I introduced in the preceding section. The .NET Framework sits on top of the operating system and is made up of two parts, the Common Language Runtime and the Base Class Libraries. Each of these parts plays an important role in the development of .NET applications and services.
The Common Language Runtime
Many different languages and platforms provide a runtime, and the .NET Framework is no exception. Its runtime, however, is quite different from most.
The Common Language Runtime (CLR) in the .NET Framework manages the execution of the code and provides access to a variety of services that make the development process easier.
The CLR has been developed to be far superior to previous runtimes, such as the VB runtime, by providing the following functionality:
- Cross-language integration
- Code access security
- Object lifetime management
- Debugging and profiling support
Code that is compiled and targeted to the CLR is known as managed code. Managed code has the metadata needed for the CLR to provide the services of multilanguage support, code security, object lifetime management, and memory management.
Note: Metadata is basically data about data or a description of the contents of a .NET component. This metadata is stored within the assembly manifest. In the past, it was difficult for components written in competing languages to interact with one another. The .NET Framework uses metadata so that .NET components are self-describing, making them easy to interoperate with other components.
Compilation to managed code
When creating a .NET application, use one of the .NET languages. After the code is written, you (or Visual Studio .NET) uses the language's compiler to compile the code down to Microsoft Intermediate Language (IL). IL is a CPU-independent set of instructions that can easily be converted to native code. The metadata (the self-describing information about the object created) is also contained within the IL. This is illustrated in Figure 1-4. You can see from the diagram of the compilation process that it really doesn't matter which language you are using with the .NET platform. In the end, each .NET language compiles down to the same type of object.
The IL is CPU-independent, which means that the object created by the compiler is not dependent upon the computer that created it. It, therefore, can be moved at this stage from the computer that created it to any other computer that has the .NET Framework on it. And because this IL object is self-describing, it doesn't need to be registered in the Windows registry. You only have to copy it to the hard drive of the computer—that's it. It makes XCopy possible with .NET applications.
To run the application from here, it actually needs to be compiled even further—down to native code. This is handled by the .NET Framework's JIT compiler. The IL contains everything that is needed to do this, such as the instructions to load, call methods, and a number of other operations.
Figure 1-4: Managed-code execution process.