A new level of security thanks to a correct API management
Read the main article by Gianantonio Dehò – Practice Manager Innovation Software Lab, Bizmatica.
Source Wikipedia: “In a computer program, with Application Programming Interface (API), in Italian” programming interface of an application “, a set of procedures (generally grouped by specific tools) are indicated to solve a specific communication problem between different computers or between different software or between different software components; often this term designates the software libraries of a programming language, although more properly the API is the method by which the libraries are used to solve a specific problem of exchange of information.”
In the era of the digital explosion, APIs are definitely the preferred method for designing and building modern applications, especially for microservice architectures, the mobile world and for IoT devices.
Although the concept of feeding an application with information from external sources is not new, the strong drive towards innovation and the consequent evolution of apps highlights that some organizations may not yet have understood the potential risks associated with making them available of their API audience.
Most organizations already have measures in place to fight against known attacks such as cross-site scripting, injection, distributed denial-of-service, and others that can undermine API security, but protection “from the outside” isn’t always effective.
The concept of “security by design” is certainly one of the best practices to be adopted in this field, and the onStage team constantly follows and implements the OWASP guidelines on security.
Common ways of attacking API
- Injection;
- Distributed Denial off Service (DDos);
- Man in the Middle:(MitM);
- Cross Site Scripting (XSS);
- Credential Guessing;
- Gestione impropria degli Endpoint;
- Monitoring insufficiente;
Common Ways of attacking APIs
Injection
- A very broad category of attack vectors, including some of the most serious application security risks. The common denominator of nearly all injection attacks is that attackers are able to insert non-validated user inputs directly into the code of the executed application.
Distributed Denial of Service (DDoSs)
- A DDoS attack is an attempt to bypass the normal traffic of a server, service, or network by loading the target or surrounding infrastructure with a huge flow of Internet data traffic.
Man in the Middle (MitM)
- A MitM attack is a type of attack where the attacker intercepts and controls the communication between two parties that talks about communicating directly with each other.
Cross Site Scripting (XSS)
- XSS attacks are a type of injection, where malicious scripts are injected into benign and trustworthy websites. XSS attacks should be sent when an attacker uses a web application to send a malicious code, usually in the form of browser-side script, to a different end user.
Credential Guessing
- Credential stuffing is an attack method where attackers use lists of compromised credentials to breach a system. The attack uses bots for automation and scalability and is based on the assumption that many users reuse usernames and passwords across multiple services.
Improper management of the Endpoint
- In applications that have been in production for a long time, it is common for endpoints that are no longer used, outdated or even obsolete to remain reachable. The presence of these “abandoned” endpoints can be used as an attack vector.
Insufficient Monitoring
- If the logging and monitoring infrastructure is not sufficient, it could be possible generate situations where is not possible to notice that there is an attack in progress, making the reaction capacity very low. Well-structured logging also allows for subsequent analysis to be able to implement appropriate corrective measures after the attack.
Common Ways of attacking APIs
| Attack type | onStage | Other Systems |
|---|---|---|
| Injection | Serialization and deserialization of incoming and outgoing data to known business entities. Validation and sanitization of incoming data. | Validation and sanitization of all incoming data; limitation of data in the response to avoid the leakage of unnecessary data. |
| DDoS | Throttling configuration for single endpoint, progressive anti-hammering (automatic), alerting mechanism on suspicious behavior of the caller. | Use of tools to limit calls (throttling) and to limit the size of the data for each request / response (payload). |
| MitM | HTTPS only, encryption of the payload. | Encryption of inbound and outbound traffic. |
| XSS | Validation of incoming data. | Validation of incoming data. |
| Crediental Guessing | Endpoint monitoring through the onStage web console, connecting clients through an API Key and a Client ID. | Control of bruteforce attacks, detection and segregation of the caller. |
| Improper Endpoint Management | Granular management of endpoints through the onStage web console. | Periodic maintenance and disabling of obsolete endpoints. |
| Insufficient Monitoring | Dashboard for monitoring logs and endpoint call statistics. | Statistical analysis of performance and periodic analysis of logs. |
onStage Best Practices
The Best Practices adopted by OnStage for API security follow the OWASP guidelines and are as follows:
Security prioritization
in the development of onStage, security is seen as the first objective.
API first
onStage implements the principle by providing tools to simplify the design of the API, the generation of code to guide the implementation, documentation and automatic creation of mock scripts.
Always TLS!
onStage obliges users to have HTTPS as the only available option.
Strong Authentication and Authorization
The client connecting to onStage is authenticated through an API Key and a Client ID, and is uniquely authorized. Access to each endpoint is granular and configurable, the communication protocol is secure and encrypted. onStage integrates with SAML, OpenID, OAuth2, JWT providers.
Principle of "minimum privilege" (Zero trust philosophy)
Access to the API is never enabled by default. It is necessary to configure onStage and explicitly give access to endpoints to users.
Only necessary information.
The definition of the interfaces and of the input and output data models forces the system to manage only the strictly necessary information, filtering the data at the source. The input data is processed by the frontend-layer, typed, deserialized a business entity, validated and if classified as compliant, sent to the business process layer.
Throttling/Rate limiting.
In onStage you can configure the number of calls per second that each endpoint can receive. Calls are queued in the order of arrival and then “queued” in compliance with the configured limits.
Advices
We assist our customers who use onStage during all stages of implementation.
Biography Gianantonio Dehò – Practice Manager Innovation Software Lab
After having achieved his specializations in Oracle, Gianantonio Dehò has been working in the Software Developing industry for over 20 years, becoming then Practice Manager – Software Innovation Lab of Bizmatica Econocom, developing internal and external applications, aimed at supporting continuous digital innovations and process optimization. , also supporting customer activities by observing the best practices to be adopted.