Invalid object-level authorization

1.1 an overview of the

Broken object-level authorization refers to the failure to enforce proper access control on an authenticated user. Attackers can exploit these flaws to access unauthorized functions or data (direct object references or restricted URLs). For example, access other users’ accounts, view sensitive files, modify other users’ data, change access rights, and so on.

1.2 Test cases

  • Change the ID of the object on the sent request

    /shops/{shopName}/revenue_data.json An attacker can retrieve sales data for different merchants by walking through {shopName} in the URL.
  • By monitoring the network traffic of the wearable device, there is a field: X-User-ID: 54796 in the custom request header of the HTTP Patch request. By replacing the value of the X-User-ID field with 54795, the attacker receives a successful HTTP response and can modify other users’ account data.

Invalid user authentication

2.1 an overview of the

Security problems in the process of user identity authentication, such as weak password, plaintext storage, weak encryption, password explosion, GET transmission of tokens and passwords, authentication bypass, etc.

2.2 Test cases

  • The validity of the token was not verified.
  • Update password interface unrestricted request frequency, old password parameters can be brute force crack.
  • SMS or email verification codes expire for more than 10 minutes or are less than 6 digits in length.

3 Excessive data exposure

3.1 an overview of the

When the API interface is called, it returns a lot of data, much of which may be unnecessary, and you should limit what the user sees to what is required.

3.2 Test cases

  • An interface queries the amount owed and whether it can return balance, bill, and other information.

4. Lack of resources and frequency limitations

4.1 an overview of the

The API interface imposes no limits on the size or number of resources that the client/user can request. Not only does this affect API server performance, leading to denial of service (DOS), but it also opens the door to authentication vulnerabilities such as brute force.

4.2 Test cases

  • When an application contains a list interface that displays 200 users per page, we can use/API /users? Page =1& Size =100 Query retrieves the list of users from the server. An attacker can tamper with the SIZE parameter to 2 million, causing performance problems in the database. At the same time, the API will be unable to respond to other requests from that client, or requests from other clients, resulting in DOS.
  • An attacker uploads large images by sending POST requests to/API /v1/images. After the upload is complete, the API will create several thumbnails of different sizes. Because the uploaded image is too large, the available memory is exhausted when creating thumbnails, and the API will not be able to respond.

Failed function-level authorization

5.1 an overview of the

Attackers exploit the vulnerability to send legitimate API calls to API endpoints they should not access. These endpoints may be exposed to anonymous users or regular non-privileged users. Because the API is more structured and more predictable about how to access the API, it is easier to find these flaws in the API (for example, replacing the HTTP method from GET to PUT, or changing the “user” string in the URL to “administrator”).

5.2 Test cases

  • During the application registration process for invitation-only applications, the mobile app will trigger an API call for GET/API/Invite_guid}. The response contains a JSON that contains details about the invitation, including the user’s role and the user’s E-mail. The attacker copies the request and changes the “role” value to Admin, sending a POST request to/API/log /new. Administrators can only access this endpoint using the administrative console, which does not implement functional-level authorization checking. An attacker exploits this problem and sends an invitation to himself to create an administrator account:

    POST/API/invites/new {" email ":" [email protected] ", "role" : "admin"}

6 Batch allocation

6.1 an overview of the

The back-end application object may contain a number of properties, some of which can be updated directly by the client (for example, User.FirstName or User.Address), while some properties should not be updated (for example, the User.IsVIP flag).

6.2 Test cases

  • A ride-sharing application gives users the option to edit basic information about their profiles. Users can update the two parameters “user_name” and “age”.

    PUT /api/v1/users/me
{"user_name":"inons","age":24}

The/API /v1/users/me interface returns an additional “credit_balance” parameter:

GET /api/v1/users/me
{"user_name":"inons","age":24,"credit_balance":10}

The attacker constructs the message and replays the first request:

PUT /api/v1/users/me
{"user_name":"attacker","age":60,"credit_balance":99999}

An attacker can tamper with his own credit without having to pay.

Security configuration error

7.1 an overview of the

Security configuration errors can occur at any level of an application stack, including platforms, Web servers, application servers, databases, frameworks, and custom code.

7.2 Test cases

  • Not configuring or misconfiguring CORS (Cross Domain Resource Sharing) policies;
  • An error message discloses call stack trace information or other sensitive information.
  • S3 bucket permissions are not properly controlled, including unauthorized access, download, and upload;
  • Determining that the API can only be accessed by certain HTTP methods and that access to other HTTP methods should be disabled (e.g., the HEAD method).

8 injection

8.1 an overview of the

The server does not validate, filter, or purify the data provided by the client. The data is directly used or concatenated into SQL/NoSQL/LDAP query statements, OS commands, XML interpreters, and ORM (Object Relational Mapper) /ODM (Object Document Mapper), resulting in injection class attacks.

8.2 Test cases

  • Determine if the server supports XML parsing and, if so, try XML injection.

    <? The XML version = "1.0" encoding = "utf-8"? > <! DOCTYPE Anything [ <!ENTITY entityex SYSTEM "file:///etc/passwd"> ]> <abc>&entityex; </abc>
  • The API does not validate, filter, or purify data from external systems (e.g., integrated systems).

9. Improper asset management

9.1 an overview of the

Asset management problems, such as exposed test interface address, old version interface not offline.

9.2 Test cases

  • Older or buggy versions of the API are not offline and continue to run without patches. For example: api.someservice.com/v2, replacing V2 in the URL with V1 enables the attacker to launch an attack using the old version of the API interface;
  • The test interface is open to the public network;
  • Using production data instead of the production API interface;