Security policies for WeChat public platform development

This article mainly introduces the security policies for public platform development.

Although the server that processes the request is at the backend of the server, the security issue cannot be underestimated.

I would like to summarize the following aspects to draw attention.

1. set a high-complexity Token and try to hide the service URL

URL: The URL of the request.
Token: User Identity Credential

When you apply to become a developer or modify the URL \ Token, you will access the URL through the Get request to verify the signature, where the Token is required.

The process is equivalent to a handshake. if the handshake succeeds, subsequent communication can be performed.

Risks:

1. if the URL and Token are cracked, they are directly linked to other public accounts and can directly steal services. Of course, for some ad-type accounts, this is not a problem. However, if it is a public account that provides an application or service and provides services to other accounts for free, it is bound to 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 be targeted by hackers. Haha

Suggestion:

1. try to ensure that the service URL is not directly related to the provision of messages or webpages. To prevent this, calculate the service URL based on the URL.

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

3. determine the Request source in the service and whether the request is from the server. This can be determined based on the request URL and will not be processed for other requests.

4. the Token value should be as complex as possible.

2. we recommend that you verify the signature for each request.

After URL or token is set, get requests are submitted to access our backend services. After the verification is passed, other requests are submitted in POST mode.

Therefore, in the code, we often determine whether to perform signature verification based on the request method. In the previous example, it was also used as follows:

////// Process the request and generate a response //////
 Public string Response () {string method = Request. httpMethod. toUpper (); // verify the signature if (method = "GET") {if (CheckSignature () {return Request. queryString [ECHOSTR];} else {return "error" ;}}// process the message if (method = "POST") {return ResponseMsg ();} return "unable to process ";}

Although other requests are submitted using POST, the URL also carries the signature information. we also need to perform signature authentication. Therefore, we recommend that you sign each request for security.

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

////// Process the request and generate a response //////
 Public string Response () {string method = Request. httpMethod. toUpper (); // verify the signature if (method = "GET") {if (CheckSignature () {return Request. queryString [ECHOSTR];} else {return "error" ;}}// process the message if (method = "POST") {// verify the signature if (CheckSignature ()) {return ResponseMsg () ;}} return "unable to process ";}

The signature algorithm CheckSignature () is not described here. For details, see: basic framework for public account development.

3. requests can be verified based on ToUserName

Generally, our public account corresponds to an openId, which can be obtained during message processing. This openId is fixed and can be used to determine the identity of the sender. This method can filter out invalid messages or cheat messages. only messages sent to me can be processed by me. Even if the URL and Token are cracked, the backend service can be guaranteed to only provide services for our public accounts.

////// Is it sent to me //////Recipient///
 
  
Bool
 Private bool IsSentToMe (string toUserName) {return string. Equals (toUserName, Context. OpenID, StringComparison. OrdinalIgnoreCase );}

IV. AppId and AppSecret

If it is a service number, there are some advanced features that require developer creden。: AppId and AppSecret.

You can obtain ACCESS_TOKEN based on AppId and AppSecret, and manage advanced functions based on ACCESS_TOKEN, such as custom menus.
ACESS_TOKEN has an expiration time, which is usually 7200 S. However, AppId and AppSecret are randomly generated by the system and have no expiration time. if you need to modify them, log on to the public account management platform and reset them.

Obtain the Access_Token using the following URL in the Get request:

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

After obtaining Access_Token, you can operate some advanced interfaces.

For example:

Create a custom menu by using the http request method: POST (please use https protocol)

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

For more information, see the custom menu for public account development.

ACCESS_TOKEN is obtained through the get method. In fact, it is not safe. if it is stolen, it can modify the link of the custom menu, change it to some ad links, or more evil links, your server directly becomes a meat machine. Therefore, you must ensure the security of the server. To ensure security, we recommend that you reset the AppId and AppSecret at intervals (the background service page of the public platform ). The important thing is to ensure the security of the server. for details, see figure 5.

5. ensure server security

There are many factors for server security, such as network security, firewall setting, anti-virus software installation, and Port restriction. this is the same as our usual server security requirements. we will not repeat this information here.

For more articles about security policy development on the public platform, refer to PHP Chinese website!