Difference between revisions of "WCF Security Best Practices"

From OWASP
Jump to: navigation, search
(New page: From [http://www.codeplex.com/WCFSecurity/Wiki/View.aspx?title=Guidelines WCF 3.5 Security Guidelines] J.D. Meier , Jason Taylor , Prashant Bansode , Carlos Farre, Madhu Sundararajan, Stev...)
 
Line 1: Line 1:
From [http://www.codeplex.com/WCFSecurity/Wiki/View.aspx?title=Guidelines WCF 3.5 Security Guidelines]
+
From [http://www.codeplex.com/WCFSecurity/Wiki/View.aspx?title=Guidelines WCF 3.5 Security Guidelines]<br/>
 
J.D. Meier , Jason Taylor , Prashant Bansode , Carlos Farre, Madhu Sundararajan, Steve Gregersen.
 
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 Considerations
  
    * Design your service as a wrapper
+
* 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 ASMX then use basicHttpBinding to support your existing clients
    * If you are coming from DCOM then, use netTcpBinding
+
* 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 within intranet then choose transport security
    * If your clients are deployed over the internet then choose message security
+
* If your clients are deployed over the internet then choose message security
    * Know your Authentication options
+
* Know your Authentication options
    * Know your binding options
+
* Know your binding options
    * If you need to Interop with non MS clients, use basicHttpBinding or wsHttpBinding
+
* If you need to Interop with non MS clients, use basicHttpBinding or wsHttpBinding
    * If your non-MS clients understand WS stack, use wsHttpBinding
+
* If your non-MS clients understand WS stack, use wsHttpBinding
  
  
 
Auditing and Logging
 
Auditing and Logging
  
    * Use WCF auditing to audit your service
+
* Use WCF auditing to audit your service
    * If non-repudiation is important, consider setting SuppressAuditFailure property to false
+
* If non-repudiation is important, consider setting SuppressAuditFailure property to false
    * Use message logging to log operations on your service
+
* Use message logging to log operations on your service
    * Instrument for user management events
+
* Instrument for user management events
    * Instrument for significant business operations
+
* Instrument for significant business operations
    * Protect log files from unauthorized access
+
* Protect log files from unauthorized access
    * Do not log sensitive information
+
* Do not log sensitive information
  
  
 
Authentication
 
Authentication
  
    * Know your authentication options
+
* Know your authentication options
    * Use Windows Authentication when you can
+
* 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 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 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 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 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 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 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 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
+
* If you are using username authentication, validate user login information
    * Do not store passwords directly in the user store
+
* Do not store passwords directly in the user store
    * Enforce strong passwords
+
* Enforce strong passwords
    * Protect access to your credential store
+
* Protect access to your credential store
    * If you are using Windows Forms to connect to WCF, do not cache credentials
+
* If you are using Windows Forms to connect to WCF, do not cache credentials
  
  
 
Authorization
 
Authorization
  
    * If you store role information in Windows Groups, consider using the WCF PrincipalPermissionAttribute class for roles 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 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 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 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 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 authorize access to WCF operations, use declarative authorization
    * If you need to perform fine-grained authorization based on business logic, use imperative authorization
+
* If you need to perform fine-grained authorization based on business logic, use imperative authorization
  
  
 
Binding
 
Binding
  
    * If you need to support clients over the internet, consider using wsHttpBinding.
+
* 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 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 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 local WCF clients, consider using netNamedPipeBinding.
    * If you need to support disconnected queued calls, use netMsmqBinding.
+
* 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.
+
* If you need to support bidirectional communication between WCF Client and WCF service, use wsDualHttpBinding.
  
  
 
Configuration Management
 
Configuration Management
  
    * Use Replay detection to protect against message replay attacks
+
* 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 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)
+
* If you don’t want to expose your WSDL, turn off HttpGetEnabled and metadata exchange (mex)
    * Manage bindings and endpoints in config not code
+
* Manage bindings and endpoints in config not code
    * Associate names with the service configuration when you create service behavior, endpoint behavior, and binding configuration
+
* Associate names with the service configuration when you create service behavior, endpoint behavior, and binding configuration
    * Encrypt configuration sections that contain sensitive data
+
* Encrypt configuration sections that contain sensitive data
  
  
 
Exception Management
 
Exception Management
  
    * Use structured exception handling
+
* Use structured exception handling
    * Do not divulge exception details to clients in production
+
* Do not divulge exception details to clients in production
    * Use a fault contract to return error information to clients
+
* Use a fault contract to return error information to clients
    * Use a global exception handler to catch unhandled exceptions
+
* Use a global exception handler to catch unhandled exceptions
  
  
 
Hosting
 
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 a Windows Service, use a least privileged custom domain account
    * If you are hosting your service in IIS, use a least privileged service 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
+
* Use IIS to host your service unless you need to use a transport that IIS does not support
  
  
 
Impersonation and Delegation
 
Impersonation and Delegation
  
    * Know the impersonation options
+
* Know the impersonation options
    * If you have to flow the original caller, use constrained delegation
+
* 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 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
+
* 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
+
* Use programmatic impersonation to impersonate based on business logic
    * When impersonating programmatically be sure to revert to original context
+
* When impersonating programmatically be sure to revert to original context
    * Only impersonate on operations that require it
+
* Only impersonate on operations that require it
    * Use OperationBehavior to impersonate declaratively
+
* Use OperationBehavior to impersonate declaratively
  
  
 
Input/Data Validation
 
Input/Data Validation
  
    * If you need to validate parameters, use parameter inspectors
+
* 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 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
+
* If you need to do schema validation, use message inspectors
    * Validate operation parameters for length, range, format and type
+
* Validate operation parameters for length, range, format and type
    * Validate parameter input on the server
+
* Validate parameter input on the server
    * Validate service responses on the client
+
* Validate service responses on the client
    * Do not rely on client-side validation
+
* Do not rely on client-side validation
    * Avoid user-supplied file name and path input
+
* Avoid user-supplied file name and path input
    * Do not echo untrusted input
+
* Do not echo untrusted input
  
  
 
Proxy Considerations
 
Proxy Considerations
  
    * Publish your metadata over HTTPS to protect your clients from proxy spoofing
+
* Publish your metadata over HTTPS to protect your clients from proxy spoofing
    * If you turn off mutual authentication, be aware of service spoofing
+
* If you turn off mutual authentication, be aware of service spoofing
  
  
 
Deployment considerations
 
Deployment considerations
  
    * Do not use temporary certificates in production
+
* 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 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 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
+
* 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 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
+
* Use a least privileged account to run your WCF service
    * Protect sensitive data in your configuration files
+
* Protect sensitive data in your configuration files

Revision as of 23:03, 15 May 2008

From WCF 3.5 Security Guidelines
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