Protecting computer servers from API attacks using coordinated varying of URL addresses in API requests

An application programming interface (API) security gateway communicates with a client computer application to establish a URL key rotation operation. An API request is received from the client computer application that is directed to a computer server. The API request contains a URL address. The URL address is parsed to identify a URL key. A local validation key is generated based on the URL key rotation operation. The URL key is validated based on the local validation key to determine whether the URL key is valid. Based on determining that the URL key is valid, a modified API request is generated which contains the URL address with at least part of the URL key removed. The modified API request is provided to the computer server.

TECHNICAL FIELD

The present disclosure relates generally to computer security and, more particularly, to computer security that protects networked computer servers from API requests generated by hackers and other maliciously operating client computer applications.

BACKGROUND

Application programming interfaces (APIs) are a set of subroutine definitions, protocols, and tools for building application software that accesses resources available through the Internet. APIs build of the basic architecture of the World Wide Web, and are based on application of the HTTP protocol. However, certain characteristics of HTTP make APIs vulnerable to attacks from hackers.

APIs use the stateless HTTP protocol, which is a foundational element of the architecture of the World Wide Web. APIs are most often designed to be stateless, both to align with the characteristics of the HTTP protocol, and to simplify the development of high volume systems that scale by instantiating many parallel instances of a service.

This property of statelessness makes APIs particularly vulnerable to exploitation by hackers. Hackers look for weak points in the security of systems. APIs create a point of interaction with applications that may be vulnerable to hackers. Since APIs are commonly stateless, a hacker has many chances to mount attacks without detection, because each API call received by an application stands alone outside of the context of a logical flow of transactions.

A hacker can experiment with repetitive varying hacking attempts to an API endpoint to discover vulnerabilities. For example, a hacker might mount fuzzing attacks against an API endpoint, which involve sending repeated transactions containing random variations in parameters of an API request. The attack seeks to determine if a specific combination of parameters will reveal an existing system vulnerability, such as a buffer overflow vulnerability or a failure to properly authorize unexpected requests for service. SQL Injection is another example of an attack that is generally fine-tuned through repeated experimentation. Unlike fuzzing attacks, SQL Injection is executed in a more guided and active manner; however, it still exploits the statelessness of HTTP and the static nature of the API endpoint.

The basic architecture of the web is built around resources that are exposed as URL-addressable endpoints. The URL contains a protocol, internet address, an optional port, and an optional string to distinguish between different APIs on a particular computer server. Every unique API has an associated unique web URL. Different APIs, such as getStockQuote( ) and buyStock( ), will by distinguished by their different URLs. For example, the former might be accessible at the URL “http://acme.com/apis/getStockQuote”, and the later at “http://acme.com/apis/buyStock”.

An attack against the buyStock API might involve sending a large number of requests to probe the “http://acme.com/apis/buyStock” endpoint. Because the computer server is stateless, this may appear to be legitimate traffic even if it is not successfully executing a financial transaction, especially if the attack is mounted over a relatively long period of time so that it is concealed by intervening legitimate traffic. Accordingly, APIs provided by a computer server are vulnerable to many types of attacks that are carried out through API requests from hacker and other maliciously operating client computer applications.

SUMMARY

Some embodiments disclosed herein are directed to methods by an application programming interface (API) security gateway. The API security gateway communicates with a client computer application to establish a URL key rotation operation. An API request is received from the client computer application that is directed to a computer server. The API request contains a URL address. The URL address is parsed to identify a URL key. A local validation key is generated based on the URL key rotation operation. The URL key is validated based on the local validation key to determine whether the URL key is valid. Based on determining that the URL key is valid, a modified API request is generated which contains the URL address with at least part of the URL key removed. The modified API request is provided to the computer server.

Some other related embodiments disclosed herein are directed to methods by a client computer. The client computer communicates with an API security gateway to establish a URL key rotation operation. A URL key is generated based on the URL key rotation operation. A URL address is generated based on a combination of the URL key and a starting URL address. An API request is generated containing the URL address, and is communicated toward the API security gateway.

