Although the server that handles WeChat requests is at the back end of the WeChat server, security issues still cannot be underestimated.

Broadly summarize the following aspects, hoping to attract attention.

1. Set up a highly complex Token and try to hide the service address URL

URL: This is the link address for processing WeChat requests
Token: User identity certificate

When applying to become a developer or modifying the URL\Token, WeChat will access the URL through Get request and verify the signature, which requires the Token.

The process is equivalent to a handshake. If the handshake is successful, subsequent communication can be carried out.

Dangers faced:

1. If the URL and Token are cracked, they will be directly linked to other public accounts. Services can be stolen directly. Of course, for some advertising-type accounts, this is unprofitable. However, if it is a public account that provides certain applications or services and provides services to other accounts for free, it will inevitably increase the pressure on the server and bring certain risks.

2. If the URL is cracked, even if the token is not cracked. Some criminals may attack the URL. Of course, it is not that easy to get targeted by hackers. Haha

Suggestions:

1. Try to ensure that the URL of the service has no direct relationship with providing information or web pages. To prevent this, the service URL is calculated based on the URL.

2. You can use URL redirection to hide some path information.

3. Determine the source of the request in the service, whether it is a request from the WeChat server. This can be determined based on the requested URL, and other requests will not be processed.

4. Token value, try to be as complex as possible.

2. It is recommended that each request be subject to signature verification

After setting the URL or token, WeChat will submit a get request to access our back-end service. After the verification is passed, all other WeChat requests are submitted through POST.

So in the code, we often judge whether to perform signature verification based on the request method. In previous examples, this was also used:

 /// <summary>
        /// 处理请求，产生响应
        /// </summary>
        /// <returns></returns>
        public string Response()
        {
            string method = Request.HttpMethod.ToUpper();
            //验证签名
            if (method == "GET")
            {
                if (CheckSignature())
                {
                    return Request.QueryString[ECHOSTR];
                }
                else
                {
                    return "error";
                }
            }

            //处理消息
            if (method == "POST")
            {
                return ResponseMsg();
            }

            return "无法处理";
        }

Although other WeChat requests are submitted as POST, the URL in It also carries signature information, and we also need to perform signature authentication. Therefore, for security reasons, it is recommended to perform signature authentication on every request.

Based on this principle, we modify the code as follows:

        /// <summary>
        /// 处理请求，产生响应        /// </summary>
        /// <returns></returns>
        public string Response()
        {            string method = Request.HttpMethod.ToUpper();            //验证签名
            if (method == "GET")
            {                if (CheckSignature())
                {                    return Request.QueryString[ECHOSTR];
                }                else
                {                    return "error";
                }
            }            //处理消息
            if (method == "POST")
            {                //验证签名
                if (CheckSignature())
                {                    return ResponseMsg();
                }
            }            return "无法处理";
        }

Signature algorithm CheckSignature(), no more here To go into details, please see: WeChat public account development basic framework construction

3. You can verify the request based on ToUserName

Usually our public account corresponds to an openId, which can be obtained when processing messages. This openId is fixed, and the identity information of the sender can be determined based on it. In this way, invalid messages or deceptions can be filtered very well. I will only process the messages sent to me. Even if the URL and Token are cracked, the backend service can still be guaranteed and only provide services for our public account.

/// <summary>
        /// 是否是发给我的呢
        /// </summary>
        /// <param name="toUserName">接受者</param>
        /// <returns>bool</returns>
        private bool IsSentToMe(string toUserName)
        {
            return string.Equals(toUserName,Context.OpenID,StringComparison.OrdinalIgnoreCase);
        }

4. AppId and AppSecret

If it is a service account, there are some advanced functions, and these advanced Features require developer credentials: AppId and AppSecret.

You can get ACCESS_TOKEN based on AppId and AppSecret, and you can manage advanced functions based on ACCESS_TOKEN, such as custom menus.

To obtain the Access_Token, request the following URL through Get

https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&appid=xxxx&secret=xxxx.

After obtaining the Access_Token, you can operate some advanced interfaces

For example:

Create a custom menu through http request method: POST (please use https protocol)

https://api.weixin.qq.com/cgi-bin/menu/create?access_token=ACCESS_TOKEN

For specific implementation, see: WeChat public account development custom menu

5. Ensure the security of the server

There are many factors for server security, such as: ensuring network security, setting up firewalls, installing anti-virus software, restricting some ports, etc. This is the same as our usual server security requirements. In this regard There is a lot of information, so I won’t go into details here.

For more WeChat public platform development security strategies and related articles, please pay attention to the PHP Chinese website!