WCF Security Best Practices

From OWASP
Revision as of 23:17, 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
(@Codeplex by J.D. Meier , Jason Taylor , Prashant Bansode , Carlos Farre, Madhu Sundararajan, Steve Gregersen.)

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