Some other related embodiments disclosed herein are directed to an API security gateway that includes network interface circuitry, processor circuitry, and memory circuitry. The processor circuitry is coupled to the network interface circuitry. The memory circuitry is coupled to the processor circuitry and includes computer readable program code that when executed by the processor circuitry causes the processor circuitry to perform operations. The operations includes communicating through the network interface circuitry with a client computer application to establish a URL key rotation operation, and receiving through the network interface circuitry an API request from the client computer application that is directed to a computer server. The API request containing a URL address. The operations further include parsing the URL address to identify a URL key, generating a local validation key based on the URL key rotation operation, and validating the URL key based on the local validation key to determine whether the URL key is valid. Based on determining that the URL key is valid, the operations generate a modified API request containing the URL address with at least part of the URL key removed, and provide the modified API request through the network interface circuitry to the computer server.

It is noted that aspects described with respect to one embodiment disclosed herein may be incorporated in different embodiments although not specifically described relative thereto. That is, all embodiments and/or features of any embodiments can be combined in any way and/or combination. Moreover, methods, systems, and/or computer program products according to embodiments will be or become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such additional methods, systems, and/or computer program products be included within this description and protected by the accompanying claims.

DETAILED DESCRIPTION

Various embodiments will be described more fully hereinafter with reference to the accompanying drawings. Other embodiments may take many different forms and should not be construed as limited to the embodiments set forth herein. Like numbers refer to like elements throughout.

FIG. 1is a block diagram of a computer system that includes an API security gateway120that protects a computer server110from API requests received from client computers100athrough100x(individually referred to as client computer100), in accordance with some embodiments. The API security gateway120is connected to receive API requests (e.g., Web service API calls, RESTful API requests, etc.) through one or more data networks108(e.g., local area network and/or wide area network) from applications processed by one or more client computers100a-100x. The API security gateway120operates to validate received API requests based on URL addresses contained therein, and to forward valid API request to the computer server110for processing to allow access to various resources (e.g., application programs and/or data) provided by the computer server110.

Although the API security gateway120is shown as being separate from the computer server110, in some embodiments the API security gateway120is embedded at least partially within or entirely within the computer server110. Accordingly, the API security gateway120may communicate through the data network108with the computer server110or may communicate through a shared backplane bus or local network.

Various embodiments disclosed herein are directed to reducing security risks to a computer server110when processing API requests that are received through APIs provided to applications being processed by client computers, such as applications providing application-to-application Web services or other API application endpoints. Various types of hacking operations discussed above may be used to attempt to misuse/attack various services and other resources that are provided by the computer server110. The API security gateway120operates to intercept API requests generated by such hacking and other malicious operations, identify such API requests as being invalid, and prevent processing of invalid API request by the computer server110.

As used herein, an “API request” can be any signaling occurring from a client computer to a computer server or other API endpoint that may be performed using a defined syntax and one or more parameters (e.g., data structure, object classes, and/or variables) to obtain data from an addressed resource and/or to provide data to the addressed resource. For example, SOAP and REST service requests can be performed using a defined API library of remote calls or other types of API requests. The API client computers100a-100xor other types of source computers can be any type of computer that processes applications to generate API requests, such as Web service API calls, RESTful API requests, etc., and may include, but are not limited to desktop computers, laptop computers, tablet computers, smart phones, application servers, and mainframe computers. The computer server(s)110may correspondingly be any type of computer(s) having applications that expose services and/or resources through APIs and process API requests received through APIs, such as Web service API calls, RESTful API requests, etc., and may include, but are not limited to mainframe computers, application server equipment, desktop computers, laptop computers, tablet computers, and smart phones.

FIG. 2is a combined data flow diagram and flowchart of operations that may be performed by the client computer100, the API security gateway120, and the computer server110ofFIG. 1in accordance with some embodiments.

