Bien que la réponse de Kyle Fennell soit très bonne, j'aimerais expliquer pourquoi il est recommandé de concevoir des applications internes en toute sécurité.

Un grand nombre de les attaques impliquent des acteurs internes

Il existe de nombreuses versions différentes de ce factoid. «50% de toutes les attaques réussies commencent en interne», «Les deux tiers de toutes les violations de données impliquent des acteurs internes», etc.

Une statistique que j'ai pu trouver était le DBIR 2019 de Verizon, en qu'ils affirment:

34% [des violations de données analysées] impliquaient des acteurs internes

Quel que soit le nombre exact, un nombre important d'attaques impliquent acteurs internes. Par conséquent, baser votre modèle de menace sur "il est interne, donc sûr" est une mauvaise idée .

Le développement de logiciels sécurisés n'empêche pas seulement les abus, mais aussi les abus

• Abus: L'utilisateur fait quelque chose de malveillant pour son propre profit
• Utilisation abusive: L'utilisateur fait quelque chose de malveillant parce qu'il ne le fait pas mieux connaître

La raison pour laquelle j'évoque une mauvaise utilisation est que tout ce qui nuit à l'entreprise n'est pas fait intentionnellement. Parfois, les gens font des erreurs, et si les gens font des erreurs, il est bon que les machines empêchent ces erreurs d'avoir des conséquences généralisées.

