# Common Risks and Development Recommendations

This article takes stock of some of the security risks that are often encountered in the process of Mini Program development, and I hope that developers will check themselves according to the risk tips to avoid losses!

# I. Interface Authentication

Interface authentication refers to the background interface (including self-built background interface and cloud function) need to check the permission of the interface call when it is called, otherwise it is prone to ultra vires behavior. Such as product deletion interface, the background should verify the identity of the caller when receiving the request (such as openid、 ip Address, developer-defined login status information, etc.), only the specified user can be deleted through validation.

Ultra vires are usually divided into parallel and vertical vires:

  • Parallel ultra vires

    Parallel overreach refers to overreach between the same roles. A1、 A2 Are regular users, A1 Request the backend interface userinfo.php?id=A1 To get users. A1 Own information. If userinfo.php Permission validation is not performed. The user A1 The request should read userinfo.php?id=A2 You can get access to A2 User's information, causing A2 Disclosure of user information.

  • Vertical ultra vires

    Vertical overreach refers to overreach between different roles. B1 Is the caretaker, B2 Is a regular user. The administrator B1 Request the backend interface getalluserinfo.php Can get information about all registered users if getalluserinfo.php Without permission checks, B2 Users can also request getalluserinfo.php To gain access to all registered users.

Development Proposals:

  1. Sensitive data and capability related interfaces need to be authenticated in the background. Usually verified. openid、 IP Address, custom login status and other information.

  2. The authentication logic should be placed in the background, and should not be replaced by hidden pages and hidden buttons in the front end of the Mini Program. Reference Principle 4.

  3. Authentication code example (for reference only)

    • Self-built backend authentication

      function actionDelete(){
          $item_id = $_POST["item_id"] 
          $openid  = $_POST["openid"]
          $ip = $_SERVER['REMOTE_ADDR']
          $user_Role = $_SESSION["user_role"]
          if ($openid  === "xxx" &&
              $ip === "192.168.0.101" &&
              $user_Role === "admin") {
                  // Perform a delete operation
                  // ...
                  return 0
              } else {
                  // Record illegal requests
                  // ...
                  return -1
              }
      }
      
    • Cloud function interface authentication

      exports.main = async (event, context) => {
          const { OPENID, APPID, UNIONID } = cloud.getWXContext()
          if (OPENID === "xxx") {
              // Perform a delete operation
              // ...
          } else {
              // Record illegal requests
              // ...
          }
      }
      

# II. Code Management and Leakage

  1. When using go、 svn And other version management tools, will produce .git And so on. Some editors or software also generate temporary files during run time. If these directories or files are taken to production, a source leak may occur.

  2. useMini Program code management platformor github When waiting for a third-party platform, you need to pay attention to project permissions, and do not disclose sensitive, internal projects.

Development Proposals:

  1. Do not synchronize files generated by backup files and version management tools to Web Under the directory.
  2. External access prohibited .git Such as directories and documents.
  3. inMini Program code management platformSuch as management platform to configure the appropriate access right.

# III. Business Information Disclosure

Sensitive information is data that, if divulged, could be detrimental to the developer's business, partners and users, including but not limited toaccount Appsecret, privileged account information, background encryption key, login account password, user body ID, mobile phone number, Silverbank card number, etc.

Development Proposals:

  1. Sensitive information should not be encoded in plain text, annotated, or reversibly Base64), insecure hash functions such as MD5、 SHA1) and other forms appear in the Mini Program file.

  2. Part of the sensitive information such as the user's bank card number, mobile phone number, etc. need to be desensitized. Commonly used desensitization specifications are as follows:

    Sensitive information type Sample display
    Full name The name has only two words, type the first word, such as:Three. More than two words, only keep the first and last, the rest are typed, such as: KingIV. O**five
    ID Show only the first and last bits, such as: 3****************1
    Phone number After removing the international code, when the number of mobile phone numbers is not less than 10, only the first three digits and the last two digits are displayed, such as: 156*77。 When the number of mobile phone numbers is less than 10, only the first and last two digits are displayed, such as: 1289。 Country codes can be fully displayed.
    Bank card Show only the last 4 bits, such as:************1234
  3. If sensitive information is leaked, WeChat Open Platform may remove the app and suspend its related services.

