API Security is an important topic and I would like in this article to get deeper into the specific case of Web Service Security.
Web Service Security
Security of Web APIs has evolved pretty much over the past 10 years. In its early days, it was all about XML firewalls and protection of Web Service. Entire products such as Axway API Gateway, IBM Datapower or CA API Gateway were built around a number of attacks which are called “Replay attack,” “SOAP action spoofing,” “XML encryption attack” and various others. Ruhr Uni Bochum did a quite spectacular attack against AWS in 2011. They also developed an OpenSource Tool called WS-Attacker which can be used to test and validate XML Security implementations.
So what does a Web Service Security implementation take?
Actually, a number of steps are required to implement this. They are embedded in some API Gateways, such as the one from the Axway API Management solution. They embed security measures that can be grouped into template policies, which can be reused across various services. With this approach, it’s a one-time effort to create the templates and make them adaptable and reusable for further services that get on-boarded.
I have always been advocating for a level-based approach because not all exposed services are equal. The levels could be for example:
- Public services – Open services, for example, a store locator.
- Protected services – Services which require some level of trust e.g. performing a status lookup of an order.
- Confidential services – Confidential data might be processed via this level of services like a human resource or payment data.
Ideally, when running a lot of services, the service owners can submit a classification in line with the above level while requesting to expose a Web Service. This helps the business as well as the IT side to understand the required level of protection, the data involved and the criticality.
Depending on the Web Service level, a different set of policies (actions and attack countermeasures) can be applied for example:
Level 1: public Web Services
- Protection against (distributed) denial-of-service – (D)DoS – attacks via quota and throttling
- XML threat-awareness done by checking against a list of common threats
- XML complexity check to protect against XML Bombing attacks
- Message size checks
- Schema validation
- Content type checks
- Level 2 and Level 3 protection below
Level 2: protected Web Services
- Access control
- Authentication
- Service-based authorization (is this authenticated client allowed to access this specific service?)
- IP-Address based filtering (white-listing / black-listing)
- Antivirus if needed, usually this is enough for inbound calls but especially required when XML attachments or embedded payload inside XML is involved
- Level 3 protection below
Level 3: confidential Web Services
- Confidentiality checks – is confidential data involved and if yes applying a set of actions as following
- Integrity checks via checksums
- XML signature verification which provides a way to check integrity too
- XML encryption and decryption
Monitoring and Integration with third-party solutions
When Services get exposed and protected this way, it’s also very important to monitor what’s happening continuously. Sophisticated API Security Gateways provide not only integrated monitoring but ways to link it to other systems which are part of an ITSM (IT Service Management) or SIEM (Security Information & Event Management) infrastructure. If an attack happens, IT people get immediately notified and can take action based on the attack.
Web Service Security Testing
After implementing all the above, proper testing is good practice. Ideally, this is an integrated piece of the delivery process and one of the last steps before going into production. Tools like Ready! API from SmartBear can help with automating API Security testing simulating some attacks. A few vendors like Axway integrate with this tool, as explained in this webinar: Test & Protect Your API: Practical Tips to Achieve API Security Nirvana.
But also the earlier mentioned WS-Attacker tool can be used to identify implementation mistakes and possible issues with Web Services early in the process before production.
It might sound like cream on the cake but finally, a pen test should be executed to check if the exposed interfaces are protected the right way.
Go much deeper. Learn more about API and security here.