Imaginez une application où tous les utilisateurs sont autorisés à tout faire (car la configuration des autorisations prend beaucoup de temps , n'a pas été pensé pendant le développement, etc.). Un utilisateur fait une erreur et supprime tout. Cela met l'ensemble du service à l'arrêt, tandis que le service informatique subit une crise cardiaque et sprinte dans la salle des serveurs avec la sauvegarde de la semaine dernière.

Imaginez maintenant la même application, mais avec un système d'autorisation bien défini. L'utilisateur tente accidentellement de tout supprimer, mais ne supprime que ses propres tâches assignées. Leur propre travail s'arrête et le service informatique fusionne les données de la sauvegarde de la semaine dernière avec les données actuelles. Deux employés ne pourraient pas faire de travail productif aujourd'hui, au lieu de 30. C'est une victoire pour vous.

«Interne» ne veut pas dire exempt d'acteurs malveillants

Certaines entreprises sont techniquement une seule entreprise avec plusieurs équipes, mais elles sont fractionnées de telle sorte que les équipes se font concurrence, plutôt que de travailler ensemble. Vous pensez peut-être que cela ne se produit pas, mais Microsoft a été comme ça pendant longtemps.

Imaginez que vous écriviez une application à utiliser en interne par toutes les équipes. Pouvez-vous imaginer ce qui se passerait une fois qu'un employé comprendrait que vous pourriez verrouiller d'autres employés pendant 30 minutes en exécutant un script qu'il a créé? Les employés de «cette autre équipe» seraient constamment exclus de l'application. Le service d'assistance serait occupé pour la 5 ^e fois cette semaine à essayer de comprendre pourquoi parfois des personnes seraient exclues de l'application.

Vous pensez peut-être que c'est tiré par les cheveux , mais vous seriez surpris de voir jusqu'où certaines personnes iraient pour obtenir ce doux bonus à la fin de l'année pour avoir mieux performé que "l'autre équipe".

"Interne" ne reste pas "Interne"

Désormais, en 2020, votre application ne sera utilisée que par un petit groupe de personnes. En 2029, l'application sera utilisée par certaines personnes en interne, certains fournisseurs et certains entrepreneurs également. Et si l'un de vos fournisseurs découvrait une faille dans votre application? Et s'ils voyaient que l'un de leurs concurrents bénéficie de bien meilleures conditions?

C'est une situation dans laquelle vous ne voulez pas être, et une situation que vous auriez pu éviter.

Réutilisation du code depuis votre application "interne"

Vous écrivez une application interne qui effectue des tâches d'accès à la base de données. Cela fonctionne bien pendant des années et personne ne s'est jamais plaint. Vous devez maintenant écrire une application qui accède aux mêmes données, mais en externe. "Facile!", Pense le codeur novice. "Je vais simplement réutiliser le code qui existe déjà."

Et maintenant vous êtes coincé avec une application externe dans laquelle vous pouvez effectuer des injections SQL. Parce que tout d'un coup, le code qui a été créé "pour un usage interne uniquement", sans jeu de mots, est utilisé en externe. Évitez cela en améliorant le code interne en premier lieu.

Sera-ce suffisant de suivre OWASP?

La réponse à cette question est une autre question "Assez pour quoi?". Cela peut sembler difficile au début, mais cela illustre le problème. Que voulez-vous protéger exactement?

Définissez un modèle de menace pour votre application, qui inclut les personnes qui, selon vous, pourraient éventuellement constituer une menace pour votre application de quelle manière, puis trouvez des solutions pour ces menaces individuelles. OWASP Top 10 peut être suffisant pour vous, ou peut-être pas.

Oui, les applications internes doivent être sécurisées avec une diligence raisonnable et oui OWASP peut être un bon guide pour sécuriser votre application. Consultez également le cycle de vie du développement de la sécurité (SDL) de Microsoft. Il s'agit d'un processus d'assurance de la sécurité axé sur le développement de logiciels.

Pourquoi?

• Défense en profondeur . Un attaquant pourrait violer les défenses du réseau. Mettez plus de couches de protection entre eux et vos données.
• Les menaces externes ne sont pas les seules. Les vulnérabilités des applications peuvent également être exploitées par des menaces internes .

D'autres ont déjà mentionné quelques bons points sur les employés maléfiques, l'infiltration, la défense en profondeur ... mais c'est beaucoup plus pratique que cela. Je peux attaquer votre application intranet interne à partir d'une page Web aléatoire.

Les gens cliquent sur des liens toute la journée. Parfois, parce qu'un collègue a vu quelque chose qu'il souhaite partager, parfois à partir de résultats de recherche (ou d'annonces), parfois d'une jolie photo de chat avec mille votes positifs d'un site comme reddit, parfois d'e-mails de phishing.

Il y a un de nombreuses façons dont un attaquant peut vous amener à cliquer sur un lien. Prenons l'image du chat: pour les milliers d'autres personnes qui ont voté pour l'image du chat mignon, c'était inoffensif. Jusqu'à ce que quelqu'un clique dont l'entreprise utilise le site Web intranet étonnant qui ne respecte pas les directives de l'OWASP.

Cliquer sur des liens vers des pages malveillantes devrait être pratiquement inoffensif: les mises à jour régulières de votre navigateur restent il est sécurisé et ne permet pas au site Web d'accéder au reste de votre ordinateur. C'est pourquoi il est si facile de vous faire cliquer sur un lien, car il est "généralement inoffensif". Mais cela ne signifie pas qu'avoir une page, qui exécute du code JavaScript, à l'intérieur du réseau de l'entreprise cible n'est pas un avantage pour l'attaquant.

La page avec l'image de chat pourrait contenir quelque chose comme ceci:

  1. <img src = cute_cat.jpg>2. <iframe name = hiddenframe style = 'display: none'>< / iframe>3. <form action = 'http: //intranet.local/addUser.php? Username = joseph&password = 123456' id = myform target = 'hiddenframe'>4. <input type = submit style = 'display: none'>5. < / form>6. <script> document.getElementById ('mon formulaire'). Submit () < / script>  

Lors de l'ouverture de la page, de manière totalement invisible, cela pourra appeler la page addUser.php sur votre application intranet. Si vous êtes connecté (comme vous sont au travail), le navigateur ajoutera volontiers votre cookie de connexion (contenant le jeton de session par lequel l'intranet reconnaît que vous êtes vous). L'attaquant a maintenant un compte sur votre système. Pour les personnes sans application intranet, cela ne fera rien.

Ceci est un exemple d'attaque de falsification de requête intersite (CSRF) (plus quelques autres mauvaises pratiques), qui, suivant les directives de l'OWASP prévenir. Un bref aperçu de ce que fait ce code:

1. Afficher l'image du chat pour rendre la page inoffensive
2. Ajouter un cadre masqué (sous-page) dans lequel la page intranet va se charger.
3. Ajoutez un formulaire qui sera soumis à votre intranet, en appelant la page addUser avec un nom d'utilisateur et un mot de passe, choisis par l'attaquant.
4. Caché Le bouton d'envoi est nécessaire pour que le formulaire fonctionne.
5. Fin du formulaire.
6. Appelez submit () sur le formulaire, afin que le bouton d'envoi se déclenche.

Si la page addUser.php ne possède pas (ou ne vérifie) pas de jetons anti-CSRF, cette attaque est possible à 100% et de nombreux sites y étaient vulnérables autrefois. Un exemple? Intranet de mon école où les notes étaient enregistrées. J'aurais pu envoyer à un enseignant un lien vers une remise numérique, et la page aurait pu (en plus de montrer ma remise) avoir changé mes notes (ou celles de quelqu'un d'autre!) En arrière-plan.

C'est encore courant aujourd'hui. Voici un autre exemple beaucoup plus simple (et moins dangereux):

  1. <img src = 'cute_cat.jpg'>2. <img src = 'http: //intranet.local/logout.php'>  

Ceci appelle simplement la page de déconnexion. Le navigateur attend une image de cette page logout.php , mais s'il n'y a pas d'image (car c'est une page de déconnexion), il rejette simplement le résultat. Pendant ce temps, l'application intranet vous déconnecte. Si l'attaquant parvient à déclencher cela toutes les 2 secondes à partir d'un onglet que vous gardez ouvert pendant un certain temps, vous ne pourrez peut-être pas utiliser l'intranet car vous continuez à être déconnecté.