Referring toFIG. 2, the client computer100and the API security gateway120communicate with each other through the data network108to establish (block200) a URL key rotation operation. The communications may occur as part of a session initiation protocol (SIP) flow to establish a communication session between an application executed by the client computer100(called a “client application”) and the API security gateway120. Alternatively, the API security gateway120may be configured to monitor communications between the client application and the computer server110to observe messages exchanged during the SIP flow to establish a communication session between the client application and the computer server110. Accordingly, the API security gateway120may intercept and

The API security gateway120and the client application can establish a starting URL key, a rotation algorithm, and/or a rotation period, such as by various operations described below.

The client application generates (block202) an API request containing a URL address for a resource that it desires to access through an API interface provided by the computer server110. The URL address contains a URL key. The API security gateway120receives (block204) the API request, and parses (block206) the URL address to identify the URL key. The API security gateway120generates (block208) a local validation key based on the URL key rotation operation, and validates (block210) the URL key based on the local validation key to determine whether the URL key is valid.

The URL key rotation operation is configured to generate a local validation key that changes between each repetition of the URL key rotation operation based on one or more changing inputs to the operation that can include a time indicator, a message sequence number, and/or other information. The URL key rotation operation is not limited to eventually cycling back to repeat any previous key that has been generated, but instead in some embodiments can generate a random or pseudorandom sequence of local validation keys over numerous repetitions of the operation.

A decision (block212) is made as to whether the URL key is valid. Based on determining that the URL key is valid, the API security gateway120generates (block216) a modified API request containing the URL address with at least part of the URL key removed, and provides (block218) the modified API request to the computer server110requesting access to a resource that is addressed at least partially by the modified URL address with the at least part of the URL key removed.

The computer server110receives (block220) the modified API request, and processes the modified API request to access (block222) a resource that is addressed by the modified URL address. The computer server110then communicates (block224) an API response containing information that was obtained based on the accessed resource. The API response may be communicated directly to the client computer100via the data network108or may be relayed through the API security gateway120and the data network108. The client computer100receives and provides (block226) the API response to the client application.

Various related operations that may be performed by the client application executed by the client computer100are illustrated by the flowchart inFIG. 3. Referring toFIG. 3, the client application communicates (block300and block200ofFIG. 2) with the API security gateway120to establish a URL key rotation operation. The client application generates (block302) a URL key based on the URL key rotation operation, and generates (block304) a URL address based on a combination of the URL key and a starting URL address. The client application then generates (block306) an API request containing the URL address, and communicates (block308) the API request toward the API security gateway120.

In the following non-limiting example, the URL key can appear to an attacking (malicious) client application, such as one operated by hacker, to be a random number that is part of the URL address in an API request provided to an API interface of the computer server110or another API endpoint to access a resource. To the attacking client application, the URL key changes over time in an unpredictable manner to have the effect of “moving” the API address over time also in an unpredictable manner, making it difficult or impossible to mount repeated attacks on the API interface of the computer server110.

For example, a URL key can be added to a “buyStock” URL address to transform it to be: “http://acme.com/apis/3a0cb278c3c605a179b5/buyStock”, where the hexadecimal sequence “3a0cb278c3c605a179b5” is the URL key. The URL key is actually generated in a deterministic manner by a URL key rotation operation that has been established between a valid (authorized) client application and the API security gateway120. A valid client application uses the URL key rotation operation to generate the URL key that it then includes in the URL request that it sends to the API security gateway120, and the API security gateway120uses the URL key rotation operation to validate the URL key that it receives in the API request from the valid client application.

The URL key rotation operation can generate the URL key as a time-sensitive sequence from a starting URL key (e.g., initial seed value) and a rotation period value (e.g., a time period at which the URL key is repetitively changed) that has been established through communications between the client computer100and API security gateway120. The URL key rotation operation may operate to change the URL key regularly at an interval, such as every 10 minutes, that is defined by the rotation period value. A valid client application can generate a currently valid URL key from a combination of the present global time and the starting URL key, wherein the starting URL key has been predefined in the application or is received from an authorized user. The URL key will be congruent (e.g., match) a current URL key that is generated by the API security gateway120using the key rotation operation. The client application can use the generated URL key to communicate with the computer server110via the API security gateway120using the standard HTTP protocol.

