Share via

Web Services on Devices Security (Windows Embedded CE 6.0)

  • Article

1/6/2010

Applies to Windows Embedded CE 6.0 R2

The Microsoft Web Service on Devices API (WSDAPI) is compliant with the Devices Profile for Web Services (DPWS) specification. For information about Devices Profile for Web Services, see the DPWS specification at this Web site. The Web Services on Devices stack and API (WSDAPI) implementation provides the following discovery mechanisms, each of which can allow a client application to find and access a device host.

  • Service availability multicast
    The device host uses UDP to multicast a service availability message. This message cannot make use of a secure channel, so this type of service discovery does not support authentication. The WSDAPI implementation does not offer authentication, however, the WS-Discovery specification provides an avenue for authentication. Typically, the multicast message does not traverse IP routers, so only the client applications on the same subnet as the device host can receive the service availability multicast.
  • Directed discovery
    The client application uses TCP to send a directed discovery message. This message can make use of a secure channel, so this mechanism supports authentication. Also, these messages can traverse an IP router, so this mechanism allows client applications to discover a device hosts that is located on a remote subnet.

Responsible use of WS-Discovery requires understanding of the security assertions and vulnerabilities built into the protocol. When planning Web Services on Devices deployment, consider the implications of the following design features:

  • When a client application searches for a known device host, a malicious device host can respond with a spoofed WS-Discovery response. If the client application receives the spoofed response before it receives a response from a legitimate device host, the client application treats the malicious device host as a legitimate device host. To avoid this risk, configure the device host and client application to require the use of a secure channel.
  • Web Services on Devices applications are designed to run on a trusted network that is located behind a firewall. If the device host is located on an untrusted network, the device host is at risk from any untrusted client application. This is true whether using multicast discovery on an untrusted subnet, or using unauthenticated, directed discovery on a larger untrusted network, such as the Internet.
  • When using multicast discovery, currently, there is no mechanism for authentication. When using directed discovery, WSDAPI supports authentication using a secure channel, but the developer chooses whether to make use of this ability. If you deploy a device host on an untrusted network, and the device host does not require the use of secure channel for authentication, an untrusted client application can access the device host. Similarly, if you start a client application that does not use the secure channel for authentication, the client application can receive availability advertisements from an untrusted device host. If a malicious user compromises the security of the WSD-enabled device, that user could gain access to other resources on the device, or resources elsewhere on the trusted network.
  • If a malicious user compromises the security of the device host, that user could gain access to other resources on the device, or resources elsewhere on the trusted network.
  • Web Services on Devices is extensible. A security defect in an extension could compromise the security of the device host, and potentially allow a malicious user to access other resources on the device, or resources elsewhere on the trusted network.

Best Practices

  • Secure the device host using the same techniques as apply when securing a Web server
    For more information, see Web Server Security.

  • Use a secure channel to enable authentication and to protect message data, especially if the device manages sensitive information
    The TLS/SSL protocol enables authentication, and it helps to protect data from packet-sniffing by anyone with physical access to the network. For more information, see Web Server Authentication and Permissions. For a brief overview of SSL, see SSL to Enhance Security of Network Communication. For information about SSL support, see SSL Support.

  • Implement the secure channel using only a trusted certificate authority (CA) root certificate
    To implement a secure channel, the administrator installs a CA root certificate. Thereafter, every application trusts that CA root certificate, including the client application, but also other applications that support TLS connections running on the device host. If the WSD-enabled device manages sensitive information, configure the device to use a static IP address.
    Using a static IP address minimizes the opportunity for an untrusted device to impersonate a trusted device.

  • Configure the device to use a static IP address
    If the device host has access to sensitive information, using a static IP address minimizes the opportunity for an untrusted device host to impersonate a trusted device host. The Device ID should be a URL and not a logical address.

  • Limit deployment to a controlled networking environment
    Deploy Web Services on Devices on a private network that is protected by a firewall. Do not deploy Web Services on Devices on any type of open network. For information about configuring an IP firewall to properly control traffic destined for the internal network, see the documentation for your firewall.

  • Limit the number of physical network interfaces on the device host
    When the client application starts on a multihomed device, the Web Services on Devices stack uses every physical interface over which it can communicate. Such interfaces typically include Ethernet adapters and WiFi adapters. You cannot configure the stack to change or disable this behavior. To prevent client applications from learning about device interfaces that lead to other networks, remove the other interfaces from the device.

  • Limit the size of messages from the client application
    Setting a limit helps to prevent a denial of service when the device memory resources are depleted.

  • Permit HTTPD access only from trusted applications
    Each service has a DEVFLAGS_TRUSTEDCALLERONLY flag in the corresponding services root registry key. If you set this value, only trusted applications can start, stop, and refresh the service or eventing endpoints. The following example shows this type of setting for any HTTPD service.

    [HKEY_LOCAL_MACHINE\Services\HTTPD]
Flags=dword:10000

    To remove the DEVFLAGS_TRUSTEDCALLERONLY flag for a service, set the corresponding Flags value to 0 in the registry. For more information, see Services.exe Registry Settings.

See Also

Concepts

Web Server Security
Web Server Authentication and Permissions

Other Resources

Web Services on Devices
Web Server (HTTPD)
Enhancing the Security of a Device
SSL to Enhance Security of Network Communication