Vous vous souvenez de la faille géante de Capital One en août 2019?

La cause principale était une vulnérabilité de falsification de demande côté serveur (SSRF) dans une application interne de Capital One.

Alors oui, vous devez vous soucier de la conception sécurisée des applications internes.

Quelle plateforme? Avant de prendre ma retraite, je devais m'assurer que tout ce que j'avais écrit ne pouvait pas ne pas gérer toutes les exceptions. toute exception non gérée présenterait à l'utilisateur une fenêtre contextuelle l'invitant à envoyer des données à Microsoft qui pourraient contenir des informations personnelles que Microsoft promet de ne pas utiliser.

Bien sûr, la plupart des utilisateurs cliquent rapidement sur OK sans lire. Et que Microsoft respecte ou non cette promesse, l'envoi des données rendrait l'hôpital passible de poursuites en vertu de la HIPAA. Et HIPAA oblige Microsoft à nous signaler s'il détecte des informations sur le patient.

MacOS a une fenêtre contextuelle similaire, et si l'utilisateur ne la désactive pas dans les paramètres à l'avance, IOS envoie les données sans demander .

Et puis il y a Android, codé par l'un des plus grands concurrents de la NSA.

Donc, la réponse est «oui» pour l'une de ces plates-formes.

Absolument à 100% oui

Pour toutes les raisons évoquées et une très importante pratique: on ne sait jamais quel jour un membre de la direction décide de mettre ce truc sur le L'Internet. "Cela fonctionne si bien que nos sous-traitants externes devraient l'utiliser." ou pour une autre raison.

Une chose très courante dans une entreprise est que les gens aiment utiliser un outil interne, le mentionnent à un partenaire ou à un client, puis on réclame que l'outil soit mis à la disposition des utilisateurs externes.

Oui, appliquez quelques précautions de sécurité sur l'outil et ne vous empêchez pas de le sécuriser à l'avenir. Les choses les plus simples vont très loin, comme "créer un utilisateur dédié au lieu de root pour ce processus" et "restreindre la visibilité de l'utilisateur et du processus uniquement aux choses dont l'outil a besoin".

Je vais publier ici une déclaration générale, mais si votre application est codée professionnellement et suit les meilleures pratiques, elle devrait être déjà assez sécurisée dès la sortie de la boîte. Au moins les vulnérabilités les plus courantes telles que l'injection SQL ne devraient pas être exploitables.

Et les frameworks de développement disponibles de nos jours vous facilitent réellement la tâche. D'un autre côté, si vous donnez la priorité à la vitesse de développement plutôt qu'à la qualité, si vous êtes coincé avec les directives de codage des années 1990, si vous n'utilisez pas de requêtes paramétrées ... alors vous demandez des problèmes.

À tout le moins, vous devriez tester votre application pour vous assurer que les erreurs les plus évidentes ne sont pas présentes dans votre code et qu'un script kiddie ne peut pas compromettre votre système en lançant une attaque automatisée.

Comme le dit Tom, des éléments isolés aujourd'hui pourraient être exposés sur Internet demain, en raison d'une décision de gestion ou d'une mauvaise configuration du routeur / pare-feu. L'application peut être exposée par accident, à votre insu, ou après avoir quitté l'entreprise.

Et vous seriez surpris de voir à quel point les employés s'ennuient pendant leur temps libre. Une fois, j'ai trouvé un scanner de port sur le poste de travail d'un commis administratif qui ne maîtrise certainement pas l'informatique. L'outil n'a pas atterri là par accident. Trop souvent, les employés sont le maillon faible de toute organisation.

Ensuite, le niveau de paranoïa approprié dépend des types d'actifs auxquels votre intranet donne accès. Si les actifs sont plutôt sensibles et que l'application est piratée un jour, votre travail pourrait être en jeu si l'enquête médico-légale montre que votre code était bâclé et ne respectait pas les pratiques de sécurité minimales. Le pire des cas est que vous soyez poursuivi par votre employeur / client pour faute professionnelle - cela doit sûrement arriver de temps en temps.

Je me demande ce qui est arrivé aux informaticiens qui ont travaillé chez Equifax?

Tenez également compte de la topologie du réseau. Si l'intranet est hébergé en interne et directement connecté à votre réseau local, il s'agit d'une passerelle vers votre réseau local et d'autres ressources. Si je suis un attaquant et que je veux entrer dans votre système, je chercherai des points faibles, des routes indirectes mais négligées.

Je reformulerais donc la question comme ceci: Dans quelles circonstances on n’a pas besoin conception de logiciels sécurisés?

Pensez à votre employeur / client, mais aussi à votre réputation. Il y a de fortes chances qu'un jour quelqu'un d'autre regarde votre code. Par exemple, un autre informaticien chargé de migrer l'application à l'avenir, n'importe quoi. Quelqu'un qui est peut-être plus informé que vous et qui n'aura rien de gentil à dire en regardant votre code.