Difference between revisions of "Web Service Security Cheat Sheet"
m (→XML Denial of Service Protection)
|Line 107:||Line 107:|
== Administration ==
== Administration ==
'''Rule''' - Ensure access to administration and management functions within the Web Service Application is limited to
'''Rule''' - Ensure access to administration and management functions within the Web Service Application is limited to administrators.
= Authors and Primary Editors =
= Authors and Primary Editors =
Revision as of 12:25, 7 October 2011
- 1 Introduction
- 1.1 Transport Confidentiality
- 1.2 Server Authentication
- 1.3 Transport Encoding
- 1.4 Consumer Authentication
- 1.5 Message Integrity
- 1.6 Message Confidentiality
- 1.7 Authorization
- 1.8 Schema Validation
- 1.9 Content Validation
- 1.10 Output Encoding
- 1.11 Virus Protection
- 1.12 Message Size
- 1.13 Message Throughput
- 1.14 Endpoint Security Profile
- 1.15 Audit Logging
- 1.16 XML Denial of Service Protection
- 1.17 Administration
- 2 Authors and Primary Editors
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.
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 .
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 - Basic Authentication has to be conducted using HTTP over SSL
Rule - Client Certificate Authentication using HTTP over SSL to be used if the client and server need to authenticate each other
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.
Rule - The Message Authentication over SSL mechanism attaches a cryptographically secured identity or authentication token with the message and use SSL for confidentiality protection.
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.
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.
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.
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).
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:
- Having clients authorize to the web service using username and password
- Having clients authorize to the web service using client certificates
Schema validation enforces constraints, syntax and semantics defined by the schema.
Rule - Web services must validate SOAP payloads against the web service schema.
Rule - Like any web application, web services need to validate input before consuming it. Content validation include:
- Validation against malformed XML entities
- Validation against XML Bomb attacks
- Validating inputs using a strong white list
- Validating against external entity attacks
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 .
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 regularly updated with the latest virus definitions / rules.
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.
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.
Rule - Configuration should be optimized for maximum message throughput to avoid running into DoS-like situations.
Endpoint Security Profile
Rule - Web Services must be compliant with Web Services-Interoperability (WS-I) Basic Profile at minimum.
Rule - Security related activities such as successful and unsuccessful login attempts must be logged into a protected environment..
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 - Ensure access to administration and management functions within the Web Service Application is limited to web service administrators.
Authors and Primary Editors
OWASP Cheat Sheets Project Homepage
Developer Cheat Sheets (Builder)
- Authentication Cheat Sheet
- Choosing and Using Security Questions Cheat Sheet
- Clickjacking Defense Cheat Sheet
- C-Based Toolchain Hardening Cheat Sheet
- Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
- Cryptographic Storage Cheat Sheet
- DOM based XSS Prevention Cheat Sheet
- Forgot Password Cheat Sheet
- HTML5 Security Cheat Sheet
- Input Validation Cheat Sheet
- JAAS Cheat Sheet
- Logging Cheat Sheet
- .NET Security Cheat Sheet
- Password Storage Cheat Sheet
- Pinning Cheat Sheet
- Query Parameterization Cheat Sheet
- Ruby on Rails Cheatsheet
- REST Security Cheat Sheet
- Session Management Cheat Sheet
- SAML Security Cheat Sheet
- SQL Injection Prevention Cheat Sheet
- Transaction Authorization Cheat Sheet
- Transport Layer Protection Cheat Sheet
- Unvalidated Redirects and Forwards Cheat Sheet
- User Privacy Protection Cheat Sheet
- Web Service Security Cheat Sheet
- XSS (Cross Site Scripting) Prevention Cheat Sheet
Assessment Cheat Sheets (Breaker)
Mobile Cheat Sheets
OpSec Cheat Sheets (Defender)
Draft Cheat Sheets
- OWASP Top Ten Cheat Sheet
- Access Control Cheat Sheet
- Application Security Architecture Cheat Sheet
- Business Logic Security Cheat Sheet
- PHP Security Cheat Sheet
- Secure Coding Cheat Sheet
- Secure SDLC Cheat Sheet
- Threat Modeling Cheat Sheet
- Web Application Security Testing Cheat Sheet
- Grails Secure Code Review Cheat Sheet
- IOS Application Security Testing Cheat Sheet
- Key Management Cheat Sheet
- Insecure Direct Object Reference Prevention Cheat Sheet
- Content Security Policy Cheat Sheet