Comment empêcher de restreindre l'accès à une application Web aux seuls appareils autorisés?
J'ai développé une application Web MVC. En ce moment, le client utilise cette application dans la zone de bureau. Le client a demandé à ce que personne n'utilise cette application sur aucun appareil, à l'exception des PC/tablettes du bureau.
Maintenant, le problème est que c'est une application Web, alors comment puis-je imposer des restrictions pour que personne ne puisse utiliser cette application de l'extérieur du bureau ou avec des appareils autres que les PC/tablettes du bureau?
Il y a plusieurs choses que vous pouvez faire pour aider à restreindre l'utilisation de l'application à un emplacement de bureau spécifique et à des appareils spécifiques, bien que, comme d'autres réponses le soulignent, aucune d'entre elles n'est une protection absolue
- Configurez un pare-feu devant l'application pour restreindre les adresses IP autorisées à accéder à l'application à la plage d'adresses IP externes des clients. La plupart des entreprises auront des adresses IP statiques sur leurs routeurs Internet et si vous définissez l'application uniquement pour qu'elle soit accessible par ces adresses IP, il serait plus difficile pour une personne non autorisée d'y accéder à moins qu'elle ne soit dans leur bureau. TBH cela ressemble à l'approche qui fonctionnera le mieux pour les besoins de vos clients
- Vous pouvez également utiliser des certificats clients sur des appareils autorisés. Comme le souligne @adnan, il peut être possible de les déplacer vers une autre machine, mais cela nécessiterait que l'attaquant soit membre du personnel de pour avoir un accès non autorisé à l'un de leurs systèmes
- peut-être en tant que contrôle de détective, vous pouvez combiner cela avec les empreintes digitales du navigateur (par exemple panopticlick ). Créez une liste d'appareils et leur empreinte digitale, puis si le certificat client est utilisé sur un appareil qui ne correspond pas à l'empreinte digitale, vous pouvez le bloquer.
Comme je l'ai dit, ce ne sont pas des absolus, mais rien dans la sécurité ne l'est. Si tout ce que votre client recherche est d'empêcher les gens de l'extérieur de l'entreprise de voir leur site, j'opterais pour l'approche du filtre d'adresse IP source.
Il vous suffit d'héberger l'application Web sur un serveur de l'intranet qui n'est pas connecté à Internet.
Un routage et une mesure de pare-feu appropriés doivent garantir que personne qui n'est pas connecté au réseau local n'a accès à l'application Web.
Si des personnes extérieures au réseau ont besoin d'accéder à l'application Web, demandez-leur de configurer une connexion VPN à votre réseau local.
Dans quelle mesure devez-vous aller?
C'est probablement aussi "sécurisé" que vous pouvez le faire. Ce n'est pas techniquement sûr. Comme l'a dit Rook , il y a encore des choses qui peuvent être exploitées. Voici quelques étapes à suivre pour essayer de durcir le système:
Configurez le serveur Web sur un serveur physique sur le réseau local du bureau. N'utilisez PAS NAT pour connecter tout trafic extérieur au serveur Web. Si le serveur est utilisé pour d'autres sites, ils doivent se trouver sur un serveur ou une machine virtuelle différent.
Configurez un SSL [[# #]] vpn [~ # ~] pare-feu (Cisco vient à l'esprit). Cisco propose des applications pour iPad qui peuvent être utilisées pour configurer un tunnel "sécurisé" avec le routeur.
Une fois que vous vous êtes authentifié via VPN (à distance), vous attribuez une adresse IP locale dans une certaine plage spécifiée (cela dépend du nombre de clients se connectant au serveur). Selon le routeur, vous pouvez attribuer des règles. Parce que vous ne pouvez pas contrôler le réseau à l'autre extrémité du VPN (disons le réseau domestique de l'utilisateur), il s'agit d'un vecteur d'attaque potentiel.
Le trafic local et le trafic VPN devraient avoir différentes plages IP pour le suivi. Le trafic local doit avoir des adresses IP statiques attribuées par l'adresse MAC (usurpée) par le serveur DHCP qui sont tous enregistrés. Cela vous aidera à vérifier les collisions, les adresses IP et les adresses MAC usurpées.
Sur le pare-feu du serveur Web, vous devez configurer un sous-réseau d'adresses pouvant se connecter au serveur Web. Cela inclurait la plage VPN attribuée dans le routeur pour les utilisateurs et les adresses IP statiques internes sur liste blanche.
Ensuite, sur le serveur Web lui-même, vous pouvez restreindre l'accès au site Web via les adresses IP sur liste blanche ( IIS 7 et Apache ) que vous avez configurées sur le serveur DHCP et dans le local pare-feu (c'est redondant dans le cas où quelqu'un trouve un exploit pour altérer iptables dans une boîte * Nix).
Si vous utilisez un pare-feu logiciel d'entreprise après-vente comme Kaspersky (sur une boîte Windows ou Linux), vous pouvez également bloquer le trafic de cette façon.
Pour apporter des modifications à ce système: 1. les listes d'adresses IP devraient être mises à jour sur le serveur DHCP interne 2. dans le pare-feu du serveur Web 3. et dans la configuration du serveur Web
Alors que "verrouille" l'accès au serveur Web réel ...
Ensuite, vous devrez exécuter SSL sur le serveur Web et exiger un nom d'utilisateur et un mot de passe spécifiques pour l'utilisateur. Le mot de passe doit contenir au moins 16 caractères.
Une fois que l'utilisateur s'authentifie sur le serveur Web, vous lui envoyez un message, soit via SMS ou par e-mail contenant une seule utilisation ou une seule fois. mot de passe qui permet à l'utilisateur d'être mis sur liste blanche pendant un certain temps sur le serveur. (Si quelqu'un a accès au téléphone portable de l'utilisateur, cela peut être compromis). Si l'utilisateur ferme la fenêtre du navigateur, il doit être authentifié à nouveau (et cela devrait mettre fin à la session). Vous pouvez définir un script keep-alive qui s'exécute dans un langage comme Javascript qui attend une transmission du client dans un certain laps de temps. Si le client ne répond pas, arrêtez la session. (Cela empêche la désactivation de javascript pour l'accès. Cela aide également les personnes à fermer leur navigateur et à essayer d'ouvrir de nouvelles sessions avant l'expiration de leur ancienne session.) Ils ne devraient pouvoir se connecter qu'à partir d'un seul emplacement à la fois.
Vous devez empêcher l'utilisateur de stocker ses mots de passe sur ses appareils. (Cela peut être contourné avec des plugins dans des navigateurs comme Firefox.)
Pour rendre les choses plus strictes, vous pourriez même aller jusqu'à exiger que les tablettes se connectent à un terminal virtuel via quelque chose comme VNC ou RDP (pas idéal sur un téléphone). Ensuite, ils devraient utiliser le client Web sur la machine virtuelle. Ce VM serait restauré pour être nettoyé lors de la prochaine exécution ou connexion.
Quiconque connaît le système peut l'exploiter. N'importe qui en dehors du système devrait passer beaucoup de temps à essayer d'entrer et il devrait savoir que le système existe.
Tous les aspects devraient être documentés. Si quelqu'un avait la documentation, il pourrait essayer de trouver une faiblesse dans le système.
Encore une fois, cela revient aux gens. Toute personne ayant accès aux informations au fil du temps peut stocker des copies de toutes les informations (captures d'écran avec un téléphone portable, PDF textuels de documents de bureau, etc.) SSL est également craquable, de sorte que même les connexions "sécurisées" cryptées peuvent être lues par la droite gens.
Ce que vous essayez d'atteindre n'est pas possible. HTTP n'est pas conçu pour fournir des identifiants spécifiques au matériel, le seul "identifiant" est l'agent utilisateur qui ne s'identifie pas du tout, et il peut être usurpé, donc les navigateurs ne accéder à cette information.
Même avec un certificat client, il peut simplement être exporté du navigateur vers un autre appareil.
Dites à votre client que ce n'est pas techniquement possible.
À qui appartient le code? Quelle est la probabilité que quelqu'un d'autre veuille utiliser l'application? Quelle serait la gravité des conséquences si quelqu'un d'autre utilisait l'application? Quels types d'appareils? L'accès doit-il être limité aux adresses IP statiques? Ce ne sont que quelques-unes des questions auxquelles vous auriez dû répondre dans votre message avant de demander des recommandations de conception.
Les adresses IP des VPN et les certificats clients ont déjà été mentionnés, mais les certificats clients peuvent être difficiles à installer sur certains appareils. Les adresses IP statiques ne fonctionneront que dans un réseau local bien géré. Un VPN nécessiterait une intégration étroite entre le serveur, le réseau et la configuration de l'application.
Le stockage d'un simple jeton dans un cookie persistant (sans autorisations et processus appropriés autour de l'enregistrement de l'appareil) est une solution simple, mais peu résistante à la rétro-ingénierie/usurpation d'identité.
Solution numéro un Si vous utilisez IIS, il a intégré un service où vous pouvez restreindre l'accès à votre application en fonction de l'adresse IP.
Solution numéro deux: Essayez d'implémenter le verrouillage du terminal qui nécessite une programmation;
Vous pouvez implémenter la solution de verrouillage de terminal qui est des identifiants spécifiques au matériel. Veuillez suivre les étapes ci-dessous.
Remarque: vous devez définir une adresse IP statique pour chaque périphérique.
- R: Utilisez les contrôles Active-x pour capturer les informations MACAddress côté client, je les ai implémentées uniquement pour Internet Explorer. Pour ajouter plus de sécurité, vous pouvez capturer MACAddress, IPAddress et le nom de l'ordinateur. veuillez noter que Active-x non signé et x actif signé doivent être activés dans le navigateur.
- B: Au niveau de l'application, la même chose doit être implémentée pour lire les informations de l'étape A et stocker/vérifier les informations transmises dans la base de données.
C: Au niveau de la base de données, veuillez suivre les étapes ci-dessous;
Étape 1: Lorsque l'application est accédée pour la première fois, le système doit capturer l'adresse IP et la stocker dans une table, par ex. veuillez créer une table avec le nom dbo.Terminals et, à travers votre application, essayez de lire et de stocker l'adresse IP et de générer automatiquement un ID unique pour chaque IP. Ce tableau doit contenir certains champs avec le nom MACADDRESS et des champs supplémentaires pour les utilisateurs mappant avec ce CODE UNIQUE, par exemple user1, user2, user3 et ainsi de suite.
Étape 2: Maintenant, modifiez votre table dbo.user et ajoutez un champ avec le nom Static Terminal-applicable qui fonctionnera comme commutateur (On/OFF)
- Étape 3: Connexion de l'utilisateur: Écrivez quelques codes pour vérifier si l'étape B est activée. Si oui, vérifiez si le terminal est attribué à l'étape A. vérifiez maintenant si ce terminal a une liste d'utilisateurs enregistrés (voir l'étape A utilisateur1, utilisateur2, etc.). vérifiez enfin que macaddress est capturé et disponible dans dbo.terminals, s'il n'est pas capturé, récupérez-le et stockez-le dans la base de données. La solution ci-dessus est testée dans de nombreuses banques, qui est un accès par appareil au domaine bancaire et aux systèmes de services financiers.