Home > Article > WeChat Applet > WeChat public platform development security strategy
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:
/// 631fb227578dfffda61e1fa4d04b7d25 /// 处理请求,产生响应 /// 039f3e95db2a684c7b74365531eb6044 /// 2363942ed0d6cd3e85bae1dffa568116f7735d9f6a7af371769ab5c16d23b2f3 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
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.
/// 631fb227578dfffda61e1fa4d04b7d25 /// 是否是发给我的呢 /// 039f3e95db2a684c7b74365531eb6044 /// ec639f3ec6e6df576b367639452f23c7接受者8bb7487ae6a16a43571bc14c7fcf93c2 /// 2363942ed0d6cd3e85bae1dffa568116boolf7735d9f6a7af371769ab5c16d23b2f3 private bool IsSentToMe(string toUserName) { return string.Equals(toUserName,Context.OpenID,StringComparison.OrdinalIgnoreCase); }
4. 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.
ACESS_TOKEN has an expiration time, usually 7200S. However, AppId and AppSecret are randomly generated by the system and have no expiration time. If they need to be modified, you need to log in to the WeChat public account management platform to reset them.
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
ACCESS_TOKEN is obtained through the get method, which is actually not very safe. If it is stolen, it can modify the link of the custom menu and change it to some advertisements Link, or a more evil link, your server directly becomes someone else's meat machine. So we must ensure the security of the server. For security reasons, it is recommended to reset the AppId and AppSecret (the background service page of the WeChat public platform) every once in a while. The most important thing is to ensure the security of the allowed server. For details, see Five.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!