Web Service Security & Authentication Best Practices

Web Service Security Objectives

In implementing security best practices for web services, there are generally four main objectives:

• Data Integrity & Authentication: Using signatures that are defined in the XML signature to secure the integrity of the data (the data has not been manipulated during transmission) and that the data arrives at the intended recipient only (authentication).

• Data Confidentiality: Encrypting certain/all parts of the transmitted via the implementation of XML encryption to make sure the data included can only be read by the intended recipient. So, when this data is compromised to attackers/other parties, they won’t be able to read and use it.

• Freshness: Implementations of nonces and timestamps to ensure transmitted messages are only valid for a set amount of time.

• Availability: Ensuring the availability of service at all times by preventing Denial of Service (DoS) attacks. A key objective of web service security is to ensure the web service is always available and can respond to client’s requests in a timely manner.

Obviously, different web services might also have other security objectives, and some of these four might not be relevant for specific web service applications. For example, if the web service is not transmitting sensitive or regulated data, confidentiality and authenticity might not be a relevant issue and we can focus on availability and freshness instead.

Below, we will discuss a checklist for web services security based on these four objectives.

Web Security & Authentication Best Practices Checklist

1. Ensuring Transport Confidentiality

Transport confidentiality must be maintained to protect against eavesdropping and Network Interception attacks on all communications to and from the server.

The general rule of thumb is to always assume all communication between and with web services contain sensitive features. Any transfer of data (especially sensitive or regulated data), and any authenticated session, must be encrypted using well-configured Transport Layer Security (TLS) protocols.

It is recommended to implement this even if the message itself is already encrypted, since TLS will also protect the integrity of the data as well as other benefits like defense against replay attacks and server authentication.

You might want to check out this cheat sheet on how to properly implement TLS.

2. Maintaining Message Integrity

For data at rest (not currently transmitted), we can use TLS to maintain the integrity of the data.

It is best to implement this even if the data is already encrypted with public-key cryptography. Encryption with a public key does not protect the integrity of the data, because the public key can be accessed by others, although it can protect the data’s confidentiality. Public-key encryption also will not maintain the identity of the sender (can be modified).

For XML data, it’s recommended to use XML digital signatures to maintain data integrity using the sender’s private key for encryption. The recipient can validate this signature using the sender’s public key.

3. Authentication Best Practice

For server authentication, TLS must be applied to authenticate the service provider to the service consumer.

The consumer should only verify the server certificate when:

• It is provided by a trusted provider.
• Authentication is not yet expired.
• Authentication is not revoked by the sender.
• It matches the domain name of the web service.

The server must prove that it has the right private key associated with the public key certificate. This can be done by decrypting or signing something decrypted with the associated public key.

User authentication should also be implemented to verify the identity of the user or the consumer/client requesting service. It is recommended to use Client Certificate Authentication using TLS. Basic Authentication is not recommended.

4. Transport Encoding

Always maintain the same encoding style between the client and the server.

5. Message Confidentiality

Data must be encrypted using a strong encryption key. Adequate key length is recommended to prevent brute force attacks.

Identify messages that contain sensitive or regulated data. Sensitive data must be encrypted with a strong encryption key. We can implement both transport encryption or message encryption when the data is transported.

For data at rest, identify whether the sensitive data must remain encrypted at rest. If so, always use strong data encryption, as transport encryption won’t be sufficient.

6. Schema Validation

The web service must validate SOAP payloads by comparing it with the associated XSD (XML Schema Definition).

The XSD should, at the very least, define the maximum length and character set that are allowed to pass into and out of the web service. The XSD should provide an allow list for all fixed format parameters that are required (i.e. list values, zip codes, etc.).

7. Bot Mitigation

Since a lot of attacks targeted at web services make use of bots, it’s highly recommended to implement a bot mitigation software solution to detect and mitigate malicious bot activities in real-time.

Solutions like DataDome can be a cost-effective and reliable solution for protecting your cloud environment. The bot protection service uses advanced AI and machine-learning technologies to detect malicious bot activity, and mitigates attacks on autopilot.

8. Authorization Best Practices

For authorization purposes, the web service must treat web service clients the same way it will authorize users. A web service should implement clear authorization policies whether a web service client is authorized to perform a certain action/method on the requested data.

Following the authentication process, the web service should also check the privileges of the requesting client whether they have access to the requested data. This process must be applied to every request.

Any administration and management functions for the web service application must be limited to the intended administrators alone. It is recommended to have all administrative capabilities in a completely separate application from the web service that is managed. This is to ensure normal users are completely separate from these administrative functions.

9. Content Validation Best Practice

Web services must validate all XML content input before consuming it, and should include:

1. Validating inputs using a strong allow list.
2. Validating inputs against external entity attacks.
3. Validating inputs against malformed XML entities.
4. Validating inputs against XML bomb attacks.

10. Output Encoding

Output sent to web service clients must be properly encoded so the client will consume it as data (not as scripts). If the web service clients can use the output to render HTML pages using AJAX objects (both directly and indirectly), this is even more important.

11. Implementing Antivirus & Anti-Malware

SOAP protocol allows users to attach files and documents to SOAP messages used in web service. Attackers might exploit it as a vulnerability by attaching viruses and malware to these messages.

It’s very important to ensure a proper antivirus/anti-malware solution is installed, preferably inline. This is to ensure all files and attachments can be properly checked before being saved to disks.

Make sure the antivirus is regularly updated, especially if it is using a database/fingerprinting-based approach rather than a behavioral-based approach.

12. XML DoS Prevention

XML DoS (Denial of Service) attack is very common in web services and is arguably the most dangerous type of attack in web service environments. Always validate against:

• Recursive payloads.
• XML entity expansion.
• Oversized payloads.
• Overlong element names especially in SOAP-based web services.

Build test cases and simulate whether your XML parser/schema validator can defend against XML DoS attacks.

13. Availability Best Practices

In the event of an attack, the web service may require more resources than what’s available, which can cause instability and denial of service (DoS). It is recommended to:

• Limit the number of CPU cycles based on the expected service rate to ensure stability.
• Limit the amount of memory that can be used by the web service to avoid system crashes.
• Limit the number of allowed simultaneous network connections, processes, and open files.

The general rule of thumb is that your security shouldn’t interfere with the web service’s availability. On the other hand, protection best practices must be implemented to ensure availability even in the event of an attack (i.e. ensuring the system is back to normal ASAP).

14. Message Size & Throughput

Hackers can attempt DoS or DDoS attacks by sending a high number of large-sized SOAP messages. This can significantly slow down the web service or even make it totally unable to respond to legitimate requests/messages. To prevent this, we should set clear policies for the message size limit.

Message throughput represents the number of web service requests served during a set amount of time. The system must be configured optimally to allow maximum message throughput to prevent DoS and ensure the service’s performance.

Conclusion

There is no one-size-fits-all web service security approach that will thoroughly protect the whole environment from all the available cyber attack vectors. Different web service entities might also require different approaches depending on various different factors like the type of web service clients, data involved in the service, etc.

With that being said, the checklist we have shared above can help you in implementing web service security and authentication best practices to defend against common cybersecurity threats and ensure service availability.