WCF Security Best Practices

From OWASP
Revision as of 23:01, 15 May 2008 by Mroxberr (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

From WCF 3.5 Security Guidelines J.D. Meier , Jason Taylor , Prashant Bansode , Carlos Farre, Madhu Sundararajan, Steve Gregersen.

The following are guidelines for Web services created with Windows Communication Foundation (WCF) 3.5. They are based on principles where possible. The recommendations are also as contextual as possible, but abstracted for reuse. Use them as a starting point, but you will likely need to tailor for your scenario:

Design Considerations

   * Design your service as a wrapper
   * If you are coming from ASMX then use basicHttpBinding to support your existing clients
   * If you are coming from DCOM then, use netTcpBinding
   * If your clients are deployed within intranet then choose transport security
   * If your clients are deployed over the internet then choose message security
   * Know your Authentication options
   * Know your binding options
   * If you need to Interop with non MS clients, use basicHttpBinding or wsHttpBinding
   * If your non-MS clients understand WS stack, use wsHttpBinding


Auditing and Logging

   * Use WCF auditing to audit your service
   * If non-repudiation is important, consider setting SuppressAuditFailure property to false
   * Use message logging to log operations on your service
   * Instrument for user management events
   * Instrument for significant business operations
   * Protect log files from unauthorized access
   * Do not log sensitive information


Authentication

   * Know your authentication options
   * Use Windows Authentication when you can
   * If you support non-WCF clients using windows authentication and message security, consider using the Kerberos direct option
   * If your users are in AD, but you can’t use windows authentication, consider using username authentication
   * If you are using username authentication, use Membership Provider instead of custom authentication
   * If your users are in a SQL membership store, use the SQL Membership Provider
   * If your users are in a custom store, consider using username authentication with a custom validator
   * If your clients have certificates, consider using client certificate authentication
   * If your partner applications need to be authenticated when calling WCF services, use client certificate authentication.
   * If you are using username authentication, validate user login information
   * Do not store passwords directly in the user store
   * Enforce strong passwords
   * Protect access to your credential store
   * If you are using Windows Forms to connect to WCF, do not cache credentials


Authorization

   * If you store role information in Windows Groups, consider using the WCF PrincipalPermissionAttribute class for roles authorization
   * If you use ASP.NET roles, use the ASP.NET Role Provider
   * If you use windows groups for authorization, use ASP.NET Role Provider with AspNetWindowsTokenRoleProvider
   * If you store role information in SQL, consider using the SQL Server Role Provider for roles authorization
   * If you store role information in ADAM, use the Authorization Store Role Provider for roles authorization
   * If you need to authorize access to WCF operations, use declarative authorization
   * If you need to perform fine-grained authorization based on business logic, use imperative authorization


Binding

   * If you need to support clients over the internet, consider using wsHttpBinding.
   * If you need to expose your WCF service to legacy clients as an ASMX web service, use basicHttpBinding
   * If you need to support remote WCF clients within an intranet, consider using netTcpBinding.
   * If you need to support local WCF clients, consider using netNamedPipeBinding.
   * If you need to support disconnected queued calls, use netMsmqBinding.
   * If you need to support bidirectional communication between WCF Client and WCF service, use wsDualHttpBinding.


Configuration Management

   * Use Replay detection to protect against message replay attacks
   * If you host your service in a Windows service, expose a metadata exchange (mex) binding
   * If you don’t want to expose your WSDL, turn off HttpGetEnabled and metadata exchange (mex)
   * Manage bindings and endpoints in config not code
   * Associate names with the service configuration when you create service behavior, endpoint behavior, and binding configuration
   * Encrypt configuration sections that contain sensitive data


Exception Management

   * Use structured exception handling
   * Do not divulge exception details to clients in production
   * Use a fault contract to return error information to clients
   * Use a global exception handler to catch unhandled exceptions


Hosting

   * If you are hosting your service in a Windows Service, use a least privileged custom domain account
   * If you are hosting your service in IIS, use a least privileged service account
   * Use IIS to host your service unless you need to use a transport that IIS does not support


Impersonation and Delegation

   * Know the impersonation options
   * If you have to flow the original caller, use constrained delegation
   * Consider LogonUser when you need to impersonate but you don’t have trusted delegation
   * Consider S4U when you need a Windows token and you don’t have the original caller’s credentials
   * Use programmatic impersonation to impersonate based on business logic
   * When impersonating programmatically be sure to revert to original context
   * Only impersonate on operations that require it
   * Use OperationBehavior to impersonate declaratively


Input/Data Validation

   * If you need to validate parameters, use parameter inspectors
   * If your service has operations that accept message or data contracts, use schemas to validate your messages
   * If you need to do schema validation, use message inspectors
   * Validate operation parameters for length, range, format and type
   * Validate parameter input on the server
   * Validate service responses on the client
   * Do not rely on client-side validation
   * Avoid user-supplied file name and path input
   * Do not echo untrusted input


Proxy Considerations

   * Publish your metadata over HTTPS to protect your clients from proxy spoofing
   * If you turn off mutual authentication, be aware of service spoofing


Deployment considerations

   * Do not use temporary certificates in production
   * If you are using a custom domain account in the identity pool for your WCF application, create an SPN for Kerberos to authenticate the client.
   * If you are using a custom service account and need to use trusted for delegation, create an SPN
   * If you are hosting your service in a Windows Service, using a custom domain identity, and ASP.NET needs to use constrained trusted for delegation when calling the service, create an SPN
   * Use IIS to host your service unless you need to use a transport that IIS does not support
   * Use a least privileged account to run your WCF service
   * Protect sensitive data in your configuration files