The API security gateway120validates the URL keys contained in incoming API requests against a local validation key that is generated by the API security gateway120using the URL key rotation operation. Any API request calls from client applications for URLs that contain invalid URL keys can be dropped, since they clearly originate from client applications without access to the correct key rotation operation, such as because they don't have access to starting URL key and/or don't have access to the rotation period value. There can be any number of active, valid sequences running in parallel, so that different client applications can be easily distinguished and separately validated by the API security gateway120. If a client application is determined to have generated an invalid URL key (e.g., due to becoming compromised via a virus), its sequence can be invalidated and can be processed as invalid API requests.

In some embodiments, the URL key generated by the client application and the local validation key generated by the API security gateway120are generated using a cryptographic technique used in two-factor authentication products, such as RSA's SecurID. The generated key can be used as a one-time, two-factor authentication for the client application and the API security gateway120. The cryptographic technique is used to modify URLs in API requests to mask the location of the URL addresses. In effect, these operations may operate to make a unique authentication event happen continuously on each and every API request transaction. This is independent of any other application layer authentication and session tracking.

To an attacker, the URL addresses contained in a sequence of API requests will in effect be moving around on continuous and entirely unpredictable basis. Without a valid URL key rotation operation and its parameters (e.g., starting URL key, key rotation timing, etc.), the attacker cannot generate a valid URL address to the API of the computer server110and cannot mount even a single attack, let alone probe a stateless API over time to discover its vulnerabilities. The API becomes invisible, and so cannot be probed. This can discourage attempts to compromise a known API, and will make automated discovery of unadvertised APIs impractical.

Various countermeasures could be applied when an unauthorized access attempt is detected by the API security gateway120. These can range from an aggressive response (severing connection without reply, which may not advisable in some scenarios because it leaks information that an attack is detected), to responding with a standard HTTP 404 (not found) error code, which reveals nothing of value to an attacker and simply states that there is nothing at the requested computer server110. Because unauthorized access attempts are now so unambiguously identifiable by the API security gateway120, probing events can be better isolated and logged. This will minimize false positive alarms and make it more likely that operators will take additional action.

FIG. 4is a flowchart that illustrate operations that may be performed by the API security gateway120to generate a local validation key that it then uses to validate the URL key received from the client application in an API request. The API security gateway120communicates with the client application to establish (block200ofFIG. 2) the URL key rotation operation, which in the example ofFIG. 4includes receiving (block400) from the client application a message containing a starting URL key and a rotation period value as part of a SIP flow to establish a communication session with the client application. The API request is received through the communication session. Generation (block208ofFIG. 2) of the local validation key based on the URL key rotation operation, includes accessing (block402) a present timing indication which is synchronized with the client application, such as a reference clock that is accessible to both the client computer100and the API security gateway120via the network108, and processing (block404) the starting URL key, the rotation period value, and the present timing indication through the URL key rotation algorithm to generate the local validation key.

With continued reference toFIG. 4, corresponding operations that can be performed by a client application to establish the URL key rotation operation with the API security gateway120, can include sending a message containing a starting URL key and a rotation period value as part of a SIP flow to establish a communication session with the API security gateway120. The client application can then generate the URL key based on the URL key rotation operation, by operations that include: accessing a present timing indication which is synchronized with the API security gateway; processing the starting URL key, the rotation period value, and the present timing indication through the URL key rotation algorithm to generate the URL key; and communicating the API request through the communication session to the API security gateway120.

