With Representational Stateful Transfer technology (commonly known as RESTful architectures) rise to prominence, developers have witnessed the emergence of some seemingly undetectable security issues. These problems, however, are absolutely avoidable and this article will address some of the challenges and security issues that developers have been facing with RESTful architectures. And of course we'll provide ways to avoid them:
A standard RESTful URL usually has a unique resource name and resource ID tagged to a particular user such as /users/100.
1.Issue: In general, you can only view your information, instead of others users'. For such RESTful URLs, however, attackers are likely to change the user ID in this URL from 100 to another value, in an attempt to check information of other users.
Solution: Given that this security risk is too apparent, most of the applications validate the identity of the current requester to confirm whether it is the user with the same ID. Once the validation completes, the application returns the information of the specified user in the URL. If the validation isn't successful, it rejects the current request. When there is also one resource in the URL, a vast majority of applications implement security defense.
2.Issue: When the URL contains multiple resources, the application only validates one of the resources. For example, in the RESTful URL, for a user to check the order: /users/100/orders/280010, the application only checks whether the current requester is the user with an ID of 100, and whether the order of an ID of 280010 exists.
There is a high probability that the application fails to check for the subordination of the order and user in the URL. The result is that the attacker can modify the order number in the URL to traverse all the order information in the system, and even initiate operations on orders of other users, such as canceling an order. In fact, if the number of resources in the URL increase, such absence of subordination validation will become more prevalent.
Solution: For such applications with two or more resources in the URL, like the below one: /ResourceA//ResourceB//ResourceC/ you should perform subordination checks for these resources before operating them, primarily to ensure the current requester has the required access and operation permissions.
Precisely, some security-related headers exist in the HTTP responses. To guarantee higher security levels, reasonable use of these headers without increasing the workload of developers dramatically is necessary, and it makes it quite cost-effective as well. However, these headers are by default disabled in most of the cases and are missing in many applications. Below are some of the common security headers:
1.X-Frame-Options:
To prevent applications from click jacking attacks, you can use X-Frame-Options:
Use DENY to send explicit instructions to the browser not to display the current HTTP response content in the HTML Frame.
2.X-Content-Type-Options:
When the browser receives the HTTP response, it tries to deduce the type of the response content based on its rules and execute the subsequent operations. Such a move, however, may cause security problems.
For example, although the Content-Type of an HTTP response that contains malicious JavaScript code is image/png, the browser will deduce that this is a script and will execute it.
X-Content-Type-Options is the header specialized in solving this problem. Set it to X-Content-Type-Options: nosniff, and the browser will stop following its bent to deduce the type of the HTTP response content. Instead, it will parse the response content considering the Content-Type specified in the response strictly, thereby ensuring the security of the content.
3.X-XSS-Protection
The best solution to avoid Cross-Site Scripting (XSS in short) vulnerability in the application is by not allowing absolute freedom in putting distrusted data into an HTML document. To resolve this, the browsers usually are nested with XSS protection capabilities.
To enable the XSS protection feature of browsers, you only need to add the following in the HTTP response:
X-XSS-Protection: 1; mode=block. In the header, the number 1 indicates enabling the XSS protection feature; the "mode=block" tells the browser to block the current to-be-rendered content immediately in case of any discovered XSS attacks.
4.Strict-Transport-Security
Transport Layer Security (TLS) helps to ensure data security during data transmission. Add the Strict-Transport-Security header in the HTTP response to instruct the browser to initiate an HTTPS request directly, instead of sending a plaintext HTTP request first. The browser then sends the subsequent HTTPS request upon receipt of the navigation instruction from the server. In addition, when the browser finds the data transmission channel unreliable after it receives this header, it will directly reject any data transmission, and disallow the user to transmit data using the unsafe channel to avoid data leakage.
1.Incremental IDs
Issue: Resource ID is a critical component of a RESTful URL. In most of the cases, the system uses numbers to represent resource IDs. Such an arrangement gives room for the inadvertent disclosure of business information, and the leaked information may be just what the competitor is after assiduously.
Taking an example of a RESTful URL /users/100 for viewing the user information, the attacker can know the user scale of the current application through the ID since the user ID is an incremental number. Additionally, it makes it possible to deduce the number of newly increased users in a month just by signing up on the application at the beginning and the end of the month and comparing the two user IDs. Similarly, if the order number is also incremental, the attacker can also find the number of orders placed within a given period.
Although such IDs will not produce any technical threats to the application, the disclosure of such inside information through the ID may prove quite sensitive for your business.
Solution: Stop using incremental numbers for resources such as the IDs, etc. In fact, try using random, unique, and unexpected values or adopt Universally Unique Identifiers (UUID) to ensure uniqueness and security of the data.
2.Return redundant data
Issue: The backend and front-end usually adopt JSON for data transmission when they are separated. The JSON data returned by the backend APIs contains much more than what the front-end code requires, hence the data leakage. For example, the front-end intends to request the order information, but JSON order data returned by the backend API also contains a lot of "interesting" data.
{"id": 280010,
"orderItems": [...],
"user": {
"id": 100,
"password": "91B4E3E45B2465A4823BB5C03FF81B65"
},
...
}
In the above example, the order data contains the user information, as well as the password field of the user which is the most critical aspect.
Solution: Filter out the sensitive data not needed by the front-end before it finds its way to the front-end. You need to make the entire application processing of JSON data following this approach strictly to eliminate any omissions.
1.Issue: For multiple APIs solving different purposes in the application, there have been instances when attackers try to overrun the APIs by overusing its functionality and going beyond a limit.
For example, the API used for sending the text message verification code on user registration does not impose a limit on the frequency. Due to this, the attackers can hammer requests for a text message verification code from the server using a script. Such hammering will lead to exhaustion of the text message quota within a short period, or text message gateway congestion among other consequences. Among the possible implications would be an impairment of the message-sending API, or the exposure of other sensitive APIs to security problems because of the absence of a request frequency limit.
Here is another example, if the API for user login lacks such frequency limits, the attacker can exploit this vulnerability for brute force username and password-cracking.
One more example could be for server-resource-consuming APIs; if such APIs lack frequency limits, the attacker can exploit this vulnerability to launch DDoS attacks.
Solution: The principle for solving such security problems is to impose appropriate limits on API request frequency. Numerous specific practices exist, and the most typical one will be the image verification code. Other methods also include statistics evaluation on the request frequency using the Expire feature of Redis, or even joint defense leveraging O&M (such as web firewalls).
It goes without saying that the development of a secure application is no easy task. The issues mentioned in this article largely focus on some of the issues that may arise when using the RESTful architecture. The root cause for the emergence of these challenges lies in the lack of sufficient specification and attention on application security during application development.
Besides, the development team remains too focused on the backend implementation of business functions, often at the expense of the security perspective. To avoid these security problems, we recommend you nip the problems in the bud by incorporating the security measures mentioned in this article.
References:
Threat Modeling (https://www.owasp.org/index.php/Application_Threat_Modeling )
Security Acceptance Standards (https://www.cert.org/secure-coding/research/secure-coding-standards.cfm)
2,599 posts | 764 followers
FollowAlibaba Clouder - June 23, 2020
PM - C2C_Yuan - August 23, 2023
Alibaba Cloud Community - August 5, 2022
Alibaba Clouder - May 10, 2018
Alibaba Clouder - October 12, 2019
Alibaba Cloud Native Community - January 26, 2024
2,599 posts | 764 followers
Follow
Architecture and Structure Design
Customized infrastructure to ensure high availability, scalability and high-performance
Learn More
DevOps Solution
Accelerate software development and delivery by integrating DevOps with the cloud
Learn More
SOFAStack™
A one-stop, cloud-native platform that allows financial enterprises to develop and maintain highly available applications that use a distributed architecture.
Learn More
Intelligent Advisor
An intelligent tool that can be used to perform quick inspections on your cloud resources and application architecture to detect underlying risks and provide solutions.
Learn MoreMore Posts by Alibaba Clouder