In-brief:In-brief: In this, the last in a three-part series on REST API, Neeraj Khandelwal of Barracuda Networks examines how web application security design can help secure REST APIs and provides tips for securing web applications. You can read Neeraj’s previous posts (here and here).
In the previous posts (here and here), we considered the ascendancy of application program interfaces (APIs) and the security challenges they pose. Among other things, we observed that APIs often lack basic protections, have security features that have been made obsolete by new threats or front incompatible legacy- and acquired technologies that are vulnerable to attack. We also discussed the difficulty of securing Representational State Transfer (REST) APIs, which can be challenging to crawl, fuzz or otherwise test using automated tools.
In this post, we will examine how web application security design can help secure REST APIs.
To start with, recognize that most commonly used technologies for detecting malicious inputs to web applications apply equally well to AJAX based web applications. These include de-obfuscation and protocol sanitizing tools, amongst a host of other checks. Using such tools, the following tips can help you improve the security, performance and manageability of your web applications:
1. Filter Malicious Data from Untrusted User Inputs in JSON/XML
Developers of programming frameworks and bespoke software alike often omit input sanitization from JSON and XML, despite enforcing it in traditional web interfaces. For example, the JSON gem in ruby was found to be vulnerable to SQL Injections and so was the Perl module SQL Maker. This opens up all the OWASP Top 10 attacks through your APIs, even though they may have been locked down through the web interface.
2. Filter Malicious Data from Untrusted User Inputs in URL Path
This includes examining the complete URL (not just the URL query part) for malicious inputs. This is enabled by default and is configured from the SECURITY POLICIES > URL Protection page.
3. Protect the Entire API Attack Surface
Web application security design should intercept and protect the entire API’s attack surface as a reverse proxy. This covers dynamically generated URLs and URLs using resource names as directories (e.g. username or moviename), etc.
4. Enable Uninterrupted API Delivery with Virtual Patching
An inline design can immediately remediate any known or new vulnerabilities in either your API or its framework (e.g. SQLi in Ruby’s JSON gem or a new SSL vulnerability) by applying virtual patches, saving you from a find-fix-test-redeploy cycle during which your API remains down and business suffers.
5. Prevent Farming Attacks (API Abuse from Rogue Consumers)
Many RESTful web service APIs are farmed by third-party aggregators. For example, price-matching websites can inundate the REST APIs of e-commerce services excessively. If not throttled properly, this could impose excessive load on the API backend, reducing the service quality for other paying, consumers. Bruteforce and anti-DDoS should be designed into web application security policies to help enforce disciplined access to the API.
6. Extend and Ensure Service Level Agreements (SLAs) to Business Partners
REST APIs often have different service levels for different resources. For example, the product catalog (/api/products/*) could have a different service level agreement (SLA) from product orders (/api/orders/*), which in turn could be different from /api/search. Further, each of these could have different SLAs for different partners. Designing rate control and bruteforce protections into web application security is key to ensuring SLAs to business partners.
7. Protect Your XML and JSON Parsers
Web application security design that includes protection for XML and JSON content prevents DoS attacks on their respective parsers, which can bring down your API service. It blocks XML bombs that look like valid XML but could still detonate your XML parser, e.g. using exponential entity expansion attack, etc.
8. Authenticate API Services
Web application security design should include the ability to pre-authenticate the API services or completely offload authentication to a web application firewall in the DMZ. Your web application should include basic authentication including LDAP and RADIUS, as well as client certificates, CRL and OCSP. Additionally, API keys should be set up to be whitelisted and validated in any part of the request, including headers.
9. Secure Session Tokens
Web application security should be designed to provide tight security for session tokens, be they in the URL, headers or in cookies. Session token encryption, signing, and replay protection to prevent man-in-the-middle attacks are all advisable. Cross site request forgery (CSRF) token injections, referrer validations and HTTP header inspections should also be designed in to fully enforce API requests.
10. Enforce Verb-based Security Constraints and Access Control
As mentioned in our earlier post, REST applications often tie HTTP (verb) methods to operational policies and role-based access control (e.g. VBAAC). Often, all the verbs are not valid for every resource. Web application security should be designed to help enforce which methods are allowed on what resources using granular positive profiling capabilities.
11. Provide Secure TLS Fronted to API Service
Web application firewalls (WAFs) can provide a secure TLS stack that prevents man in the middle eavesdropping attacks on clear text data and credentials that are often transferred in clear text via basic authentication headers or API keys. In addition, offloading TLS/SSL to your WAF can relax the API infrastructure and allow it to scale better. Not all encryption is equal, however. Make sure, however, that your WAF supports only strong ciphers as well as perfect forward secrecy.
12. Use Connection Multiplexing for API Delivery and Scalability
The chatty nature of REST (and AJAX) can impose significant overhead on your servers due to frequent connection establishments and teardown. Connection multiplexing designed into application security between a web application firewall and backend servers improves the efficiency of these exchanges. In this design setup, a pool of connections is always maintained at all times, over which client requests are multiplexed. Due to this, connection setup and teardown times are not incurred, streamlining network processing on the servers.
13. Cache and Compress your REST APIs
REST advocates statelessness to promote caching. Designing reverse proxies into web application security design are best practices to provide caching for your API. This helps speed up API delivery and reduces server load, saving significant bandwidth over the wire – a useful quality given unreliable mobile networks.
14. Centralize API Auditing and Analytics
Web application security design that takes advantage of a centralized auditing and regulatory compliance framework can get immediate insights into API use and data consumption behaviors. Administrators can drill down into reports using many different client and server side metrics, which can provide many benefits. Among them: better planning and design of web application security and adequate security for APIs dealing with personally identifiable information, confidential or sensitive data.
