To build secure solutions that use remoting technology, you need to know the associated threats. The top threats to components that use remoting are:
Unauthorized access
Network eavesdropping
Parameter manipulation
Serialization
Figure 13.2 shows these threats.
Remote components that provide sensitive or restricted information should authenticate and authorize their callers to prevent unauthorized access. Weak authentication and authorization can be exploited to gain unauthorized access to sensitive information and operations.
Vulnerabilities that make your remoting solution susceptible to unauthorized access include:
No application level authentication because a custom Windows service host is used
No IPSec policies to restrict which computers can communicate with the middletier application server that hosts the remote components
No role-based authorization
No file authorization to restrict access to remoting endpoints
Trusting IPrincipal objects passed from the client
Countermeasures that may be implemented to prevent unauthorized access include:
Ensure that the front-end Web application authenticates and authorizes clients , and that communication to middle-tier application servers is restricted by using IPSec policies. These measures ensure that only the Web server can access the middle- tier application server directly.
Use ASP.NET to host remote components and use Windows authentication to restrict access to remote components.
Use the ASP.NET FileAuthorizationModule. This requires specific configuration and the creation of a physical file (.rem or .soap) to match the remoting endpoint.
Use role-based authorization to restrict access to remote components, remote component classes, and methods . This can be done by using URL authorization to control access to the remoting endpoint (.rem or .soap) or, at the class or method level, by using principal-permission demands.
Do not trust IPrincipal objects passed from the client unless the client is trusted. This is generally only the case if IPSec is used to limit the range of client computers.
With network eavesdropping, an attacker is able to view request and response messages as they flow across the network to and from the remote component. For example, an attacker can use network monitoring software to retrieve sensitive data. This might include sensitive application level data or credential information.
Vulnerabilities that can lead to security compromises from network eavesdropping include:
Basic authentication used over an unencrypted communication channel
No transport level encryption
No application level encryption
Countermeasures that may be implemented to prevent successful network eavesdropping attacks include:
Use transport level encryption such as SSL or IPSec. The use of SSL requires you to use an ASP.NET host and the HttpChannel . IPSec can be used with custom hosts and the TcpChannel .
Encrypt the request at the application level to provide privacy. For example, you could create a custom encryption sink to encrypt part of the entire message payload.
Parameter manipulation refers to the unauthorized modification of data sent between the client and remote component. For example, an attacker can manipulate the request message destined for the remote component by intercepting the message while it is in transit.
Vulnerabilities that can lead to parameter manipulation include:
Messages that are not digitally signed to provide tamperproofing
Message that are not encrypted to provide privacy and tamperproofing
Countermeasures that may be implemented to prevent successful parameter manipulation include:
Digitally sign the message. The digital signature is used at the recipient end to verify that the message has not been tampered with in transit.
Encrypt the message payload to provide privacy and tamperproofing.
Serialization is the process of converting an object's internal state to a flat stream of bytes. The remoting infrastructure uses the serialization services of the .NET Framework to pass objects between client and server. It is possible for malicious code to inject a serialized data stream to your server in order to coerce it into performing unintended actions. For example, malicious client-side code can initialize an object that, when de-serialized on the server, causes the server to consume server resources or execute malicious code.
The main vulnerability that can lead to successful serialization attacks stems from the fact that the server trusts the serialized data stream and fails to validate the data retrieved from the stream.
The countermeasure that prevents successful serialization attacks is to validate each item of data as it is deserialized on the server. Validate each field for type, length, format, and range.