Les applications Web qui ne sont accessibles qu'à partir d'un LAN doivent-elles respecter les mêmes normes de sécurité que les sites Web accessibles au public?
De nombreuses mesures de sécurité visent à protéger les utilisateurs hostiles qui souhaitent abuser du logiciel ou accéder à du contenu auquel ils n'ont pas l'autorisation d'accéder. Des choses comme la protection CSRF, la protection SQLi, TLS et de nombreuses autres fonctionnalités de sécurité protègent principalement contre les utilisateurs malveillants. Mais que faire si tous les utilisateurs peuvent faire confiance?
Supposons que vous disposiez d'une application Web entièrement interne qui ne fonctionnera que sur l'intranet de l'entreprise et ne sera jamais accessible de l'extérieur. supposons que tous les utilisateurs internes peuvent être fiables, il n'y a pas d'utilisateurs externes et les données à l'intérieur de l'application ne sont pas très utiles aux attaquants. Cela signifie que le modèle de menace est très limité et qu'il n'y a pas beaucoup de données sensibles.
Compte tenu de ces détails, il semble que certaines mesures, comme la protection TLS et XSS, ne seraient pas aussi importantes. Après tout, il y a très peu de risques que des attaquants interceptent le trafic, et les utilisateurs peuvent être autorisés à ne pas entrer de charges utiles XSS. Dans ce cas, serait-il toujours judicieux de mettre en œuvre des mesures de sécurité contre l'interception du trafic ou les utilisateurs malveillants?
Oui. Absolument oui.
Vos hypothèses sur votre réseau interne ont des problèmes:
- vous supposez qu'aucun attaquant ne prendrait le contrôle d'un appareil de votre réseau, ce qui est une mauvaise hypothèse (voir http://www.verizonenterprise.com/verizon-insights-lab/dbir/ , https://www.fireeye.com/current-threats/annual-threat-report/mtrends.html ). Les attaquants mettront un certain temps à prendre pied dans un réseau, et il existe un marché commercial pour acheter des hôtes compromis au sein de sociétés spécifiques.
- vous supposez que seuls les utilisateurs y ont accès, mais qu'en est-il des tiers, tels que les prestataires de services gérés, les sous-traitants, les employés temporaires? De plus, que se passe-t-il si quelqu'un se connecte au wifi? Ou accède à un port filaire (par exemple, un pwnplug )
Plus généralement, il y a aussi la question de savoir pourquoi avoir deux ensembles de pratiques/normes, alors qu'il est sûrement plus efficace d'avoir une seule norme qui s'applique partout?
Vous pouvez trouver utile de lire l'article de Google sur BeyondCorp, https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44860.pdf .
Le tl; dr étant que dans leur conception du réseau, vous faites des affirmations sur les utilisateurs et les appareils, mais pas sur le réseau - principalement parce qu'il est plus simple de supposer que tous les réseaux sont hostiles, que de supposer que certains le sont, et certains le sont non (en partie, le coût d'une classification erronée d'un réseau comme sûr pourrait être très, très élevé).
Une des raisons possibles d'une telle approche est que les fuites de Snowden ont révélé que les hypothèses précédentes sur la sécurité de leur réseau étaient incorrectes - le NSA exploité dans la fibre afin d'exploiter (à l'époque non chiffré) flux de données inter-DC.
Je pense que la réponse de base à votre question est que le point de limite/démarcation pour la sécurité n'est plus au bord de votre réseau, ce sont les appareils sur votre réseau. Et en tant que tel, il est à la fois plus simple et plus réaliste de se concentrer sur la prévention des catégories d'attaques/abus, plutôt que de considérer qu'un réseau est "meilleur" qu'un autre. Il se peut que vous n'ayez pas besoin de contrôles aussi puissants sur un DMZ externe que sur un externe, mais supposer que votre réseau est sécurisé est une hypothèse dangereuse à faire.
La surface d'attaque sur le réseau interne et le réseau externe est différente, ce qui signifie que différentes mesures de sécurité sont appropriées. Cela ne signifie pas que la surface d'attaque dans le réseau interne est plus petite car d'un côté les utilisateurs sont généralement plus fiables et de l'autre côté il y a des données plus critiques qui sont souvent faciles d'accès depuis l'intérieur.
Même si tous les utilisateurs peuvent faire confiance, il est possible que leur système soit infecté par des logiciels malveillants. En dehors de cela, bon nombre des attaques que vous avez mentionnées comme CSRF, SQLi ou XSS peuvent être effectuées entre les origines, c'est-à-dire qu'il suffit qu'un utilisateur interne visite un site Web externe qui utilise ensuite le navigateur interne comme un trampoline pour attaquer les internes systèmes.
En résumé: une protection appropriée est également nécessaire pour les réseaux internes, même si tous les utilisateurs peuvent être fiables. Cela est particulièrement vrai s'il est possible d'accéder à la fois au réseau interne et à Internet à partir du même système, car cela permet des attaques d'origine croisée à partir d'Internet contre des systèmes internes.
Je dirais non, principalement en raison de cette citation du message d'origine spécifiée:
il n'y a pas d'utilisateurs externes et les données à l'intérieur de l'application ne sont pas très utiles aux attaquants
La principale considération est que, même dans un réseau interne, les acteurs hostiles peuvent toujours compromettre les systèmes qui peuvent ensuite être utilisés pour accéder à votre application Web.
Je pense que votre modèle de menace est toujours un élément important à prendre en compte ici, et malgré les craintes qu'une application puisse être introduite, si tout ce que vous protégez est celui de Joe calendrier des vacances et invitations à la fête de Sally, il peut ne pas être utile de mettre en œuvre le filtrage HSTS, HPKP et XSS, etc.
La plupart des logiciels malveillants qui infecteront les machines locales ne seront probablement pas conçus pour exécuter une analyse du réseau et trouver des serveurs Web intranet. Ceux qui le seront vont probablement chercher des paquets connus (bien que certains vont juste chercher des noms communs et exploser toutes les formes qu'il peut trouver avec des exploits connus)
Ceci est similaire à la sécurité par l'obscurité, et est définitivement une mauvaise pratique. Cependant, les préoccupations pratiques l'emporteront sur les idéaux dans de nombreux scénarios. Je recommanderais quand même au moins un certificat auto-signé et HTTPS/TLS.
Un système comme celui-ci ne peut pas survivre à une attaque ciblée, mais puisque vous avez éliminé la surface d'attaque la plus courante (accès public à Internet), la majeure partie des abus automatisés ne trouvera pas votre site.
Quelques ajouts aux excellentes réponses:
beaucoup de choses que vous devez faire pour vous protéger contre XSS (encoder correctement les données lorsque vous les affichez, principalement) sont également nécessaires pour éviter une variété de bogues qui peuvent être déclenchés par une entrée parfaitement innocente (vous ne voulez pas qu'un champ de texte soit être cassé juste parce qu'il contient un
<ou&au mauvais endroit). Il en va de même pour les injections SQL (vous ne voulez pas qu'une requête soit interrompue juste parce qu'il y a une citation dans un champ). Vous devez donc faire ce genre de choses de toute façon, même si ce n'est pas pour des raisons de sécurité.il y a une forte tendance pour les navigateurs à devenir de plus en plus restrictifs sur les sites non-TLS, au point qu'ils pourraient devenir très inutilisables dans un avenir proche (ou à tout le moins afficher tellement d'avertissements que cela effrayera vos utilisateurs).
de plus, même si vous ne ciblez que des utilisateurs internes sur un réseau interne et qu'ils peuvent être entièrement fiables (voir les autres réponses pour des raisons pour lesquelles ils ne devraient pas), les choses peuvent changer à l'avenir. Vous devrez peut-être ouvrir (des parties de) le site à des utilisateurs externes (partenaires, fournisseurs, clients ...). Il est beaucoup plus facile de prendre les bonnes mesures lorsque vous effectuez le développement initial que de moderniser la sécurité ultérieurement.
Créez un modèle de menace. Selon les données stockées et les menaces que vous identifiez, vous pouvez constater que vous avez besoin de normes de sécurité différentes ou que, tout bien considéré, il n'y a en fait aucune différence cruciale.
Répondre à la question en termes généraux peut se faire de telle ou telle manière, selon les hypothèses retenues, comme vous pouvez déjà le voir dans les réponses données. Mais au final, LAN ou Internet public n'est qu'une variable de l'ensemble et vous ne pouvez pas résoudre x = y + z avec une seule des variables données.