Synthetic Monitoring
API TESTING SERIES
API development, either SOAP or REST, starts out with a discussion of functionality – What is the API supposed to do? Once the API is developed to perform that function there may be little thought given to the security that is required surrounding the API. This is a mistake as APIs should be treated like all other transactions and be vetted as thoroughly.
The main reason is that API Attack surfaces are larger. Applications are being broken down into micro-services and doing that creates a large number of interfaces and exposes those interfaces to the public internet. This creates a significant number of attack surfaces, making it so that hackers no longer need to attack a single application. They can look at lots of services, creating a bigger risk that they can get access to data.
Download our eBook, Testing in the API Economy & Why it’s Critical to your Organization
This makes it critical to keep security in mind when testing, as well as developing, APIs.
API Testing, a list to keep in mind:
- Verification and encryption. APIs cannot intuit that they are connecting to a fake website, so it is important to create a level of trust that the API is connecting to the application it is intending to content. API transactions should also be encrypted to ensure the security of the API transaction. Both of these requirements can be achieved through the use of TLS certificates and the use of HTTPS.
- Business Logic Flaws. APIs are designed to support a large variety of client devices. From traditional desktops to mobile devices, smart televisions, gaming consoles and even nodes in the Internet of Things, access to application functionality has to be available and fully functional in order to be useful. APIs are also designed to provide access to a subset of endpoints in the host system. That is, data is supposed to be accessed in a very specific manner. That’s the entire reason for having APIs, to create structure and boundaries. Attackers try alternative routes and calls to obtain data outside those boundaries. They do this by exploiting Business Logic Flaws in the design of the API. Facebook is just one noteworthy organization that has fallen victim to business logic flaws attacks.
- DoS Attacks – APIs are as affected by flooding and other DoS attacks as the human application interface. These attacks are intended to overwhelm the API with requests, crippling its ability to respond. Normally an API has no way to limit the number of calls it can receive allowing it to be flooded and shut down, or made so busy that it affects quality of service (QoS) for legitimate users.
- Cross-Site Scripting (XSS) – Compromised APIs can inject malicious code onto web pages and even clean APIs are incapable of discovering tainted content and, since the source of information retrieved by the API is trusted, high-level access to confidential content can be granted to an attacker.
Twitter is just one site that has suffered this type of attack.
- SQL Parameter Attacks – Tainted APIs can try to inject malicious SQL statements into an entry field for execution, such as instructing the database to dump the database contents to the attacker.
- Malicious Code Injection – manipulates security design flaws to send valid code to services using regular application statements to open up the interface for any user to cause harm.
- Business Logic Attacks (BLA) – BLAs abuse the functionality of the application, attacking the business directly. As opposed to traditional application attacks, business logic attacks do not contain malformed requests and include legitimate input values making this sort of attack difficult to detect.
- Service Information Leakage – This is when an API inadvertently leaks data about its configuration, resulting in the ability to take control or expose private data. Broken Session IDs, Keys and Authentication can create exposure to unauthorized access via authentication factors that are not functioning due to poor security design or technology bugs.
API Security Best Practices
Security often finds itself coming in third behind functionality and performance. This can be because the frameworks and components that are used are trusted to be “secure” and warrant no further assessment in this regard. Instead, a better approach to security testing should include:
- API Requirements, making security visible in requirements and backlog processes and keeping it on the same level as performance, functionality, and usability.
- Knowledge: stress security best practices and testing among your developers and testers so they understand how to guard against the most common security breaches.
- Prevention: Test and assess security early in your project and continue the practice through to the end. It is critical not to leave security testing to a single individual at the end right before production.
- Monitoring: Continuously monitor your applications for security vulnerabilities using available tools or homegrown solutions – as you would performance and functionality.
- Awareness: Make use of free tools and resources (like those available at OWASP) to get an overview of relevant vulnerabilities and how to make sure your APIs are not affected.