This document discusses each of the application integration methods commonly used these days for B2B integrations. The concepts discussed below focuses on API security from the perspective of confidentiality, integrity, authentication and replay attacks.
- Technology overview – This section provides the background, overview and advantages of each of the existing technology.
- Confidentiality - Ensuring the confidentiality of access credentials, authentication credentials, and tokens used for authorization is highly important. The system design and controls implementation must prevent the disclosure of credentials and tokens to any personnel other than the associated user. Maintaining the confidentiality is critically important to meet business objectives.
- Integrity - Ensuring the integrity of identity information, protecting accounts throughout the information lifecycle and preventing unauthorized modification to ensure a robust identity management system is of critical importance.
- Authentication – Ensuring authentication methods are understood and implemented correctly to identify the legitimate user to the system. Insufficient authentication methods could lead to unauthorized access to system resources and leakage of sensitive information.
- Replay attacks – Ensuring application resources cannot be replayed or repeated with already utilized parameters leading to a database overflow or denial of service. This is usually triggered by man-in-the-middle attack.
At a high-level there exist two major types of web services that could be chosen for application to application communication:
- JAX-RPC based web service – This is based on SOAP protocol. The service provider publishes the web service definition using a WSDL specification and the consumer communicates using a serialized XML message wrapped in a SOAP envelop across the wire.
- JAX-RS based web service – This is based on Representational State Transfer (REST) web service. The service provider publishes the Resource name that can be used to consume the service and the consumer access the service over stateless HTTP protocol. The message payload can be XML or JSON format.
SOAP (Simple Object Access Protocol)
SOAP is a Microsoft developed protocol specification for exchanging structured information in the implementation of web services. It relies exclusively on XML to provide messaging services and has standardized rules for writing the web services. SOAP is usually best suited for distributed enterprise environments where standardization is crucial part in application communication. SOAP being a Microsoft developed protocol has advantages when worked in an enterprise environment.
Built-in error handling
Used with both HTTP and SMTP protocol. Secure version of these protocols must be used to achieve high level of security
Language, platform, and transport independent
The most important part of SOAP is the Web Services Description Language (WSDL). It provides the definition of how the web service works and the IDE can completely automate the process.
Confidentiality of the web service communication relies on transport layer security and message level encryption. Using encrypted protocols such as HTTPS/SMTPS protect eavesdropping and man-in-the-middle attacks. All communication with and between web services containing sensitive information, an authenticated session, or transfer of sensitive data must be encrypted using SSL/TLS protocol. Web services communication containing sensitive information such as username, password, token, session identifier must be transmitted over POST request as GET request are cached in communication paths e.g. web browsers, network proxies, etc.
Using XML encryption, the message level confidentiality can be achieved. The OASIS standard specification introduced WS-Security for SOAP messages that enables SOAP message body or portions of it to be encrypted to ensure message confidentiality. Only approved public algorithms must be used such as AES, RSA public key cryptography, and SHA-256 or better. Do not use weak algorithms such as MD5 or SHA1.
Web services integrity applies to data at rest as well as data in transit and is protected by TLS layer and XML digital signatures. To ensure data integrity, digital signatures can be used 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). Generally, the digital signature service is provided by the same vendor who provides digital certificates for transport layer security.
Using XML digital signatures, the message level integrity can be achieved. WS-Security uses XML digital signature that enables SOAP messages to be digitally signed to ensure message integrity. The message signature is computed based on the content of the message and is attached to the message. If the message is altered over the transport layer the computed signature becomes invalid and the message is ignored. Use PBKDF2, bcrypt or scrypt for hashing.
Web services authentication can be divided into 2 parts i.e. Client Authentication and Server Authentication. Authentication is the process of validating both communication parties are legitimate and are authorized entities to the system.
Client Authentication – This implies to the client or web browser or web service call accessing the system resource. Each web service call must be authenticated using a username/password combination or token or session identifier. To simplify the authentication process, the application could use a separate web service call to authenticate a user and issue a valid token (also called as bearer token) or session identifier. All subsequent web service call must then use the bearer token or session identifier. From this on, the web service security can be compared to web application security.
WS-Security offers use of username/password, X.509 certificates or Kerberos authentication mechanisms. The combination of username/password along with Digest Authentication is the preferred way to go.
Server Authentication – This implies to the server offering services to another application or users. TLS must be used to authenticate the server to the client. The client must 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.
A replay attack is a “man-in-the-middle” type of attack where a message is intercepted and replayed by an attacker to impersonate the original sender. The replay attack can be tackled broadly in two ways:
- Timestamp – A timestamp element is used along with web service call to keep track of messages and to detect replays of previous messages. This control must be implemented both at the client and server side. The server validates the timestamp token on each client request to the server cached timestamp.
- Nonce – This control is provided by most of the IDEs to protect against replay attacks. Since Nonce element has a unique value, server can detect replay attacks with relative ease.
- As a security best practice, both Nonce and timestamp can be used and must be signed by the IDE. Avoid using own algorithms or secret number generators instead use a IDE provided functionality to implement a Nonce.
The below table summarizes the above discussed methods.
|SOAP based integration||Transport Layer Security and XML Encryption||Transport Layer Security and XML Digital Signature||OAuth 2.0 or Username-Password with Digest Authentication||Nonce attached to user identifier|
REST (REpresentational State Transfer)
REST is a most popular application integration method for most of the companies today. Yahoo, Google, Flickr, Amazon uses REST web services over SOAP. The reason is flexibility, platform independence and requires less bandwidth than SOAP. REST is stateless, architectural style and best utilized with JSON output. The one most important advantage of using JSON output is the user input is rendered in TEXT format by web browser rather than the HTML format. This prevents the attacks such as cross site scripting inherently. However, the input validation rule still applies to REST web service that do not always trust the user input. Though REST relies heavily on the HTTP method to route and process endpoint requests and expects properly typed data hence the REST security must be considered when using the REST web service for application integration.
REST is stateless and based on HTTP protocol. The confidentiality of data lies on transport layer security that is provided by HTTPS connection. By using TLS 1.2 and strong cipher e.g. SHA-256 with RSA encryption ensures that the communication is not brute-forcable. REST web services must be implemented over HTTPS connection for all user transaction calls, resource name and utilize POST request for transmitting user information. The POST request ensures that the HTTP request is not cached along the network path such as web browser, network proxy. The example of REST API includes.
REST data integrity is provided by using digital signatures over TLS layer and strong input validation. The Validate in, Validate out concept applies to all application integration methods that guarantees API data integrity and also protects against attacks such as cross site scripting, XXE, XML denial of service. E.g. if API data is used as an input to another application the lack of data input validation could cause serious damages to another application.
Another way to ensure data integrity is message level encryption. The most common way to achieve is use of XML digital signatures with approved hashing algorithms such as PBKDF2, bcrypt or scrypt. This ensures that the data is not tampered while in transit preventing unauthorized modification of the data.
The client or each REST API call must be authenticated before accessing any system resources. There are several methods by which authentication can be implemented i.e. Basic Authentication, Digest Authentication, OAuth1.0a or OAuth2.0. There are pros and cons of each authentication method and are best suited when applied using the combination of authentication techniques. Example, an application performs OAuth2 authentication based on IP whitelisting. This ensures system resources are accessed from known IP and OAuth2 ensures Authorization token is present for each API call.
Since REST is a stateless protocol, each API call requires a user to be tracked by some identifier e.g. Session Identifier or OAuth2 Token. The OAuth2.0 authentication is the recommended approach as there is no session information stored on the server, all is tracked via the OAuth token that must be set with an expiry time.
The other authentication methods include:
- Basic Authentication - This is the easiest way to implement authentication and security. It is basic in nature and require no overhead of additional APIs. The username and password is sent in the request header in Base64 encoding format. This method must be used only with SSL/TLS security to prevent credentials being sniffed and decoded.
- Digest Authentication – This is the secure way to implement authentication where user credentials are sent in encrypted format over the network. The client request a server to access the resource and the server responds with a realm (hash) and nonce asking for client to authenticate. The client authenticates using username and password that is sent along with nonce and realm to the server. If matches, server authenticates the client.
- OAuth1.0a – This is a signature based protocol and has a overhead of complex signature generating process. The user credentials are passed through the cryptographic algorithm such as HMAC-SHA1 to generate a token secret or nonce. This token is then used for each REST API call for authentication and authorization.
- OAuth2.0 – This protocol eliminates use of signatures instead the security lies on Transport Layer Security. The protocol uses token secret or nonce for each REST API call for authentication and authorization.
REST web services are more prone to replay attacks, especially when authentication is not implemented sufficiently on the APIs. By taking an advantage of REST being a stateless and language independent it is relatively very simple to replay the REST API call. Each REST API call should use a time limited encryption key, keyed against the session token or bearer token, date and time or IP address. The encryption key is sent along with bearer token via POST method that is then validated at the server end. This prevents the replay attack as the encryption key is attached to the local client storage and validated at the server end before processing the API call.
|REST based integration||Transport Layer Security and message level encryption||Transport Layer Security and message level digital signature||OAuth 2.0 with token expiry IP whitelisting||Encryption key or secret token attached to user identifier|
Message Based Integration
Message Based Integration method is most commonly used in supplier-subscriber environment. For example, as an end user I want to be notified for any price change of a product, new offer published by supplier or special discounts running by supplier I will subscribe to the supplier website. With this pattern, many applications offering to subscribe users will use the Message based service of the supplier. When an event is created, the supplier sends this event to all the subscribers to the service notifying users of the subscriber.
The Confidentiality of the data and communication lies on Transport Layer Security and Message encryption. Since Message based integration is platform independent it can use message encryption (WS-Security) or XML encryption as discussed above to achieve message confidentiality. The use of HTTPS ensures that the message is protected by eavesdropping and network level attacks and message level encryption ensures that the message is encrypted at rest providing data confidentiality.
The integrity of the data and communication lies on digital signatures. The use of strong hashing algorithms and validating the computed value at the server prevents tampering of message in transit. Implementing digital signature over HTTPS prevent from network level attacks and using digital signature with approved hashing algorithms such as PBKDF2, bcrypt or scrypt prevent unauthorized modification of data. Ensure that the hashing value is validated at the server for each message call.
Message Based Integration is no different than other web service offerings. The authentication methods that could be utilized includes Basic Authentication, Digest Authentication, Username/Password combination over HTTPS protocol. Ensure authentication method is always implemented on HTTPS layer. In cases where source application endpoints are known, IP whitelisting must be used to deter unauthorized access attempts to the web service.
For message based integration, Digest Authentication with IP whitelisting works in most cases as consumer applications are known and frequently requires access to known set of system resources.
The API can be written in any of the language XML or SOAP-based. Implementing a time limited encryption key, keyed against the session token or bearer token, date and time or IP address prevents against the replay attacks. The encryption key is sent along with bearer token via POST method that is then validated at the server end.
|Message Based Integration||Transport Layer Security and message level encryption||Transport Layer Security and message level digital signature||Digest Authentication over HTTPS IP whitelisting||Encryption key or secret token attached to user identifier|