java - 如何确保服务端的接口调用安全？

Question

服务端提供各种功能接口供客户端调用，那么怎样才能确保请求是来自合法的客户端，而不是非法的请求呢？

Answer 1

Vérifiez le jeton ou utilisez le framework OAuth2 côté serveur

Answer 2

Comment définissez-vous le légal et l'illégal ? Dans le cadre du SSO, si vous avez un token, vous irez de côté. S'il s'agit d'un tiers, vous aurez certainement besoin de l'appid et du appsecret. Si vous avez besoin d'une autorisation, vous devrez également apporter le AccessToken. de côté. Le moyen le plus simple est d'écrire un intercepteur IP pour permettre uniquement le passage des adresses IP de confiance, mais il est utilisé pour l'interception de haut niveau des appels mutuels internes. De manière générale, si l'autre partie fournit un jeton ou un secret d'application, c'est essentiellement le cas. légal, non ?

Answer 3

Lors de la conception d'une API, pour garantir la sécurité d'une API RESTful, trois aspects majeurs doivent être pris en compte :

1. Autorisation de connexion pour les ressources restreintes
2. Authentification d'identité pour les demandes
3. Crypter les données sensibles

1. Autorisation de connexion pour les ressources restreintes
Ce processus n'est pas l'objet de cet article et ne sera pas décrit en détail. Le processus de base est le suivant :

1. Le client soumet les informations de compte (nom d'utilisateur + mot de passe) au serveur

2. Le serveur vérifie avec succès et renvoie l'AccessToken au client pour le stockage
   3 Lors de l'accès à des ressources restreintes, le client peut y accéder en apportant l'AccessToken.

2. Demander l'authentification
Si la demande n'est pas signée et authentifiée, vous pouvez facilement capturer les données via des outils tels que fiddler, les falsifier, les soumettre et effectuer des appels par lots à grande échelle, ce qui entraînera la système pour générer beaucoup de déchets. Une grande quantité de données et de ressources système sont consommées et ne peuvent même pas être utilisées normalement (de plus, bien sûr, le courant peut être limité via GateWay), nous devons donc effectuer une authentification par signature sur le demande.

Format de l'URL
URL:schema://domain/path?query&imei×tamp&sign

Description du paramètre
Méthode de signature
sign=signature(path?query&imei×tamp&SIGN_KEY)

Processus de vérification
Logique d'authentification
1 Initialement, le serveur dispose du SIGN_KEY de chaque version de l'application, et le client dispose de la version correspondante de SIGN_KEY
2. Cryptez et obtenez un signe
3. Lors de l'envoi d'une requête, envoyez-la au serveur avec le signe
4. Le serveur vérifie d'abord si l'horodatage est valide. Par exemple, les requêtes avec un horodatage du serveur il y a 5 minutes. sont considérés comme invalides. ;
5. Prenez ensuite la version correspondante de SIGN_KEY pour vérifier si le signe est légal
6 Afin d'éviter les attaques par rejeu, vous devez vérifier si le signe est stocké dans redis. n'existe pas, stockez-le dans Redis (cache pendant 5 minutes)

Comment empêcher la falsification des données
Ici, le paramètre de signature contient tous les paramètres de la demande d'origine. Si un paramètre est modifié, la valeur du signe sera différente, elle ne pourra donc pas être falsifiée.

Comment empêcher les attaques par rejeu
Étant donné que l'algorithme de signature a également des paramètres imei (ID d'appareil unique) et d'horodatage, et que l'algorithme de signature est un algorithme irréversible (tel que md5 ou sha1), la valeur de signe pour chaque requête normale n'est pas va répéter. À ce stade, le serveur peut stocker la valeur du signe de 5 minutes pour vérification et filtrage lors des attaques par relecture. Les requêtes qui dépassent 5 minutes sont directement filtrées par vérification d'horodatage.

Résumé
De cette manière, l'authentification de la demande est obtenue pour empêcher la falsification des données et les attaques par relecture, mais elle est nécessaire pour garantir le stockage sécurisé de la clé de l'application (SIGN_KEY). L'avantage est qu'elle est facile à comprendre et à comprendre. mettre en œuvre, mais l’inconvénient est qu’il nécessite la responsabilité de stocker en toute sécurité les clés de mot de passe et la charge de mettre à jour régulièrement les clés.

3. Cryptage des données sensibles
1) Déployer l'infrastructure SSL (c'est-à-dire HTTPS).
2) Chiffrez uniquement certaines données sensibles (telles que le numéro de compte + le mot de passe) et ajoutez un nombre aléatoire comme sel de cryptage pour empêcher la falsification des données.

Answer 4

Nous utilisons l'algorithme de cryptage RSA. Les paramètres des données de la requête sont convertis en json puis le certificat RSA du serveur est utilisé pour crypter le json. La requête http suffit et la clé privée du serveur est déchiffrée

.

Answer 5

Utilisez oauth2 ou un jeton similaire