I’m participating in nuggets Creators Camp # 4, click here to learn more and learn together!

preface

Since 2017, wechat mini program was released. Because of its use – and – go, lightweight, low barrier to development characteristics, over the years, it feels like any company has started small programs. Even the convenience store downstairs has a quick shopping mini program.

The security of small programs has always been teased by developers. In the developer community, data security issues arise with respect to decompilation of applets.

As a developer, whether front-end or back-end, it is essential to understand common security issues and common solutions.

Common security Questions and solutions

Small program part

1. The compilation

Many original micro channel small programs, by technical personnel through decompilation technology or tools, the complete code decompilation. This technology has been around since the inception of applets. Most developer decompilation projects are for learning purposes, but many companies use existing small programs in the decompilation market to quickly build their own products and make money.

For such problems, wechat officials did not make too many countermeasures. After all, small program simulation is the browser, the general front-end project, right click in the browser side can view the source code, in the console can view network requests and other more detailed information.

In small program code, do not write sensitive data, sensitive data all on the server side. When the client wants to use it, it requests it through the interface. The decompiled code is front-end style, which is not important. After all, it’s only a matter of time before the average front-end programmer copies a small program project.

2. Interface authentication

It is easy for developers to get applets’ network requests through packet capture and third-party tools. When the background interface is called, the developers of small programs should verify the permission of the call, including the self-built background interface and cloud function, otherwise it is easy to overreach the authority and data leakage.

Sensitive data and development-related interfaces need to be authenticated in the background, such as OpenID, IP address, and custom login status.

The authentication logic should be carried out in the background and should not be replaced by hidden pages and buttons in small programs.

Common authentication examples are as follows:

// Self-built platform 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") {
            // Delete the file
            // ...
            return 0;
        } else {
            // Log illegal requests
            // ...
            return -1; }}Copy the code
// exports.main = async (event, context) => {const {OPENID, APPID, UNIONID} = cloud.getwxContext (); If (OPENID === "XXX ") { } else {// Record illegal requests //... }}Copy the code

3. Code management

When a version management tool such as git or SVN is used, a.git directory is generated. Some editors or software also generate temporary files as they run. If these directories or files are taken into production, source code leakage can occur.

4. Content security

For functions that contain user input, such as comments, changing nicknames, and profile pictures, etc. Developers need to invoke their own information filtering interface to determine if the content is illegal. Applets that are not configured will be warned and search will be limited. A small program I developed in the community category was banned for a long time for this reason.

5. Security of sensitive data

For sensitive data stored locally, such as user information, OpenID and other data, developers should encrypt and store sensitive data by themselves.

The background part

1. Injection attack

Injection attack means that users bypass the restriction of background code and directly execute custom code in the database or shell. It is usually divided into SQL injection and command injection.

Different back-end languages or frameworks have their own solutions to these risks. For example, use the parameterized query provided by the database to perform database operations. It is not allowed to compose SQL statements by concatenating strings.

2. Weak passwords

Weak password Indicates that the user name and password of the management background are set simply or the default account is used. Attackers can log in to these accounts to modify background data or perform further intrusion operations. If the background management system is exposed to the public network. It is highly likely to be attacked, and a secondary authentication mechanism should be added for sensitive services, such as SMS verification codes.

3. Upload and download files

If the validity of the file type and format is not verified during file upload, files in an unexpected format may be uploaded. Such files may pose a risk to the server. Therefore, the types of uploaded files must be correctly resolved and the file types that can be uploaded must be whitelisted.

During file download, the range of the directory where downloadable files reside is restricted. As a result, files outside the expected range are downloaded and leaked. This type of problem requires that the range of directories in which files can be downloaded and the download permission be restricted.

Official development principles and matters needing attention

  1. Do not trust data submitted by users, including data provided by third-party systems. Necessary data verification must be performed in the background.
  2. Minimum permission principle: Code and module only have the minimum permission that can complete tasks, and do not grant unnecessary permission.
  3. Do not save sensitive user data in plaintext.
  4. Small program code (excluding cloud function code) is similar to the front-end code of traditional Web applications. It can be obtained externally and de-confused. Important business logic should be carried out in background code or cloud function.
  5. Background interface calls and cloud function calls must be authenticated.

conclusion

Before the development of small programs, it is necessary to understand the corresponding problems to prevent possible problems. After the development is completed, the possible problem areas should also be checked to prevent the loss of unused.

If this article is helpful to you, feel free to like it and follow the comments! Thank you very much!