Although various embodiments have been described in the context of the URL key rotation operation being established through electronic communications (e.g., messaging communicated through one or more networks) directly between the client computer100and the API security gateway120, some of the underlying communications may be relayed indirectly through an intermediary device such as a cellular phone operated by a person. For example, the client computer100and/or the API security gateway120may send an out-of-band message containing the starting URL key, an identifier value which identifies the rotation algorithm to be used, and/or a value identifying the rotation period to be used. The out-of-band message may be sent through, for example, a text message or email message to the intermediary device, e.g., cellular terminal, which is then read and manually inputted to the intended end-receiving device (e.g., the client computer100or the API security gateway120) or who then electronically forwards the entire content or a selection portion of the content of the out-of-band message to the intended end-receiving device.

Operations by the API security gateway120to validate (block210) the URL key based on the local validation key to determine whether the URL key is valid, can include: hashing the URL key to generate a hashed URL key value; hashing the local validation key to generate a hashed local validation key value; and then determining whether the URL key is valid responsive to whether the hashed URL key value matches the hashed local validation key value. The URL key may be determined to be valid only when the hashed URL key value matches (e.g., is numerically equal to) the hashed local validation key value.

Based on determining (block212ofFIG. 2) that the URL key is not valid, the API security gateway120can operate to terminate the communication session with the client application. Termination of the communication session may include operating the API security gateway120to send a message to the computer server110that contains a command for the computer server110to terminate the communication session with the client application. Termination of the communication session with the client application can advantageously cut-off the ability of the client application to continue testing the computer server110through the communication session for vulnerabilities in its API interface. The communication session may have been set up as a trusted (e.g., encrypted) session which may have been granted privileges that become revoked for the client application by termination of the session.

Alternatively, the API security gateway120can respond to determining (block212ofFIG. 2) that the URL key is not valid, by sending through the communication session to the client application an API response containing data indicating that the resource addressed by the URL address was not found and preventing the received API request and the modified API request from being provided to the computer server110. By preventing the API requests from being provided to the computer server110, the computer server110is thereby protected from the possible malicious testing of its API interface, and prevents burdensome processor loading that would otherwise result for the computer server110to attempt to process the API request. Responding to the client application in this manner may be beneficial by tricking the client application into believing that the computer server110receives and process the API request and attempt to access the addressed resource.

FIG. 5is a flowchart that illustrate alternative operations that may be performed by the API security gateway120to generate a local validation key that it then uses to validate the URL key received from the client application in an API request. The API security gateway120communicates with the client application to establish (block200ofFIG. 2) the URL key rotation operation, which in the example ofFIG. 5includes receiving (block500) from the client application a message containing a starting URL key as part of a SIP flow to establish a communication session with the client application. The API request is received through the communication session and further contains a message sequence number. The API security gateway120may parse (block502) the URL address to identify the message sequence number. Generation (block208ofFIG. 2) of the local validation key based on the URL key rotation operation, includes processing (block504) the starting URL key and the message sequence number through the URL key rotation algorithm to generate the local validation key.

With continued reference toFIG. 5, corresponding operations that can be performed by a client application to establish the URL key rotation operation with the API security gateway120, can include sending a message containing a starting URL key as part of a SIP flow to establish a communication session with the API security gateway120. The client application can then generate the URL key based on the URL key rotation operation, by operations that include processing the starting URL key and a message sequence number through the URL key rotation algorithm to generate the URL key. The message sequence number is generated to identify an API request, and may be generated to uniquely identify an API request from among a sequence of API requests, each having different message sequence numbers, that the client application sends to the API security gateway120within a same communication session. The client application embeds the message sequence number in the API request, and communicates API request through the communication session to the API security gateway120.

FIG. 6is a flowchart of operations that may be performed by the API security gateway120to generate (block216ofFIG. 2) in accordance with some embodiments. Referring toFIG. 6, the API security gateway120shortens (block600) the URL address to remove the URL key and generate a shortened URL address, and embeds (block602) the shortened URL address in the modified API request. In one embodiment, the URL address that the API security gateway120receives (block204ofFIG. 2) in the API request is not a resource address that identifies to the computer server110a particular resource being requested by the client computer application, and the shortened URL address is a resource address that identifies to the computer server110the particular resource being requested by the client computer application.

