Difference between revisions of "Web Service Security Cheat Sheet"

From OWASP
Jump to: navigation, search
m (XML Denial of Service Protection)
m (Related Pages)
(23 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 
= Introduction  =
 
= Introduction  =
  
This article is focused on providing guidance to securing web services and preventing web services related attacks. Please notice that due to the difference of implementation between different frameworks, this cheat sheet is kept at high level.  
+
This article is focused on providing guidance to securing web services and preventing web services related attacks. Please notice that due to the difference of implementation between different frameworks, this cheat sheet is kept at a high level.  
  
 
== Transport Confidentiality  ==
 
== Transport Confidentiality  ==
  
Transport confidentiality protects against eavesdropping and man-in-the-middle attacks against web service communications to\from the server.  
+
Transport confidentiality protects against eavesdropping and man-in-the-middle attacks against web service communications to/from the server.  
  
'''Rule''' - All communication with and between web services containing sensitive features, an authenticated session, or transfer of sensitive data must be encrypted using well configured TLS. For more information see [[Transport Layer Protection Cheat Sheet]] .
+
'''Rule''' - All communication with and between web services containing sensitive features, an authenticated session, or transfer of sensitive data must be encrypted using well configured TLS. This is recommended even if the messages themselves are encrypted because SSL/TLS provides numerous benefits beyond traffic confidentiality including integrity protection, replay defenses, and server authentication. For more information on how to do this properly see the [[Transport Layer Protection Cheat Sheet]].
  
 
== Server Authentication  ==
 
== Server Authentication  ==
  
Transport level authentication verifies the identity of the user or the system trying to connect to the service. Usually, transport authentication is a functional of the container of the web service.
+
'''Rule''' - SSL/TLS must be used to authenticate the service provider to the service consumer. The service consumer should verify the server certificate is issued by a trusted provider, is not expired, is not revoked, matches the domain name of the service, and that the server has proven that it has the private key associated with the public key certificate (by properly signing something or successfully decrypting something encrypted with the associated public key).
  
'''Rule''' - Basic Authentication has to be conducted using HTTP over SSL
+
== User Authentication ==
  
'''Rule''' - Client Certificate Authentication using HTTP over SSL to be used if the client and server need to authenticate each other
+
User authentication verifies the identity of the user or the system trying to connect to the service. Such authentication is usually a function of the container of the web service.
 +
 
 +
'''Rule''' - If used, Basic Authentication must be conducted over SSL, but Basic Authentication is not recommended.
 +
 
 +
'''Rule''' - Client Certificate Authentication using SSL is a strong form of authentication that is recommended.
  
 
== Transport Encoding  ==
 
== Transport Encoding  ==
Line 22: Line 26:
  
 
'''Rule''' - Enforce the same encoding style between the client and the server.
 
'''Rule''' - Enforce the same encoding style between the client and the server.
 
== Consumer Authentication  ==
 
 
'''Rule '''- The Message Authentication over SSL mechanism attaches a cryptographically secured identity or authentication token with the message and use SSL for confidentiality protection.
 
  
 
== Message Integrity  ==
 
== Message Integrity  ==
  
Encryption does guarantee confidentiality but it does not guarantee integrity as the message can be changed en route. In addition, encryption does not ensure the identity of the sender.  
+
This is for data at rest. Integrity of data in transit can easily be provided by SSL/TLS.
  
'''Rule '''- Use XML signatures to ensure message integrity using the sender's private key. Signature can be validated by the recipient using the sender’s digital certificate.
+
When using public key cryptography, encryption does guarantee confidentiality but it does not guarantee integrity since the receiver's public key is public. For the same reason, encryption does not ensure the identity of the sender.
 +
 
 +
'''Rule '''- For XML data, use XML digital signatures to provide message integrity using the sender's private key. This signature can be validated by the recipient using the sender’s digital certificate (public key).
  
 
== Message Confidentiality  ==
 
== Message Confidentiality  ==
Line 37: Line 39:
 
Data elements meant to be kept confidential must be encrypted using a strong encryption cipher with an adequate key length to deter brute forcing.
 
Data elements meant to be kept confidential must be encrypted using a strong encryption cipher with an adequate key length to deter brute forcing.
  
'''Rule '''- SOAP Messages must be encrypted using a strong encryption cipher.  
+
'''Rule''' - Messages containing sensitive data must be encrypted using a strong encryption cipher. This could be transport encryption or message encryption.
 +
 
 +
'''Rule''' - Messages containing sensitive data that must remain encrypted at rest after receipt must be encrypted with strong data encryption, not just transport encryption.
  
 
== Authorization  ==
 
== Authorization  ==
  
Web services need to authorize web service clients the same way web applications authorize users. A web service needs to make sure a web service client is authorized to: perform a certain action (coarse-grained); access the requested data (fine-grained).
+
Web services need to authorize web service clients the same way web applications authorize users. A web service needs to make sure a web service client is authorized to: perform a certain action (coarse-grained); on the requested data (fine-grained).
  
'''Rule''' - A web service should authorize its clients whether they have access to the method in question. This can be done using one of the following methods:
+
'''Rule''' - A web service should authorize its clients whether they have access to the method in question. Following authentication, the web service should check the privileges of the requesting entity whether they have access to the requested resource. This should be done on every request.
  
*Having clients authorize to the web service using username and password
+
'''Rule''' - Ensure access to administration and management functions within the Web Service Application is limited to web service administrators. Ideally, any administrative capabilities would be in an application that is completely separate from the web services being managed by these capabilities, thus completely separating normal users from these sensitive functions.
*Having clients authorize to the web service using client certificates
+
  
 
== Schema Validation  ==
 
== Schema Validation  ==
  
Schema validation enforces constraints, syntax and semantics defined by the schema.  
+
Schema validation enforces constraints and syntax defined by the schema.  
  
'''Rule''' - Web services must validate SOAP payloads against the web service schema.  
+
'''Rule''' - Web services must validate SOAP payloads against their associated XML schema definition (XSD).
 +
 
 +
'''Rule''' - The XSD defined for a SOAP web service should, at a minimum, define the maximum length and character set of every parameter allowed to pass into and out of the web service.
 +
 
 +
'''Rule''' - The XSD defined for a SOAP web service should define strong (ideally white list) validation patterns for all fixed format parameters (e.g., zip codes, phone numbers, list values, etc.).
  
 
== Content Validation  ==
 
== Content Validation  ==
  
'''Rule''' - Like any web application, web services need to validate input before consuming it. Content validation include:  
+
'''Rule''' - Like any web application, web services need to validate input before consuming it. Content validation for XML input should include:  
  
 
*Validation against malformed XML entities  
 
*Validation against malformed XML entities  
Line 73: Line 80:
 
SOAP provides the ability to attach files and document to SOAP messages. This gives the opportunity for hackers to attach viruses and malware to these SOAP messages.  
 
SOAP provides the ability to attach files and document to SOAP messages. This gives the opportunity for hackers to attach viruses and malware to these SOAP messages.  
  
 +
'''Rule''' - Ensure Virus Scanning technology is installed and preferably inline so files and attachments could be checked before being saved on disk.
 
'''Rule''' - Ensure Virus Scanning technology is regularly updated with the latest virus definitions / rules.
 
'''Rule''' - Ensure Virus Scanning technology is regularly updated with the latest virus definitions / rules.
  
Line 81: Line 89:
 
'''Rule''' - SOAP Messages size should be limited to an appropriate size limit. Larger size limit (or no limit at all) increases the chances of a successful DoS attack.
 
'''Rule''' - SOAP Messages size should be limited to an appropriate size limit. Larger size limit (or no limit at all) increases the chances of a successful DoS attack.
  
== Message Throughput  ==
+
== Availability ==
  
Throughput represents the number of web service requests served during a specific amount of time. Obsviously this depends on many factors including the hardware, the containser of the web service ... etc.
+
=== Message Throughput ===
 +
 
 +
Throughput represents the number of web service requests served during a specific amount of time.  
  
 
'''Rule''' - Configuration should be optimized for maximum message throughput to avoid running into DoS-like situations.
 
'''Rule''' - Configuration should be optimized for maximum message throughput to avoid running into DoS-like situations.
  
== Endpoint Security Profile ==
+
=== XML Denial of Service Protection ===
  
'''Rule''' - Web Services must be compliant with Web Services-Interoperability (WS-I) Basic Profile at minimum.
+
XML Denial of Service is probably the most serious attack against web services. So the web service must provide the following validation:
  
== Audit Logging  ==
+
'''Rule''' - Validation against recursive payloads
  
'''Rule''' - Security related activities such as successful and unsuccessful login attempts must be logged into a protected environment..
+
'''Rule''' - Validation against oversized payloads
  
== XML Denial of Service Protection ==
+
'''Rule''' - Protection against XML entity expansion
  
XML Denial of Service is probably the most serious attack against web services. So the Web Service must provide the following validation:
+
'''Rule''' - Validating against overlong element names. If you are working with SOAP-based Web Services, the element names are those SOAP Actions.
  
'''Rule''' - Validation against recursive payloads
 
  
'''Rule''' - Validation against oversized payloads
+
This protection should be provided by your XML parser/schema validator. To verify, build test cases to make sure your parser to resistant to these types of attacks.
  
'''Rule''' - Protection against XML entity expansion
+
== Endpoint Security Profile ==
 
+
== Administration ==
+
  
'''Rule''' - Ensure access to administration and management functions within the Web Service Application is limited to Web Service administrators.
+
'''Rule''' - Web services must be compliant with Web Services-Interoperability (WS-I) Basic Profile at minimum.
  
 
= Authors and Primary Editors =
 
= Authors and Primary Editors =
  
Gunnar Peterson<br/>
+
Gunnar Peterson <br/>
Sherif Koussa
+
[mailto:sherif.koussa@owasp.org Sherif Koussa] <br/>
 +
[mailto:dave.wichers@owasp.org Dave Wichers] <br/>
 +
[mailto:jim@owasp.org Jim Manico]
  
 +
= Other Cheatsheets =
 
{{Cheatsheet_Navigation}}  
 
{{Cheatsheet_Navigation}}  
  
 
[[Category:Cheatsheets]]
 
[[Category:Cheatsheets]]

Revision as of 05:52, 9 July 2012

Contents

Introduction

This article is focused on providing guidance to securing web services and preventing web services related attacks. Please notice that due to the difference of implementation between different frameworks, this cheat sheet is kept at a high level.

Transport Confidentiality

Transport confidentiality protects against eavesdropping and man-in-the-middle attacks against web service communications to/from the server.

Rule - All communication with and between web services containing sensitive features, an authenticated session, or transfer of sensitive data must be encrypted using well configured TLS. This is recommended even if the messages themselves are encrypted because SSL/TLS provides numerous benefits beyond traffic confidentiality including integrity protection, replay defenses, and server authentication. For more information on how to do this properly see the Transport Layer Protection Cheat Sheet.

Server Authentication

Rule - SSL/TLS must be used to authenticate the service provider to the service consumer. The service consumer should verify the server certificate is issued by a trusted provider, is not expired, is not revoked, matches the domain name of the service, and that the server has proven that it has the private key associated with the public key certificate (by properly signing something or successfully decrypting something encrypted with the associated public key).

User Authentication

User authentication verifies the identity of the user or the system trying to connect to the service. Such authentication is usually a function of the container of the web service.

Rule - If used, Basic Authentication must be conducted over SSL, but Basic Authentication is not recommended.

Rule - Client Certificate Authentication using SSL is a strong form of authentication that is recommended.

Transport Encoding

SOAP encoding styles are meant to move data between software objects into XML format and back again.

Rule - Enforce the same encoding style between the client and the server.

Message Integrity

This is for data at rest. Integrity of data in transit can easily be provided by SSL/TLS.

When using public key cryptography, encryption does guarantee confidentiality but it does not guarantee integrity since the receiver's public key is public. For the same reason, encryption does not ensure the identity of the sender.

Rule - For XML data, use XML digital signatures to provide message integrity using the sender's private key. This signature can be validated by the recipient using the sender’s digital certificate (public key).

Message Confidentiality

Data elements meant to be kept confidential must be encrypted using a strong encryption cipher with an adequate key length to deter brute forcing.

Rule - Messages containing sensitive data must be encrypted using a strong encryption cipher. This could be transport encryption or message encryption.

Rule - Messages containing sensitive data that must remain encrypted at rest after receipt must be encrypted with strong data encryption, not just transport encryption.

Authorization

Web services need to authorize web service clients the same way web applications authorize users. A web service needs to make sure a web service client is authorized to: perform a certain action (coarse-grained); on the requested data (fine-grained).

Rule - A web service should authorize its clients whether they have access to the method in question. Following authentication, the web service should check the privileges of the requesting entity whether they have access to the requested resource. This should be done on every request.

Rule - Ensure access to administration and management functions within the Web Service Application is limited to web service administrators. Ideally, any administrative capabilities would be in an application that is completely separate from the web services being managed by these capabilities, thus completely separating normal users from these sensitive functions.

Schema Validation

Schema validation enforces constraints and syntax defined by the schema.

Rule - Web services must validate SOAP payloads against their associated XML schema definition (XSD).

Rule - The XSD defined for a SOAP web service should, at a minimum, define the maximum length and character set of every parameter allowed to pass into and out of the web service.

Rule - The XSD defined for a SOAP web service should define strong (ideally white list) validation patterns for all fixed format parameters (e.g., zip codes, phone numbers, list values, etc.).

Content Validation

Rule - Like any web application, web services need to validate input before consuming it. Content validation for XML input should include:

  • Validation against malformed XML entities
  • Validation against XML Bomb attacks
  • Validating inputs using a strong white list
  • Validating against external entity attacks

Output Encoding

Web services need to ensure that output sent to clients is encoded to be consumed as data and not as scripts. This gets pretty important when web service clients use the output to render HTML pages either directly or indirectly using AJAX objects.

Rule - All the rules of output encoding applies as per XSS (Cross Site Scripting) Prevention Cheat Sheet .

Virus Protection

SOAP provides the ability to attach files and document to SOAP messages. This gives the opportunity for hackers to attach viruses and malware to these SOAP messages.

Rule - Ensure Virus Scanning technology is installed and preferably inline so files and attachments could be checked before being saved on disk. Rule - Ensure Virus Scanning technology is regularly updated with the latest virus definitions / rules.

Message Size

Web services like web applications could be a target for DOS attacks by automatically sending the web services thousands of large size SOAP messages. This either cripples the application making it unable to respond to legitimate messages or it could take it down entirely.

Rule - SOAP Messages size should be limited to an appropriate size limit. Larger size limit (or no limit at all) increases the chances of a successful DoS attack.

Availability

Message Throughput

Throughput represents the number of web service requests served during a specific amount of time.

Rule - Configuration should be optimized for maximum message throughput to avoid running into DoS-like situations.

XML Denial of Service Protection

XML Denial of Service is probably the most serious attack against web services. So the web service must provide the following validation:

Rule - Validation against recursive payloads

Rule - Validation against oversized payloads

Rule - Protection against XML entity expansion

Rule - Validating against overlong element names. If you are working with SOAP-based Web Services, the element names are those SOAP Actions.


This protection should be provided by your XML parser/schema validator. To verify, build test cases to make sure your parser to resistant to these types of attacks.

Endpoint Security Profile

Rule - Web services must be compliant with Web Services-Interoperability (WS-I) Basic Profile at minimum.

Authors and Primary Editors

Gunnar Peterson
Sherif Koussa
Dave Wichers
Jim Manico

Other Cheatsheets

OWASP Cheat Sheets Project Homepage

Developer Cheat Sheets (Builder)

Assessment Cheat Sheets (Breaker)

Mobile Cheat Sheets

OpSec Cheat Sheets (Defender)

Draft Cheat Sheets