# IV. Change of Authorized User Information

Developers through WeChat Mini Programs APIs obtain user data with the express consent of the user. When encountering cases where user data is expired, users voluntarily revoke, users log out of accounts, etc., the developer needs to clean up the user data previously obtained in a timely manner, fulfill the corresponding personal information protection obligations in accordance with the regulations, and protect the rights and interests of users.

Development Proposals: Developers need to set upMessage Push Server Configuration, Timely receive the notification of authorization information on WeChat platform and deal with it, please checkThis document

# V. Injecting Vulnerabilities

Injection vulnerabilities (SQL, Commands, etc.) usually refers to the user bypassing the background code restrictions and working directly in the database, shell Execute custom code inside.

Common injection vulnerabilities are:

# SQL injection

SQL Injection means Web Program code for the user-submitted parameters do not do effective filtering directly spliced to the SQL Statement, causing the special characters in the arguments to break SQL Statement original logic, hackers can use this vulnerability to execute arbitrary SQL Statement.

Development Proposals:

  1. Use parametric queries provided by the database to carry out database operations, do not allow directly through the stitching of character strings to the composition SQL Statement.
  2. If there are some situations that need to be synthesized by splicing SQL Variables must be processed:
    • For integers, you need to determine whether the variable is an integer type.
    • For character strings, you want to escape single quotes, double quotes, and so on.
  3. avoid Web Application display SQL The error message.
  4. ensure Web Uniform coding of each data layer in the application.

# Command injection

A command injection vulnerability is Web The application does not filter the user-controllable parameters effectively, and the attacker can construct malicious parameters to execute arbitrary commands.

Development Proposals:

  • To the data entered by the user (such as 、|, &, etc.) for filtering or escaping.

# VI. Weak Passwords

Weak password means that the user name and password of the administrative background is set relatively simple or use the default account. Attackers can log in to these accounts to modify the background data or the next step of the intrusion operations.

Development Proposals:

  1. Background services disable the default account, change the background weak password.
  2. Sensitive services to increase the secondary verification mechanism, such as SMS verification code, email verification code.

# VII. File Upload Vulnerability

A file upload vulnerability means Web The application allows the user to upload the specified file, but does not verify the validity of the file type and format, so that the file can be uploaded in an unexpected format.

Development Proposals:

  • Correctly parse the file type of the uploaded file, and limit the file type that can be uploaded by whitelist.

# VIII. Document Downloads

File download vulnerability refers to Web The application allows the user to download the corresponding file by specifying the path and file name, but does not properly limit the directory where the downloadable file is located, resulting in the download of files outside the expected range.

Development Proposals:

  1. Correctly limit the scope of the directory where the downloadable file is located
  2. By designatefile id The way to find the download of the corresponding file

# IX. Directory Traversal

Directory traversal refers to the server directory content leakage caused by insufficient validation of user input by back-end services or improper configuration. External directory traversal may get system files, background code and other sensitive files.

Development Proposals:

  1. web Service Configuration

    • The server prohibits the display of directories
    • Set directory access right
    • Under each directory place an empty index.html page
  2. web Application code

    • Strictly check the file path parameters and limit the scope of the file

# X. Conditional Competition

A common example of conditional competition is when an attacker uses concurrent https Request to achieve multiple awards, multiple harvests, multiple gifts and other abnormal logic can trigger the effect.

  • Vulnerability Code Examples

    // Query the remaining number of awards from the DB, and the initial value is 1
    int Remain_times = SelectRemainTimes()
    
    if(Remain_times > 0){
        EarnRewards()          // Users are rewarded
        ClearRemainTimes()     // In the DB to clear the user's remaining number of awards
    }
    

    The developer's design is intended to allow the user to receive a reward only once, but when there are concurrent requests, it is possible that a request may occur A And requests B The second line of code is executed, at which point the two requests Remain_times Are 1, that is, you can judge by the fourth line of code, get two rewards.

Development Proposals:

  • A lock operation on critical (complete) logic or processing of critical logic in the form of queued tasks.