Programming .Net Security: Writing Secure Applications Using C# or Visual Basic .Net - Softcover

Freeman, Adam; Jones, Allen

Softcover

ISBN 10: 0596004427 ISBN 13: 9780596004422

Publisher: O'Reilly Media, 2003

Synopsis

With the spread of web-enabled desktop clients and web-server based applications, developers can no longer afford to treat security as an afterthought. It's one topic, in fact, that .NET forces you to address, since Microsoft has placed security-related features at the core of the .NET Framework. Yet, because a developer's carelessness or lack of experience can still allow a program to be used in an unintended way, Programming .NET Security shows you how the various tools will help you write secure applications.The book works as both a comprehensive tutorial and reference to security issues for .NET application development, and contains numerous practical examples in both the C# and VB.NET languages. With Programming .NET Security, you will learn to apply sound security principles to your application designs, and to understand the concepts of identity, authentication and authorization and how they apply to .NET security. This guide also teaches you to:

• use the .NET run-time security features and .NET security namespaces and types to implement best-practices in your applications, including evidence, permissions, code identity and security policy, and role based and Code Access Security (CAS) use the .NET cryptographic APIs , from hashing and common encryption algorithms to digital signatures and cryptographic keys, to protect your data.
• use COM+ component services in a secure manner

If you program with ASP.NET will also learn how to apply security to your applications. And the book also shows you how to use the Windows Event Log Service to audit Windows security violations that may be a threat to your solution.Authors Adam Freeman and Allen Jones, early .NET adopters and long-time proponents of an "end-to-end" security model, based this book on their years of experience in applying security policies and developing products for NASDAQ, Sun Microsystems, Netscape, Microsoft, and others. With the .NET platform placing security at center stage, the better informed you are, the more secure your project will be.

About this title

About the Author

Adam Freeman is a professional programmer and the author of two early Java books, Programming the Internet with Java and Active Java, both published by Addison Wesley, as well as Java course materials. His recent experience architecting a green-field e-commerce platform has given him an in-depth understanding of the current security challenges facing those developing large scale distributed systems. Adam has previously worked for Netscape, Sun Microsystems and the NASDAQ stock exchange.

Allen Jones has been developing Windows solutions since 1990 and working with Windows NT and Win32 since 1993. He was one of the first MCSEs to qualify anywhere in the world. For the last 3 years, Allen has been developing e-commerce and security systems for large corporations and financial institutions. He is a former employee of Microsoft in both Australia and the UK and co-author, with Adam Freeman, of C# for Java Developers and .NET XML Web Services Step by Step , both from Microsoft Press.

Excerpt. © Reprinted by permission. All rights reserved.

CHAPTER 4 - The Lifetime of a Secure Application

This chapter looks at the way in which software security is integrated into the application lifetime and provides practical advice that will help you understand the content contained in later chapters.

We define the term secure application to mean an application designed with security in mind. We firmly believe that truly effective software security is achieved only when it is completely integrated into the application development process and is understood to be every bit as important as stability, performance, and feature completeness.

We recommend that you read this chapter twice. Read it now to help build a context for the technical content of the following chapters. When you have finished reading this book and have a better grasp of .NET security, read this chapter again, and consider how you can improve your development process to best implement the advice and recommendations we make.

Designing a Secure .NET Application
With few exceptions, a design is produced for an application before development begins; for smaller projects, the programmers may produce the design, which may be closely related to the implementation and contain low-level technical details. Larger projects usually engage an application architect to produce a more abstract design, leaving development of it’s components to individual development teams.

Security is an important part of the design process and cannot be left until the implementation phase. A fully integrated security policy will provide the greatest protection against your application being subverted and simplify the process of integrating security functionality into your code. You cannot retrofit a comprehensive security model into a design.

As the application designer, you need to have an understanding of the security capabilities provided by the platform that the application uses, in the same way that you must understand the features and functions of other components, such as databasesand operating systems. This knowledge is important even if you will not be involved in the implementation of the application. Where possible we have written each chapter so that an explanation of the security features offered by .NET is separate from the details of how to apply the functionality during coding; we recommend that architects working at even the most abstract levels should read the latter material.

The first step towards applying security to an application design is to identify the restricted resources and secrets, two concepts that we introduced in Chapter 1. Recall that a restricted resource is functionality to which you wish to control access to, and a secret is some piece of data that you wish to hide from third parties.

Identifying Restricted Resources
Restricted resources tend to fall into three categories:
Functional resources

Functional resources are the features that your application provides, for example, the ability to approve a loan within a banking application. These resources are easy to identify and are defined with the functional specification for the application.

External resources
External resources are those that underpin your application—for example, a database. Access to these resources should be coordinated with access to your functional resources, so that, for example, users who are unable to approve loans through a functional resource are not able to edit the database directly to achieve the same effect. This coordination proves the need for a wider security view that we introduced in Chapter 1.

Subversion resources
Subversion resources do not appear to be significant at first glance but can be used in conjunction with a functional or external resource in order to subvert your application or the platform on which your application executed. For example, one resource is the ability to write data to a file that is used by the operating system to enforce security policy.

Creating the list of restricted resources associated with your application is the foundation for understanding the trust relationships that you need to define, which we discuss in the next section. We make the following suggestions to assist in developing your skills in identifying restricted resources:

Consider the way your application interacts with other systems. Think carefully about the way in which your application depends on other services. Access to some resources may need to be restricted in order to protect other systems, even though they cannot be used to subvert your application.

Apply common sense. Do not follow the business specification slavishly—as an architect, you are responsible for designing an application that satisfies all of the business and technical objectives of the project, even those that are not stated explicitly. By applying some common sense, you can often identify resources that must be restricted in order to achieve the wider objectives of your organization.

Define and follow design standards. By applying a common design methodology to all of your projects, you can create patterns of functionality that are recognized easily as restricted resources.

Open your design to review. Do not work in isolation—ask for, and act on, the comments of your colleagues. Different people think in different ways, and we have found that reviewing application designs in groups is especially effective for identifying subversion resources.

About this edition

• Publisher: O'Reilly Media
• Publication date: 2003
• ISBN 10: 0596004427
• ISBN 13: 9780596004422
• Binding: Paperback
• Number of pages: 714