Stratégie de sécurité du développement de la plateforme publique WeChat

Bien que le serveur qui gère les requêtes WeChat se trouve en backend du serveur WeChat, les problèmes de sécurité ne peuvent toujours pas être sous-estimés.

Résumez globalement les aspects suivants, en espérant attirer l'attention.

1. Configurez un jeton très complexe et essayez de masquer l'URL de l'adresse du service

URL : l'adresse du lien pour le traitement des demandes WeChat
Jeton : identifiant d'identité de l'utilisateur

Lorsque vous postulez pour devenir développeur ou modifiez l'URLToken, WeChat accédera à l'URL via la requête Get et vérifiera la signature, qui nécessite le jeton.

Le processus équivaut à une poignée de main. Si la poignée de main réussit, une communication ultérieure peut être effectuée.

Dangers rencontrés :

1. Si l'URL et le jeton sont piratés, ils seront directement liés à d'autres. les comptes publics. Les services peuvent être volés directement. Bien entendu, pour certains comptes de type publicitaire, cela n'est pas rentable. Cependant, s'il s'agit d'un compte public qui fournit certaines applications ou services et fournit des services gratuits à d'autres comptes, cela augmentera inévitablement la pression sur le serveur et entraînera certains risques.

2. Si l'URL est crackée, même si le jeton n'est pas cracké. Certains criminels peuvent attaquer l’URL. Bien entendu, il n’est pas facile d’être ciblé par des pirates. Haha

Suggestions :

1. Essayez de vous assurer que l'URL du service n'a aucune relation directe avec la fourniture d'informations ou de pages Web. Pour éviter cela, l'URL du service est calculée en fonction de l'URL.

2. Vous pouvez utiliser la redirection d'URL pour masquer certaines informations de chemin.

3. Déterminez la source de la demande dans le service, s'il s'agit d'une demande du serveur WeChat. Cela peut être déterminé en fonction de l'URL demandée et les autres demandes ne seront pas traitées.

4. Valeur du jeton, essayez d'être aussi complexe que possible.

2. Il est recommandé d'effectuer une vérification de signature pour chaque demande

Après avoir défini l'URL ou le jeton, WeChat soumettra une demande d'obtention pour accéder à notre service backend. Une fois la vérification réussie, toutes les autres demandes WeChat sont soumises via POST.

Ainsi, dans le code, nous jugeons souvent s'il faut effectuer une vérification de signature en fonction de la méthode de requête. Dans les exemples précédents, cela a également été utilisé :

 /// 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 "无法处理";
        }

Bien que d'autres requêtes WeChat soient soumises en POST, leur URL également contient des informations de signature, et nous devons également effectuer une authentification par signature. Par conséquent, pour des raisons de sécurité, il est recommandé d’effectuer une authentification par signature à chaque demande.

Basé sur ce principe, nous modifions le code comme suit :

        /// <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 "无法处理";
        }

Algorithme de signature CheckSignature() , ici je n'entrerai plus dans les détails, pour plus de détails, voir : Construction du cadre de base pour le développement du compte public WeChat

3 Vous pouvez vérifier la demande en fonction de ToUserName

Habituellement notre. le compte public correspond à un openId, qui peut être obtenu lors du traitement des messages. Cet openId est fixe et les informations d'identité de l'expéditeur peuvent être déterminées sur cette base. De cette façon, les messages invalides ou les tromperies peuvent être très bien filtrés. Je ne traiterai que les messages qui m'ont été envoyés. Même si l'URL et le jeton sont piratés, le service back-end peut toujours être garanti et ne fournir des services que pour notre compte public.

/// 631fb227578dfffda61e1fa4d04b7d25
        /// 是否是发给我的呢
        /// 039f3e95db2a684c7b74365531eb6044
        /// ec639f3ec6e6df576b367639452f23c7接受者8bb7487ae6a16a43571bc14c7fcf93c2
        /// 2363942ed0d6cd3e85bae1dffa568116boolf7735d9f6a7af371769ab5c16d23b2f3
        private bool IsSentToMe(string toUserName)
        {
            return string.Equals(toUserName,Context.OpenID,StringComparison.OrdinalIgnoreCase);
        }

4. AppId et AppSecret

S'il s'agit d'un compte de service, il existe des fonctions avancées. , et Ces fonctionnalités avancées nécessitent des informations d'identification de développeur : AppId et AppSecret.

Vous pouvez obtenir ACCESS_TOKEN basé sur AppId et AppSecret, et vous pouvez gérer des fonctions avancées basées sur ACCESS_TOKEN, telles que des menus personnalisés.
ACESS_TOKEN a un délai d'expiration, généralement 7200S. Cependant, AppId et AppSecret sont générés aléatoirement par le système et n'ont pas de délai d'expiration. S'ils doivent être modifiés, vous devez vous connecter à la plateforme de gestion de compte public WeChat pour les réinitialiser.

Pour obtenir l'Access_Token, demandez l'URL suivante via Get

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

Après avoir obtenu l'Access_Token, vous pouvez utiliser certaines interfaces avancées

Par exemple :

Créez un menu personnalisé via la méthode de requête http : POST (veuillez utiliser le protocole https)

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

Spécifique Pour la mise en œuvre, voir : Menu personnalisé de développement de compte public WeChat

ACCESS_TOKEN est obtenu via la méthode get, qui n'est en fait pas très sûre. Si quelqu'un le vole, il peut modifier le lien de la coutume. menu et changez-le Remplacez-le par des liens publicitaires, ou des liens plus maléfiques, et votre serveur deviendra directement une machine à viande pour les autres. Il faut donc assurer la sécurité du serveur. Pour des raisons de sécurité, il est recommandé de réinitialiser AppId et AppSecret (la page de service en arrière-plan de la plateforme publique WeChat) de temps en temps. Le plus important est d'assurer la sécurité du serveur autorisé. Pour plus de détails, voir Five.

5. Assurer la sécurité du serveur

Il existe de nombreux facteurs pour la sécurité du serveur, tels que : assurer la sécurité du réseau, configurer des pare-feu, installer un logiciel antivirus, restreindre certains ports, etc. nos exigences habituelles en matière de sécurité du serveur. Il y a beaucoup d’informations, je n’entrerai donc pas dans les détails ici.

Pour plus de stratégies de sécurité de développement de plateforme publique WeChat et d'articles connexes, veuillez prêter attention au site Web PHP chinois !