With APIs becoming foundational to modern app development, the attack surface Attack surface refers to all entry points through which an attacker could potentially gain unauthorized access to a network or system to extract or enter data or to carry out other malicious activities. One problem with some APIs, as we’ll see shortly, is that they provide weak access control and, in some cases, none at all. The difference is that many websites at least employ some type of access control, requiring authorized users to log in.
Vulnerabilities exist in every system “zero-day” vulnerabilities are those that have not yet been discovered., an API endpoint is similar to any Internet-facing web server the more free and open access the public has to a resource, the greater the potential threat from malicious actors. In terms of potential vulnerability A vulnerability is an inherent weakness in a system (hardware or software) that an attacker can potentially exploit. By design, APIs give outsiders access to your data: behind every API, there is an endpoint-the server (and its supporting databases) that responds to API requests (see Figure 1). The downside of publicly available web APIs is that they can potentially pose great risk to API providers. Understanding the Potential Risks of APIs And ultimately, APIs benefit consumers, who appreciate (and drive demand for) innovative, feature-rich, interactive apps that provide many services all in one app. APIs also benefit providers, who are able to create new revenue streams by making valuable data and services available to developers, usually for a fee. APIs benefit app developers by simplifying the coding process and granting them access to a wealth of data and resources they would not otherwise be able to access. The example we gave was a travel app, which uses web API calls to pull in availability and pricing information from various hotel, airline, cruise line, tour, car rental, and other companies. It is not QA tested, provided as is, and therefore should be considered as proof of concept only with no warranties or guaranties implied to Axway in regard to its use whatsoever.In part one, we learned that web APIs (application programming interfaces) provide a way for app developers to “call” information from outside sources into the applications they build. This script is not part of the Secure Transport product. Note that it works on Linux OS and requires the following libraries to be installed: bash-4.1.2-15, perl-XML-Twig-3.34-1, coreutils-8.4-31.0.1, curl-7.19.7-37. The attached 'check_cert_info.sh' bash script demonstrates one possible implementation. To be able to extract the useful information from the raw data it has to be processed and formatted in a way that serves the current needs. It looks like this.ĬN=Account1_Private_x509cert1,OU=GSS,O=Axway,L=Sofia,ST=Bulgaria,C=Bulgaria To display the available information for all certificates:Ĭurl -k -X GET -H "Content-Type: application/xml" -H "Accept: application/xml" display the available information for the local server certificates:Ĭurl -k -X GET -H "Content-Type: application/xml" -H "Accept: application/xml" display the available information for trusted CAs:Ĭurl -k -X GET -H "Content-Type: application/xml" -H "Accept: application/xml" display the available information for accounts' login certificates:Ĭurl -k -X GET -H "Content-Type: application/xml" -H "Accept: application/xml" display the available information for accounts' partner certificates:Ĭurl -k -X GET -H "Content-Type: application/xml" -H "Accept: application/xml" display the available information for accounts' private certificates:Ĭurl -k -X GET -H "Content-Type: application/xml" -H "Accept: application/xml" output displayed is only a raw data. The following commands using 'curl' shows how the RESTful API services can be used for this purpose. Starting from Secure Transport 5.2.x versions this information can be obtained through the Administrator's RESTful API. The main task while maintaining the Secure Transport server and account certificates is to identify the expiration time of each certificate. The existing 'ckcerts' in the $FILEDRIVEHOME/bin folder provides information limited to the local server certificates and the internal CA. Maintaining these certificates by knowing which certificate expires when, can become a challenging task over time. They are used for various purposes - authentication, encryption, decryption, certificate validation, etc. Secure Transports stores different public and private certificates and keys.