Microsoft's .NET development framework can help your Web apps perform securely.
Web services allow organizations to connect with other entities across disparate platforms, delivering the information they need, when they need it. Lifting up the hood, Web services include a complex mix of service-oriented architectures, semantic webs, XML, self-describing software and SOAP.
Utilizing Web services involves combining technology and techniques from different applications into a seamless architecture. To solve this problem, Microsoft created and embedded .NET into its operating systems and key Microsoft server applications to provide seamless integration across its entire suite of products.
Any time you hear about a new development platform that allows for dynamic downloads and remote execution of code, your security radar should perk up immediately. Web services open a world of dynamic connectivity and commerce, but they have also opened enterprises to attack because of vulnerable code and authentication infrastructure.
While security is still only as good as the human beings who adhere to sound security coding policies and practices, .NET provides built-in mechanisms for avoiding some of the common pitfalls. Let's examine some of the most important points.
Critical pieces of security in any application are making sure anyone requiring access is properly validated, giving them only the permissions they need and holding them accountable for their actions.
With most applications, control is applied when the user first authenticates via a username and password. They are usually not reauthenticated as they move deeper into authorized resources; so, if someone hijacks the session, they could have broad access to crack deeper into the enterprise.
In addition, even legitimate users tend to be given wider access than they need based on file permissions.
.NET addresses both problems by allowing programmers to build security into each level or tier of operation: Web server, programming language, operating system and database.
Typically, a user would first interact with the IIS Web server for basic authentication and limited access. .NET enables enterprises to build in security at each tier as the user works with additional resources, downloading mobile code to work with business and commercial apps and accessing data on the corporate back end.
Let's track this through the .NET environment. Users connect to a system via the Web server, where they can be validated with a certificate and basic password; they're granted authorization based on their subnet and given access to the application. The application can require a Passport account, perform URL validation and be assigned to certain .NET roles. After the application performs its checks, the server can also authenticate. Finally, when the user tries to access the data, Windows authentication is performed, and users are only given access to information based on object roles built into SQL server.
These roles are a differentiating point for .NET, helping developers tighten security and make it easier to manage.
The following are the basic methods that are used in the .NET framework:
Role (xx) to create a new role
Add (xx) to add a new role to the database
Update (xx) to update an existing role
The following code will assign a user to a new role:
SiteRole newUser =
new SiteRole( Context.User.Identity.Name );
Context.User = newUser;
Who--Or What--Are You?
In general, development platforms have provided rigid but strong access control designs, or flexible but potentially insecure access controls. .NET's access control architecture provides the flexibility to give users and applications the permissions they need--and nothing more. It does this in two basic ways:
Role-based access control addresses the gap between highly secure, rigid mandatory access control (MAC) architectures and flexible, insecure discretionary access control (DAC) platforms.
MAC is typical of older mainframe and some highly classified government systems. MAC is secure because the operating system controls all access between subjects and objects; every user is assigned a clearance level (e.g., "Secret"), and every object or file is assigned a classification level (e.g., "Top Secret"). This provides excellent control, but requires a lot of effort to implement and maintain. For that reason, it's not seen much anymore.
Most modern operating systems are based on DAC, in which an admin decides on permissions and assigns them to objects accordingly. DAC allows tremendous flexibility to control who has access to what, but it can be a security nightmare. While an organization should have a policy dictating that proper approvals are required before authorizing access, there's no assurance that it's done--or done properly. Moreover, since access permissions are assigned to the users, the admin has to make sure to revoke those privileges if they are transferred or terminated, in addition to assigning permissions to their replacements.
.NET overcomes this problem by allowing developers to assign built-in roles in the application to make sure the proper granularity of control is provided (see Figure 1). Since security needs to be built into the design from the beginning, this allows security to be part of the architecture and built within the code. Admins responsible for the application can determine who is assigned to a certain role; but it's the role, not the individual, that is granted permissions, strengthening security and tightening control.
Evidence-based access control builds an additional layer of security that attaches permissions to the code itself, limiting how it executes. In a Web environment, small mobile code has to be flexible enough to interact with other code, yet still be secure. One danger is that untrusted code from the Internet could be used to access other applications on the system, allowing it to compromise the system or get to privileged data.
With .NET, the code, just like the user, has security assigned to it, defining when and where it can run. When a piece of mobile code is downloaded, it must have the proper permission to run on the system. These controls check the code for evidence defined by security policy (such as a digital signature), validate it and enforce the restrictions under which it can operate.
Preventing Buffer Overflow
The code first attempts to parse the data and capture it from the user. The line that begins with "catch" detects the buffer overflow exception. The remaining lines will display an error message telling the user why the input has been rejected.
Security Made Easier
Security, until recently, hasn't been a primary concern for developers, who are under pressure to make sure that application features work properly and, most importantly, are delivered on schedule.
The result has been exploitable vulnerabilities, typically due to improper error-checking. For example, attackers can engineer a buffer overflow if the developer allocates "x" amount of memory but doesn't build in checks to ensure that amount isn't exceeded; attackers can enter in "x-plus" of information, overwrite the return pointer and cause their own malicious code to be executed. Or, if attackers can enter, say, more than the eight digits of a requested account number, they can simply append a semicolon and write in an additional statement to execute a SQL injection attack.
While you can write extensive error-checking code to stop this, the code can be complex, time consuming and prone to mistakes.
.NET makes it much easier to integrate error-checking into the program without extra coding by allowing you to set parameters on memory checks. Further, .NET will alert the programmer during code compilation if no parameters have been set (see Figure 2).
Consider another example of how .NET makes it easy for developers to build secure code from the start: Since HTTP is stateless, e-commerce applications require developers to add session IDs and mechanisms to track state. This creates extra work for the developer and a possible avenue for errors to be introduced.
With .NET, adding an attribute, "trace=true," at the page level will automatically track request details: trace information, control tree, session state, cookie collection, header collection and server variables.
There is, of course, much more to .NET security. Among its other strengths are built-in features to implement cryptography for both data at rest and data in transit.
But, while .NET provides the framework for strong and deep security on the Web, corporate polices and practices--not robust tools--are the keys to bulletproofing Web apps. If you make embedded security policies and testing parts of your development work flow, .NET will reward your efforts.