Security Guidelines for Temporary Keys Used for Direct Transmission from the Frontend to COS

Overview

In mobile and web applications, you can initiate requests to COS directly on the frontend by using the iOS/Android/JavaScript SDK. Data upload and download do not pass through the backend server. In this way, you can reduce the bandwidth usage and load of the backend server and make full use of various capabilities of COS, such as bandwidth and global acceleration, improving the user experience of your application.

In actual application, you need to use a temporary key as the signature for frontend COS requests to avoid problems, such as leakage of the permanent key and unauthorized access. However, if you specify excessive permissions or paths when generating a temporary key, even though a temporary key is used, problems such as unauthorized access may still occur, which brings risks to your application. This document describes some risk cases and security regulations that you need to comply with for your application to securely use COS.

Prerequisites

This document assumes that you fully understand the concepts related to temporary keys and can generate and use temporary keys to send requests to COS.

Risk Cases and Security Regulations

Risk Case 1: The Value Range of the resource Field Exceeds the Limit

Application A uses COS when registered users upload avatars. Each registered user's avatar has a fixed object key app/avatar/<Username>.jpg, and different avatar sizes are included, corresponding to object keys app/avatar/<Username>_m.jpg and app/avatar/<Username>_s.jpg, respectively. For convenience, the backend directly sets the resource field to <BucketName-APPID>/app/avatar/* when generating a temporary key. Malicious users can obtain the generated temporary key through network packet capturing and other means and overwrite any user's avatar, leading to unauthorized access and loss of legitimate avatar data.

Security Regulations

The resource field indicates the resource path that can be accessed with a temporary key, and the users covered by this path need to be fully considered. In principle, resources specified by the resource field should only be used by a single user. The specified <BucketName-APPID>/app/avatar/* in this case obviously covers all users. Therefore, a security vulnerability exists.

In this case, you can change the user's avatar path to app/avatar/<Username><size>.jpg. You can set the resource field to <BucketName-APPID>/app/avatar/<Username>/* to meet the regulation requirements. In addition, multiple values of the resource field can be sent in the form of an array. Therefore, you can also explicitly specify multiple resource values to limit the final resource paths the user is authorized to access, for example:

"resource": [
    "<BucketName-APPID>/app/avatar/<Username>.jpg",
    "<BucketName-APPID>/app/avatar/<Username>_m.jpg",
    "<BucketName-APPID>/app/avatar/<Username>_s.jpg"
]

Risk Case 2: The Value Range of the action Field Exceeds the Limit

Application B offers a public photo wall feature, and all photos are stored under app/photos/*. The client needs to list objects (GET Bucket) and download objects (GET Object). For convenience, the backend directly sets the action field to name/cos:* when generating a temporary key. After malicious users obtain the generated temporary key through means like network packet capturing, they can perform all object operations (such as upload and delete) on any object under this resource path, leading to unauthorized access, which causes data loss and affects online businesses.

Security Regulations

The action field indicates the operation requests that are permitted by a temporary key. In principle, temporary keys that allow all operations, such as name/cos:* should not be issued to the frontend. All necessary operations should be explicitly listed, and if the resource paths required for different operations vary, the action and resource paths should be matched separately, rather than specifying them in batches.

In this case, you should use "action": [ "name/cos:GetBucket", "name/cos:GetObject" ] to specify specific operations.

Risk Case 3: The Value Ranges of the action and resource Fields Exceed the Limit

Application C offers a management tool that allows users to list and download everyone's files (app/files/*) but can only upload and delete files in their own directories (app/files/<Username>/*). For convenience, the backend mixes the two permissions, that is, four operations (actions) together when generating a temporary key. The resource paths corresponding to the two permissions are also mixed. As a result, the temporary key has more extensive permissions specified in the resource paths, that is, users can list, download, upload, and delete anyone's files. In this way, malicious users can alter or delete others' files, leading to unauthorized access and legitimate data disclosure.

Security Regulations

Multiple actions and resources should not be simply combined separately and should be combined by using multiple statements to avoid more excessive permissions due to simple separated combinations.

In this case, the following statements should be used:

"statement": [
    {
        "effect": "allow",
        "action": [
            "name/cos:GetBucket", 
            "name/cos:GetObject"
        ], 
        "resource": "<BucketName-APPID>/app/files/*"
    },
    {
        "effect": "allow", 
        "action": [
            "name/cos:PutObject",
            "name/cos:DeleteObject"
        ],
        "resource": "<BucketName-APPID>/app/files/<Username>/*"
    }
]

Risk Case 4: Unauthorized Access to a Temporary Key

Application D provides a forum application, and posts and attachments in the forum are stored in COS. Users of the forum application are classified into different levels, and only active users with a certain number of posts can view posts and attachments in certain subforums. For some public subforums, all users can view the posts and attachments.
When COS is used, the API used to generate a temporary key at the backend generates a temporary key for downloading attachments in a subforum based on the subforum ID transmitted from the frontend. However, the backend does not determine whether a user who sends a request has permission to access the subforum specified by the subforum ID. As a result, anyone can request to obtain a temporary key for obtaining attachments in a private subforum over this API, resulting in unauthorized access, and resources that require limited access are not effectively limited, resulting in data leakage.

Security Regulations

In addition to ensuring that the permissions of the obtained temporary key are granted as expected, the API for obtaining a temporary key also needs to check whether the correct permissions are requested by correct users based on the actual business scenario. This prevents users with low permissions from obtaining temporary keys for high permissions.

In this case, the backend API should also check whether the requesting user has permission to access the specified subforum. If not, it should not return a temporary key.

Summary

The above cases illustrate the security risks that may occur if permissions of a temporary key are more excessive than expected. In scenarios where data can be directly uploaded to COS on the frontend, malicious users can obtain a temporary key more easily than in the scenario where COS is accessed on the backend. Therefore, developers should pay more attention to permission control.

The security regulation, that is, the minimum permission principle mentioned in this document, can enumerate all possible permissions based on the action and resource fields in actual applications. For example, in the case of three actions and two resources, six (2 x 3) accessible resources and the corresponding actions can be calculated. You can determine whether each scenario is within the expected permission scope. If not, enumerate multiple statements to split permissions.

In addition, the API used to generate a temporary key should also fully consider identity authentication and authorization processing. Only if the behavior of obtaining a temporary key is secure, the obtained temporary key is truly secure. No oversight is allowed in the security chain.