One of the most discussed topics on various IT-related blogs and forums is internet security. There is a logical explanation for this popularity: the number of security breaches has increased significantly in the course of the past five years. According to the statistics from the Global Data Risk Report (2018) by Varonis, more than 50% of organizations don’t bother protecting their data or invest into implementing advanced cybersecurity practices, which renders them defenceless and often results in major data losses. We won’t stop reminding you that your security must be preventive, especially if you work with REST APIs. Most developers working in this segment are willing to find optimal answers to solve this security challenge as it prevents normal growth of the entire API world. RESTful APIs share common vulnerabilities we will discuss in this article.
Web API and RESTful API – What Are Those?
Before we proceed to the list of vulnerabilities, let’s get acquainted with RESTful APIs and APIs in general. API is the abbreviation for Application Programming Interface. To make it less sophisticated, imagine a set of methods and classes that have a strict hierarchy that forms an operable interface. Via that interface developers can access the data or features of an application and perform various actions. Each operating system has its own APIs, which are used by software developers or services to create applications for that OS.
In terms of popularity, REST is easily ahead of many other APIs. REST means “Representational State Transfer.” The style was invented to optimize the usage of existing protocols. REST is extremely protocol-friendly style, which makes it more flexible for various development processes. Developers don’t need additional software/libraries to work on RESTful APIs. RESTful is just another way to name these APIs, so don’t get confused by the name.
Versatility is one of the main strengths of REST APIs. When the data required for the project is not limited to specific resources and methods, REST becomes an ultimate tool to manage various types of calls and formats, while also allowing changes in the structure. Such flexibility solves two questions at once – how to create a perfect app that meets the needs of the target audience and how to satisfy the owner of the app at the same time.
Most common .NET Vulnerabilities by Type
Now it is clear why RESTful APIs is the top choice for developers in many cases: less complicated project cycle, shorter development process, simpler (faster) deployment. However, there is always a fly or two in the ointment. With accelerated implementation, it becomes harder to maintain already released apps in terms of security, especially within one long-going project. New threats and exploits appear on the radar when you least expect them. Plus, their number is constantly growing, so it is recommended to know at least the most common ones to understand their nature and try to invent countermeasures before it is too late. Without any further ado, let’s get to the list of the most common RESTful vulnerabilities:
- Denial of Service
- Flawed authentication
- Information Exposure
- Improper Certificate Validation
- Privilege escalation
- Man-in-the-middle vulnerability
Severity level: High
According to statistics, more than 50% of RESTful vulnerabilities belong to this category. Denial of Service attacks can do serious damage by making the server stutter or stop responding under the onslaught of messages with falsified access requests. Such attacks have one main purpose – make websites as well as RESTful APIs inaccessible for users. Without proper security measures, downtime might cause serious indirect damage (reputation, revenue losses, etc.).
The vulnerabilities exploited by DoS attacks can be divided into these two types:
- Boosted consumption of CPU/RAM resources – in this case, the requests become so frequent that the system requires inadequate time to process them.
- Crash – the requests aimed at crashing the system completely.
In comparison with other attacks, this is probably the easiest way to disrupt the service. Since DoS have become a popular instrument for cybercriminals, organizations have to come up with countermeasures and plan ahead to protect their APIs from disruptions or outsource this task for the professionals. If you manage to trace DoS attacks and discover the IP address responsible for the requests, you can manually block. However, it is a short-term solution because nothing stops the attacker to switch to another address and continue harassing your API.
An alternative solution would be to apply request limits within short time intervals. For example, when your RESTful API receives too many requests in quick succession, disrupt the API key access for the time being, and send back the HTTP error code 429 (too many requests).
Severity level: Medium
Attackers either take control over the authentication process of your API or bypass authentication completely. This translates literally into having full access to passwords, API keys, and more. Also, cybercriminals get the same privileges as legitimate users within the system. The most common types of authentication-related attacks are brute-force, reflections, impersonations, and bypass attacks.
Ideally, only authenticated users must have access to the APIs. To protect your RESTful API from those we recommend implementing heavy authorization methods such as authorization with credentials as well as authorization with default keys. Basic authentication methods thrown into the mix won’t harm either. Use API keys, OpenId tokens, and PKI for this matter. Also, remind users to be cautious and never send sensitive information via unsecured connections.
Sensitive Information Exposure
Severity level: High
This includes credit card info, business details, personal data, and many other things that require extra protection from cybercriminals. When designing a RESTful API or any API in general, you need to determine what information it will process and store during operation. Then you must implement security measures to protect the most sensitive information. General recommendations for the process as we see it:
- Data analysis, classification, implementing appropriate controls for each class.
- Adding encryption.
- Disabling cache for the classes with sensitive information.
Use SSL to prevent sensitive data leaks. Also, the combination of SSL and TLS is one of the basic measures to patch some common API vulnerabilities without a hassle that is why everyone is using this method today.
Improper Certificate Validation
Severity level: High
As we mentioned in the previous paragraph, encryption and SSL certificates is a must, but those certificates need validation. This process also requires analysis and planning. Otherwise, you might have problems such as improper validation and other possible loopholes. Leave them unattended, and attackers will step in to play with falsified certificates and tools for traffic interception. It is another opportunity to steal sensitive user data we discussed earlier – passwords, personal info, API keys, and more.
An experienced hacker can easily create a certificate with a name that almost fully copies a trusted name so that most unsuspicious web clients won’t notice the difference. They will think they are using a legit thing and they trust it completely. The API will try connecting to a fake host taking it as a trusted one. Also, the software can be fooled to accept spoofed information that seemingly originates from a trusted host. After this “false validation” completes, hackers get access to user data.
Severity level: High
Unprotected software is vulnerable to injections that transfer a malicious code that initiates an attack. Most popular type in this scenario is SQL injections, while the second place goes to cross-site scripts. Injected API becomes a host of untrusted data and may continue spreading the infection even further. Most injection attacks end with providing unauthorized access to hackers. The most reliable practice for defending yourself from injections is adding input validation. Consider doing the following:
- Validate length, ranger, type, format for each input.
- Use numbers, dates, fixed data ranges, and times in the parameters of your RESTful API.
- Constrain string inputs via regex.
- Set size limits for requests (all requests over the limit should be rejected).
Severity level: High
Attacks of these type exploit known bugs and flaws in the API design to get to the data, functions, and options unavailable to users with standard access. Sometimes hackers can get elevated access, which grants them permissions to act as a developer. There are two types of escalation – vertical and horizontal.
Exploiting vertical escalation lets hackers reap all kinds of benefits available within API. For example, become a premium user with access to advanced features unavailable for standard users. It is the most “harmless” way of using privilege escalation vulnerability. It gets much worse when attackers gain full access to the app and start acting as an administrator. At this point, the damage caused by their actions is limited only by their imagination. Horizontal escalation is much harder to detect because attackers mask their actions by using the same functions and options as the other accounts within their league.
The optimal solution to protect your API from privilege escalation attacks requires implementing the Principle of Least Privilege. According to this principle processes and programs can only access the minimal number of resources required to get the job done. In other words, if your account has nothing to do with database updates, then you cannot do any database-related edits. Also, we would recommend you to have an automated monitoring system. The algorithm will analyze the network and users’ behaviour. Any irregular activity will be perceived as a threat resulting in an immediate block. Better safe, then sorry.
Severity level: Medium
Imagine two systems interacting with each other, transferring confidential information, etc. And then the direct connection between those two gets exploited by initiating a new connection going through the middle-man, the hacker. Now, all that data that was originally secured get through third-party. The main goal of this attack is yet again to steal, intercept, alter, or disrupt normal communications pretending that nothing sketchy is going on.
MITM attacks have two phases – interception and decryption. During the first stage, hackers intercept the outgoing traffic before it is delivered to the original recipient. Most popular techniques to get this done are IP/ARP/DNS spoofing. After the successful interception, the traffic hijackers need to decrypt it without causing any suspicion.
There are bad news and good ones. Five out seven most common vulnerabilities have high severity rank. There are only two medium vulnerabilities that cause fewer problems for RESTful APIs. And as for low-rank vulnerabilities – there are none. The good news is that every single issue on the list is solvable. There are always a few recommended remediation actions to follow, and some of them we briefly mentioned.
However, we still firmly believe that it is better to prevent vulnerabilities and patch loopholes in APIs before something bad happens. Don’t be afraid to outsource the security analysis to other companies if you don’t have a dedicated team to do it on your own. Plus, it never harms to have a second opinion on the project to make it more secured. If you have any questions related to known RESTful vulnerabilities, feel free to contact us and read our blog for more detailed articles on this topic.