Step 3. Decompose the Application

In this step, you break down your application to create a security profile for the application based on traditional areas of vulnerability. You also identify trust boundaries, data flow, entry points, and privileged code. The more you know about the mechanics of your application, the easier it is to uncover threats. Figure 3.4 shows the various targets for the decomposition process.

Figure 3.4: Targets for application decomposition

During this step, you perform the following tasks :

• Identify trust boundaries .

• Identify data flow .

• Identify entry points .

• Identify privileged code .

• Document the security profile .

Identify Trust Boundaries

Identify the trust boundaries that surround each of the tangible assets of your application. These assets are determined by your application design. For each subsystem, consider whether the upstream data flows or user input is trusted, and if not, consider how the data flows and input can be authenticated and authorized. Also consider whether the calling code is trusted, and if it is not, consider how it can be authenticated and authorized. You must be able to ensure that the appropriate gatekeepers guard all entry points into a particular trust boundary and that the recipient entry point fully validates all data passed across a trust boundary.

Start by analyzing trust boundaries from a code perspective. The assembly, which represents one form of trust boundary, is a useful place to start. Which assemblies trust which other assemblies? Does a particular assembly trust the code that calls it, or does it use code access security to authorize the calling code?

Also consider server trust relationships. Does a particular server trust an upstream server to authenticate and authorize the end users, or does the server provide its own gatekeeping services? Also, does a server trust an upstream server to pass it data that is well formed and correct?

For example, in Figure 3.3, the Web application accesses the database server by using a fixed, trusted identity, which in this case is the ASPNET Web application process account. In this scenario, the database server trusts the application to authenticate and authorize callers and forward only valid data request data on behalf of authorized users.

Note  

In a .NET Framework application, the assembly defines the smallest unit of trust. Whenever data is passed across an assembly boundary ” which by definition includes an application domain, process, or machine boundary ” the recipient entry point should validate its input data.

Identify Data Flow

A simple approach is to start at the highest level and then iteratively decompose the application by analyzing the data flow between individual subsystems. For example, analyze the data flow between a Web application and an Enterprise Services application and then between individual serviced components .

Data flow across trust boundaries is particularly important because code that is passed data from outside its own trust boundary should assume that the data is malicious and perform thorough validation of the data.

Note  

Data flow diagrams (DFDs) and sequence diagrams can help with the formal decomposition of a system. A DFD is a graphical representation of data flows, data stores, and relationships between data sources and destinations. A sequence diagram shows how a group of objects collaborate in terms of chronological events.

Identify Entry Points

The entry points of your application also serve as entry points for attacks. Entry points might include the front-end Web application listening for HTTP requests . This entry point is intended to be exposed to clients . Other entry points, such as internal entry points exposed by subcomponents across the tiers of your application, may only exist to support internal communication with other components. However, you should know where these are, and what types of input they receive in case an attacker manages to bypass the front door of the application and directly attack an internal entry point.

For each entry point, you should be able to determine the types of gatekeepers that provide authorization and the degree of validation.

Logical application entry points include user interfaces provide by Web pages, service interfaces provided by Web services, serviced components, and .NET Remoting components and message queues that provide asynchronous entry points. Physical or platform entry points include ports and sockets.

Identify Privileged Code

Privileged code accesses specific types of secure resources and performs other privileged operations. Secure resource types include DNS servers, directory services, environment variables , event logs, file systems, message queues, performance counters, printers, the registry, sockets, and Web services. Secure operations include unmanaged code calls, reflection, serialization, code access security permissions, and manipulation of code access security policy, including evidence.

Privileged code must be granted the appropriate code access security permissions by code access security policy. Privileged code must ensure that the resources and operations that it encapsulates are not exposed to untrusted and potentially malicious code. .NET Framework code access security verifies the permissions granted to calling code by performing stack walks. However, it is sometimes necessary to override this behavior and short-circuit the full stack walk, for example, when you want to restrict privileged code with a sandbox or otherwise isolate privileged code. Doing so opens your code up to luring attacks, where malicious code calls your code through trusted intermediary code.

Whenever you override the default security behavior provided by code access security, do it diligently and with the appropriate safeguards. For more information about reviewing code for security flaws, see Chapter 21, "Code Review." For more information about code access security, see Chapter 8, "Code Access Security in Practice" and Chapter 9, "Using Code Access Security with ASP.NET."

Document the Security Profile

Next, you should identify the design and implementation approaches used for input validation, authentication, authorization, configuration management, and the remaining areas where applications are most susceptible to vulnerabilities. By doing this, you create a security profile for the application.

The following table shows what kinds of questions to ask while analyzing each aspect of the design and implementation of your application. For more information about reviewing application architecture and design, see Chapter 5, "Architecture and Design Review."

Table 3.2: Creating a Security Profile

Category	Considerations
Input validation	Is all input data validated ? Could an attacker inject commands or malicious data into the application? Is data validated as it is passed between separate trust boundaries (by the recipient entry point)? Can data in the database be trusted?
Authentication	Are credentials secured if they are passed over the network? Are strong account policies used? Are strong passwords enforced? Are you using certificates? Are password verifiers (using one-way hashes) used for user passwords?
Authorization	What gatekeepers are used at the entry points of the application? How is authorization enforced at the database? Is a defense in depth strategy used? Do you fail securely and only allow access upon successful confirmation of credentials?
Configuration management	What administration interfaces does the application support? How are they secured? How is remote administration secured? What configuration stores are used and how are they secured?
Sensitive data	What sensitive data is handled by the application? How is it secured over the network and in persistent stores? What type of encryption is used and how are encryption keys secured?
Session management	How are session cookies generated? How are they secured to prevent session hijacking? How is persistent session state secured? How is session state secured as it crosses the network? How does the application authenticate with the session store? Are credentials passed over the wire and are they maintained by the application? If so, how are they secured?
Cryptography	What algorithms and cryptographic techniques are used? How long are encryption keys and how are they secured? Does the application put its own encryption into action? How often are keys recycled?
Parameter manipulation	Does the application detect tampered parameters? Does it validate all parameters in form fields, view state, cookie data, and HTTP headers?
Exception management	How does the application handle error conditions? Are exceptions ever allowed to propagate back to the client? Are generic error messages that do not contain exploitable information used?
Auditing and logging	Does your application audit activity across all tiers on all servers? How are log files secured?