If you are a business undergoing a digital transformation, like Walgreens, Nike or Bechtel, heavy reliance on APIs is a key part of that digital transformation strategy.
“The growing demand for information, delivered securely at any time, in any place and on any device has changed the way we think about applications — APIs are a critical part of our go forward strategy for meeting and exceeding our global business needs.” — Christian Reilly, BECHTEL CORP
Since 2009, Apigee (now a subsidiary of Google) played a significant role in making API management, monetization and metering easier and more scalable for the enterprises. Apigee is, rightfully, the most popular API gateway on the market.
Security on Apigee — good but not complete
In recent years it became obvious true digital transformation can only happen when the API design and application security come in lock-step. (The topic of API security is addressed in a recent Wallarm whitepaper, Top Five Challenges Protecting APIs )
Apigee has introduced many new security features to improve the security posture for their customers. Features such as encryption, certificate-based authentication, and role-based access control go a long way to satisfy compliance requirements and follow security best practices.
Apigee Edge. However, Apigee is an API gateway and not an especially built security product. According to Apigee,
“Using the Apigee platform itself does not guarantee protection against issues identified by the Open Web Application Security Project (OWASP)”.
Product documentation further advises:
“To protect APIs, Apigee provides several policies out of the box, such as rate limiting and spike arrest, along with other policies that can be custom developed for specific use cases.”
These custom-developed use-case policies are defined as regular expressions. Apigee Edge allows developers to define explicit predefined regular expressions. The content of the API message sections URI Path, Query Param, Header, Form Param, Variable, XML Payload, or JSON Payload is evaluated against these regular expressions.
Unfortunately, this approach is fraught with the same problems and other common RegEx-based WAFs, like ModSecurity:
- Common WAFs require laborious creation, maintenance and continuous reconciliation of the regular expressions.
Below is an example of just one regular expression defined to detect a specific SQL Injection in the URI path. It obviously give a lot of room for making a mistake.
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1"><DisplayName>Regular Expression Protection 1</DisplayName><Source>response</Source><IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables><URIPath>
<Pattern>
[\s]*((delete)|(exec)|(drop\s*table)|(insert)|(shutdown)|(update)|(\bor\b))
</Pattern>
</URIPath></RegularExpressionProtection>
- Detection itself is not always possible for complicated, nested or embedded API protocols. If the pattern is encoded with base64 encoding, for example, regular- expression detection would not be effective.
- Anomalies in the length of parameters, number/depth of elements (JSONThreatProtection and XMLThreatProtection) and other advanced attacks cannot be detected.
Wallarm and Apigee
Now customers who are concerned about the run-time API security can rely on Wallarm using newly developed integration of Wallarm AI-Powered Application Security platform with Apigee. You can get unprecedented visibility on malicious traffic coming to your XML and JSON based APis running on Apigee gateway.
Says one of the early adopters of the Wallarm Apigee Extension, “We are using Wallarm instead of configuring Apigee RegularExpressionProtection policy manually. The attack detection is accurate and automatic — and we don’t have to spend time on adjusting and redefining regular expressions on Apigee.”
Deployment architecture assume asynchronous mode where Wallarm Node analyzes requests for malicious content but doesn’t affect traffic flow. There is no potential impact on the performance and additional latency introduced.
The integration is configured under Develop -> API Proxy setting. Develop section is where you would also find configuration options for Apigee’s standard JSONThreatProtection and XMLThreatProtection as well as RegularExpressionProtection policies. Wallarm JS-based extension is also added in this section.
The extension would redirect a copy of the traffic to Wallarm Node for automated analysis. IP of this node would be set in the source code of JS-connector. For this system to work, you will also need to deploy Wallarm node. The node can be deployed as a Docker container, virtual machine or any other available deployment options. The node would then parse the request, apply attack detection techniques and provide visibility in Wallarm Console.
Protect your Apigee now
If you’re using Apigee and interested in participating in the evaluation program, please reach out to us at request@wallarm.com or sign-up here: https://us1.my.wallarm.com/signup
