Application Security for Visual C++.NET Developers
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Developers are under increasing pressure to create and maintain secure application environments, but it's harder to accomplish the task than many people think. For one thing, the cause of a security breach often isn't within the developer's control, even if the developer is blamed for the problem. For example, users often rely on passwords that are easy to guess; then, to make matters worse, they write down the passwords and display them prominently on their computer monitors. Many companies clamor for wireless applications today, although the technology is essentially hostile to security.
A single article can't cure all of your security woes. Even a book would have problems curing all of them. However, in this article I'll provide you with essential techniques to dramatically improve the security of your .NET applications. I'll also explain some of the choices in developing applications in the .NET environment.
Types of .NET Security
The .NET Framework borrows more than a few ideas from COM+. Among them is a combination of code access security and role-based security, which can ensure your application maintains a specific security environment.
Code access security controls what the code can do. The old Win32 API environment controlled the user and essentially didn't do much regarding the code. In contrast, NET lets you make sure the code can't do anything that would become a security issue later. For example, you can decide that an application has no need to access the hard drive, and build in that assumption. Even if the user has permission to access the hard drive, he can't access it using the application due to the limitation in the code. This kind of security ensures that a cracker can't gain access to an application, then force it to perform tasks that you decided the code shouldn't perform.
Role-based security controls caller actions (not just users, but any caller) based on the role the caller is fulfilling. This means that unlike Win32 API security, the caller's rights change based on the current situation. For example, a user who logs into an application from the Internet will likely be granted fewer rights than when he logs into the application from a local desktop. Role-based security (which works very much the same as the role-based security found in COM+) helps you control user access based on the actual needs of the user at the time. You don't create settings that could cause security holes in a given circumstance.
The .NET Framework implements security in two basic ways: declarative and imperative. Declarative security relies on attributes you add to the assembly, class, method, property, event, or other element. These attributes declare the requirements for using the application resource. Imperative security relies on security objects in the code. These objects define the security requirements for a specific code area, rather than a whole element. The sections that follow discuss how to use each kind of security in an application and describe the benefits of using each security type.