Further to the above example, the API security gateway120can shorten the URL address “http://acme.com/apis/3a0cb278c3c605a179b5/buyStock”, which is received in the API request from the client application, to remove the hexadecimal sequence “3a0cb278c3c605a179b5”. The shorted URL address of “http://acme.com/apis/buyStock” is provided in the modified API request to the computer server110. In this example, the URL address that is received in an API request would not be recognized by the computer server110as a proper address for a resource that is accessible through the computer server110. In sharp contrast, the shortened URL address is recognized by the computer server110as a proper resource address.

FIG. 7is a flowchart of some other operations that may be performed by the API security gateway120to generate (block216ofFIG. 2) in accordance with some other embodiments. Referring toFIG. 7, the API security gateway120accesses (block700) a resource address translation data structure using the URL key as a pointer to retrieve a URL address segment. Resource address translation data structure provides a one-to-one mapping between individual URL keys among a set of defined URL keys to individual URL address segment among a set of URL address segments. The gateway120replaces (block702) at least part of the URL key in the URL address with the URL address segment to generate a combined URL address, and then embeds (block704) the combined URL address in the modified API request. In one embodiment, the URL address having the at least part of URL key removed is not a resource address that identifies to the computer server110a particular resource being requested by the client application, and the combined URL address having the at least part of the URL key replaced in the URL address with the URL address segment is a resource address that identifies to the computer server110a particular resource being requested by the client application.

By the operations ofFIG. 7, the API security gateway120using the resource address translation data structure effectively hides from the client application the proper resource addresses that must be provided to the computer server110to properly address its resources. The client application is thereby only able to access a resource on the computer server110if it includes a valid URL in a URL request, otherwise the URL request does not contain a complete resource address that can be used by the computer server110to access a resource. Moreover, the client application must have its API request processed through the API security gateway120in order to have the URL address contained therein transformed into a modified URL address that is provided through the modified API request to the computer server110.

In some related operations, the client application can operate to obscure the URL address in an API request from other applications that are operating on the client computer100and/or on other client computers that be able to observe communications between the client application an API security gateway120.FIG. 8is a flowchart of operations of may be performed by a client application being executed by the client computer100to obscure the URL address in an API request. Referring toFIG. 8, generation (block202ofFIG. 2) of the URL address by the client application can include receiving (block800) an API call from another application executed by the client computer100. The client application obtains (block802) the starting URL address from the API call. The starting URL address provides a full address identifying to the computer server110a particular resource being requested by the other application. The client application then combines the URL key and the starting URL address to generate the URL address, where the combining may include replacing (block804) a portion of the starting URL address with the URL key to generate the URL address which no longer provides the full address identifying to the computer server the particular resource being requested by the application.

The various operations and methods disclosed herein can reduce security risks to computer servers when processing API requests that are received through APIs that the computer servers provide to applications. API security gateways can effectively shield the computer servers from at least some attempts to hack or otherwise obtain improper access to resources of the computer servers.

FIG. 9is a block diagram of an API security gateway120that can be configured to perform operations in accordance with some embodiments. Referring toFIG. 9, the API security gateway120can include a network interface circuitry930which communicates via the one or more data networks108with the client computers100a-100x, the computer server(s)110, and other components of the system. The API security gateway120includes processor circuitry910and memory circuitry920that contains computer program code922which performs various operations disclosed herein when executed by the processor circuitry910. The processor circuitry910may include one or more data processing circuits, such as a general purpose and/or special purpose processor (e.g., microprocessor and/or digital signal processor), which may be collocated or distributed across one or more data networks (e.g., network(s)108). The processor circuitry910is configured to execute computer program instructions among the program code922in the memory circuitry920, described below as a computer readable medium, to perform some or all of the operations and methods for one or more of the embodiments disclosed herein.

FURTHER DEFINITIONS AND EMBODIMENTS