Menu
Application Programming Interfaces or APIs have existed for decades. However, they have recently seen a significant expansion in usage from their traditional use within areas such as Business to Business (B2B) or partner integrations into several new areas. These include the growing use of APIs that are exposed publicly for developer integrations with cloud platforms in particular, as well as supporting new web application design paradigms such as microservice architectures and Single Page Applications (SPAs). Many of the mechanisms necessary to apply security controls to API traffic within these new paradigms in particular are generally newer and less commonly covered than those in traditional web applications – this means that they are generally less well understood by developers, less mature and robust, harder to configure, and can be lacking in certain environments.
In this article, we’ll look at the security risks that APIs can present, and how AppCheck can help you to detect and mitigate them.
A Web API or Application Programming Interface is an HTTP interface that is exposed by a web service, in which the returned data is in a machine-parseable format, often with a hierarchical or structured data format. This contrasts to the “rich” documents returned by traditional web interfaces that contain both data and design elements relating to display and layout, and which are designed to render in client browsers for human consumption via Graphical User Interfaces (GUIs), such as HTML “webpages”.
Web APIs are served over HTTP, and typically return data in a structured format that contains addressable data within a hierarchical “tree” structure, with each leaf containing a data structure such as a string or array. The data formats most commonly used include the eXtensible Markup Language (XML) format (most commonly used within SOAP APIs) and the JavaScript Object Notation (JSON) format (most commonly in REST APIs), as well as newer languages and frameworks such as GraphQL. Interpreters and libraries for managing these data formats exist that allow the returned data to be parsed, and specific key/values within them to be addressed via their “path” within the data tree structure. Since each value can be uniquely addressed in this way, the returned data lends itself to machine-based processing since the data can be unambiguously parsed and assigned to variables by the processing interpreter at the client side. For example, take the following snippet:
{"widget": {
"window": {
"name": "main_window",
"width": 500,
"height": 500
}
}}
This allows the window name to be addressed in a form similar to the pseudo-code example below, dependent on the language used:
my parsedObject = JSON.parse(responseBody); my windowName = parsedObject.widget.window.name;
Whereas a web application interface in a traditional web application might provide a user with a button which, when clicked, returns a new page from the server for the browser to render, an API call will typically return a “blob” of this machine-parseable data, which lends itself to processing by computer code.
Web applications are traditionally modelled according to a three-tier architecture, consisting of three logical and physical computing tiers: the presentation tier is the user interface and communication layer of the application, the application tier (also known as the logic tier or middle tier) collects and processes information from the presentation tier in line with required business logic, and the data or database tier provides backend storage and management services for the service. Rather than being considered to be an alternative interface at the presentation layer in such a model, APIs are most often implemented as part of the business layer, providing both direct interaction for server-to-server and developer integrations, as well as the middleware for any supported in-house web application interfaces (websites).
APIs have historically been most heavily developed and deployed to support inter-host (server to server) communication between two computer systems, and perhaps most commonly within two businesses in order to provide partner integration services. However, in recent years, they have seen rapid adoption into alternative models in support of various alternative service delivery paradigms. In general, APIs can be classified as falling into one of three broad categories:
Partner APIs are the traditional heartland of API usage, in which a business develops and exposes an API to specific trusted partner organisations only for integration with its platform. Examples might include the exchange of stock and order information between retailers and wholesalers, the provision of financial reconciliation data between financial institutions, and various other data feed and Business-to-Business (B2B) integrations. The APIs in these partner integrations are exposed only to whitelisted partner organisations.
Private APIs are APIs that are exposed only internally within an organisation. There are various potential uses for such APIs, such as the exchange of data between different business units or regional entities within large enterprises and conglomerates. However, a more recent use of private APIs is in the development of web applications (either internal or external) that make use of the micro-service architecture paradigm. Micro-services are a variant of the service-oriented architecture (SOA) structural style which arranges an application as a collection of loosely-coupled services, with the advantage that developers of front-end applications do not need to concern themselves with the details of the application stack supporting the integration: interactions between each layer of the architecture are decoupled from one another (i.e. can be independently updated without impacting other layers) so long as they continue to implement functions as defined in an agreed service contract.
APIs can also be exposed publicly. This can in the most traditional form be used to offer developer integrations and similar services. However, it can also be used in support of direct communication with end users in client-server interactions: human end-users cannot make sense of data blobs returned by APIs, however communication with the API is performed by the client user-agent (web browser) and the responses processed by a client-side scripting language which then updates the page in-browser via modifications to the DOM. This second form of public API is commonly used as the primary mechanism used to deliver Single-Page Applications (SPAs). In SPAs, client-side script (e.g., JavaScript) is used to dynamically re-write portions of a rendered page within a web browser based upon data returned via (often asynchronously) HTTP AJAX requests directly to the API, rather than requesting full-page HTML content from the server.
API security can often be overlooked. Web application developers are, broadly, aware of vulnerabilities such as the OWASP Top 10 when developing web applications, but these barely or tangentially mention API security. Additionally, traditional security measures such as vulnerability scanning, and penetration testing may be focused by a client on their website front-end and not be extended to cover any supporting APIs.
This may not have been a significant issue historically when the majority of APIs were restricted to partner integrations and not exposed publicly without measures such as source restriction (whitelisting). However, APIs are no longer a niche or secondary form of traffic: the use of APIs in support of microservice architectures, cloud services, mobile applications and Single Page Applications (SPAs) means that API calls now represent 83 percent of web traffic, according to traffic review detailed in the Akamai State Of The Internet Security Report 2018. That figure may seem surprising to many, but it reflects the massive growth in API usage for client-initiated in-browser and in-app requests that massively out-scales the more traditional use of APIs for programmatic access to third-party services such as in Business to Business (B2B) back-end service communications. It also means that API security may need to be considered as the primary security focus for organisations in securing their web estate.
The majority of API traffic is now in the service of custom web applications and mobile applications, itself the result of digital transformations and cloud-based application deployment. The web is changing rapidly and, in this respect, the OWASP Top 10 standard may have failed to keep up with this shift in the last few years. For many organisations, a central API gateway or loose collection of unrelated service APIs may now represent the organisation’s primary interface with customers and partners, and consequently present its primary attack surface and area of greater vulnerability.
A study conducted by the University of Virginia researchers found out that API programmers, even after following the standard security practices, often deliver insecure code. They conducted research that determined that 67% to 86% of apps have security vulnerabilities that may be exploited by attackers.
APIs offer access to data at a more atomic level: that is, they often provide access to data at a rawer level (and in larger quantity) than do typical web interfaces, with the returned data blobs often structured directly on back-end data stores. A traditional web application will typically rely on a web application server endpoint performing rich functionality and “heavy lifting” of processing loads based on provided user requests, in response to a few key parameters provided by the user as request parameters or variables. For example, the user may send basic parameters such as
https://www.example.com/application?action=login&userIDusername=daniel
and the web application server will perform all the application logic required, often using multiple tiers of code in an MVC (Model View Controller) architecture or similar. The web application server will be tasked with structuring queries, making calls to retrieve details from a database system or differing stores and caches, verifying the user identity, making a decision on output, fetching a template, inserting per-user parameters, stitching together a large multi-byte and richly formatted HTML response document and finally serving it to the client as a single web document in HTML format ready for rendering:
HTTP/1.1 200 OK Date: Mon, 27 Jul 2009 12:28:53 GMT Content-Length: 88 Content-Type: text/html <html> <body> <h1>Welcome, daniel!</h1> </body> </html>
API traffic, on the other hand is generally based on solitary, atomic requests relating to specific data reads or writes only. An example might be the request sent in with the parameters
POST https://www.example.com/api/login/new HTTP/1.1 Host: www.example.com name=daniel
and the server response will be a JSON blob confirming only that the task was executed and the output status:
HTTP/1.1 200 OK
Date: Wed, 08 May 2019 11:26:05 GMT
Content-Type: application/json
Content-Length: 110
{
"errors": null,
"user_id": "123456",
"success": true
}
It is up to the requesting client or server code to place this data in appropriate context and – if being used within a client-facing application such as a mobile application or SPA – to render a human-readable response to a browser by merging the returned data elements into a locally-cached template to create a complete HTML document suitable for display.
As part of the wider “Web 2.0” paradigm, many developers are now producing dynamic web applications in forms such as Single Page Applications (SPAs), which are heavily reliant on client-side scripting using JavaScript, and in which the majority of processing now occurs client side-side in an application. In support of this, the traditional “fat” web-servers are replaced by a model in which there is a single API endpoint operating to process simple atomic requests with minimal processing and no server-side document rendering. The API returns data to the requesting client, which parses and processes API responses, and itself stitches them into a DOM that is rendered by the client-side browser, using a combination of templates and client-side logic written in JavaScript – the rendering component is the client, not the server.
This shift in development practices and its impact on traffic patterns has significant ramifications for application security and vulnerability scanning solutions. Many, if not most, controls that have been historically used to protect web applications are based on the MVC model outlined above and focused on using technologies that filter or monitor browser traffic, as well as providing filtering and patterns that protect against the risks present in a traditional web application model. The mechanisms necessary to apply the same controls to API traffic may be less understood by developers, less mature or robust, harder to configure, or lacking entirely in certain environments.
Although the risks from API security are very real, this article isn’t going to be entirely doom and gloom. The good news is that the risks to APIs are very similar to those in web applications. This means that developers should be familiar with issues that are associated with API’s as well as the remediation steps that are required in order to harden an API endpoint. This means that forward looking technical teams have an opportunity to get ahead of the curve and review and secure their APIs before exploits become more widespread by attackers.
Additionally, traditional vulnerabilities are less common in API-Based apps. Statistically, vulnerabilities such as SQL Injection may be less common in newly-developed APIs due to the increasing use of standardised Object-relational mapping (ORM) libraries in new code, and less direct addressing of SQL databases by in-house code. Likewise, the use of alternative authentication mechanisms in APIs such as OAuth 2.0 access delegation, reduces the risk of attacks based on techniques such as CSRF.
The unwelcome news however is that for every traditional vulnerability type not prevalent within APIs, there is a new vulnerability type that is.
Cloud security provider Akamai recently published their 2020 “State of the Internet” report, showcasing the growing trend of cyber-criminals targeting public API platforms worldwide. In a 2-year period, Akamai observed a staggering seventeen billion credential violation attacks involving API endpoints. In one vulnerability discovered by a security researcher, a Verizon API exposed the details of 2 million customer contracts without authentication.
APIs, as we have seen, present a range of security vulnerabilities, some that we are familiar with from traditional web application security, and some that are unique to APIs. APIs pose a unique challenge for security vulnerability scanners in that they are a sufficiently different model of server interaction that some techniques used in traditional vulnerability scanning are not effective. Specific challenges that prevent a traditional web application scanner from being effective in scanning APIs include:
So how can AppCheck help you in securing your APIs?
AppCheck includes specific API scanning technology that is able to build up a map of a scanned API using WSDL and OpenAPI/Swagger files, seeded targets and similar technologies, to ensure that the API is fully modelled and scanned.
AppCheck supports API authentication methods including API access keys to ensure that APIs can be authenticated against, and all methods fully probed for vulnerabilities.
AppCheck includes API-specific vulnerability checks written by our in-house penetration testers, to detect previously unknown vulnerabilities from first principles.
AppCheck help you with providing assurance in your entire organisation’s security footprint. AppCheck performs comprehensive checks for a massive range of web application vulnerabilities – including SQL injection and other database security weaknesses – from first principle to detect vulnerabilities in in-house application code. Our custom vulnerability detection engine delivers class-leading detection of database vulnerabilities and includes logic for multiple detection methods (including Time Delay Detection, Error Detection, Out of Band Detection and Boolean Inference) as well as a range of database products and platforms (including Oracle, PostgreSQL, SQLite, MSSQL, MySQL and Azure).
The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail, and proof of concept evidence through safe exploitation.
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure. AppCheck are authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA).
As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please contact us: info@localhost
No software to download or install.
Contact us or call us 0113 887 8380
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network and cloud infrastructure. AppCheck are authorized by te Common Vulnerabilities and Exposures (CVE) Program aas a CVE Numbering Authority (CNA)
