Maison / Technologie / Comment fonctionnent les vulnérabilités liées à la sécurité des logiciels et ce que vous pouvez faire pour rester en sécurité

Comment fonctionnent les vulnérabilités liées à la sécurité des logiciels et ce que vous pouvez faire pour rester en sécurité

Suivre
( 0 Abonné(e)s )
X

Suivre

E-mail : *

Les aspects les plus cruciaux de notre vie, y compris nos finances, notre identité et nos soins de santé, dépendent maintenant du code. La sécurité des logiciels est désormais un aspect critique non seulement pour les entreprises, mais également pour les particuliers.

Dans les circonstances les plus récentes, nous estimons que les concepts de sécurité des logiciels doivent être compris au moins à un niveau élémentaire par quiconque utilise des produits et des services logiciels modernes. Et pour tout développeur qui travaille à la conception, à la création ou à la maintenance de ces produits et services, une compréhension globale des vulnérabilités de sécurité et des meilleures pratiques de sécurité est indispensable pour éviter les violations de la sécurité qui pourraient maintenant coûter beaucoup plus cher que jamais.

La plupart du temps, les failles de sécurité nous paraissent lointaines et peu familières. ce sont des problèmes potentiels pour nous qui ne sont pas entièrement tangibles; donc facile à négliger. Imaginer un attaquant réel entrant dans vos systèmes à l’aide du plug-in de serveur de messagerie obsolète dont vous ne pensez jamais qu’il a réellement besoin de mises à jour, ou des pirates informatiques entrant dans vos systèmes via un réservoir de poissons intelligent que votre entreprise vient d’apporter au bureau est difficile; jusqu’à ce que vous en fassiez l’expérience. Le fait de respecter des délais stricts et de répondre continuellement aux demandes de nouvelles fonctionnalités ne nous aide pas non plus à veiller à la sécurité des logiciels.

Une approche populaire de la sécurité des logiciels.

Dans cet article, je vais passer en revue des exemples concrets de vulnérabilités et d’exploits logiciels connus, répartis en différentes catégories (par exemple,Application","Bibliothèque" ou "Système"Vulnérabilités") pour rendre la sécurité de nos logiciels et systèmes plus tangible et abordable. Ce n’est en aucun cas une liste exhaustive, ni une liste exhaustive de catégories. Si vous plongez, il reste encore beaucoup à découvrir dans les bases de données de vulnérabilités, les articles, les supports de discussion et peut-être dans votre serveur.

Vulnérabilités des applications

Votre mot de passe est utilisé par / u / rowealdo37189.

Il est difficile d’imaginer que la fonctionnalité que vous venez d’ajouter au produit sur lequel vous travaillez donne à n’importe qui sur Internet le pouvoir d’exécuter du code arbitraire sur votre serveur en tant que fonctionnalité supplémentaire, mais c’est le cas. Dans le feu du développement, nous introduisons dans le code de nombreux bugs qui peuvent être transformés en vulnérabilités, et nous ne pourrons jamais les considérer comme des vulnérabilités avant même de voir quelque chose de similaire en action. Voici donc quelques exemples de scénarios réels d’infractions au code d’application:

Panera Pain Incident

Comme Dylan Houlihan rapports, en août 2017, il a envoyé un courrier électronique l’informant Panera pain Director of Information Security d’une vulnérabilité dans leur API de livraison qui permet à n’importe qui d’obtenir le nom complet, l’adresse personnelle, l’adresse électronique, les préférences alimentaires / diététiques, le nom d’utilisateur, le numéro de téléphone, la date de naissance et les quatre derniers chiffres d’une carte de crédit enregistrée de n’importe quel pain Panera client qui s’est connecté à un compte, simplement en incrémentant un index dans un URI. Il mentionne brièvement la vulnérabilité sans donner de détails et suggère que si le directeur fournit une clé PGP (une clé publique qui permettrait à Dylan Houlihan de chiffrer son rapport afin qu’il soit le seul à pouvoir le déchiffrer), il pourrait envoyer un rapport sans toute autre entité écoutant / lisant le courrier électronique et apprenant la vulnérabilité.

Apparemment, il est rejeté par le directeur de la sécurité de l’information, accusé d’avoir envoyé le courrier électronique comme une "tactique de vente" et indiquant également que "demander une clé PGP ne serait pas un bon moyen de commencer" et une pratique de sécurité ne répondrait jamais à la demande comme celle qu’il a envoyée ».

PGP est un outil développé par Phil Zimmermann en 1991. Il utilise un cryptage asymétrique, dans lequel une clé peut être utilisée pour le cryptage, mais pas pour le décryptage, d’où le nom asymétrique. Cela permet à une personne d’avoir une "clé publique" et une "clé privée", la clé publique ne pouvant être utilisée que pour chiffrer des données, vous pouvez donc les distribuer librement. vous pouvez le mettre sur votre site Web, ou l’écrire sur un papier et le laisser sur votre bureau, c’est totalement sûr; comme les gens ne peuvent l’utiliser que pour chiffrer des données, seule la personne avec la clé privée est capable de les déchiffrer et de les lire. Dans ce cas, il a suggéré à Panera Bread de lui envoyer une clé publique (une nouvelle clé peut être générée en moins d’une minute pour cette conversation puis supprimée) par mesure de sécurité, afin que personne ne connaisse les détails de la conversation. Panera Bread sera en sécurité jusqu’à ce que le problème soit résolu rapidement. Ou c’est ce qu’il supposait arriver.

Bref, Panera Bread n’a apparemment pas corrigé la vulnérabilité pendant huit mois. Après cela, certains experts en sécurité, ne souhaitant toujours pas informer Panera Bread, ont décidé de l’exposer publiquement. Une fois la vulnérabilité exposée publiquement, Panera Bread a déclaré que les dommages sont limités à 10 000 utilisateurs et qu’ils corrigent la situation. Et apparemment, ils ne l’ont pas fait avant ils devaient.

Incident Fiserv

En août 2018, KrebsOnSecurity a signalé que Kristian Erik Hermansen, consultant en sécurité, avait trouvé un vulnérabilité dans la plateforme bancaire Fiserv. Cette vulnérabilité permettait à un utilisateur de voir les données relatives aux transactions d’autres utilisateurs, notamment leur adresse de messagerie, leur numéro de téléphone et leur numéro de compte bancaire complet. Les données pourraient être obtenues simplement en incrémentant un paramètre appelé «numéro d’événement».

Selon le rapport, Fiserv a développé un correctif dans les 24 heures suivant la réception de la notification et le correctif est déployé rapidement après.

Incident sur Facebook

Dans Septembre 2018, une mise à jour de sécurité est publiée par Guy Rosen, vice-président de la gestion des produits de Facebook. Il a expliqué une vulnérabilité qui permet à un utilisateur de générer des jetons d’accès pour d’autres utilisateurs ayant accès à leurs comptes. Selon la mise à jour, la vulnérabilité est causée par plusieurs bogues agissant ensemble. Un outil de téléchargement de vidéos apparaît dans une mauvaise page et le bouton "Voir en tant que" sur cette page permet normalement à l’utilisateur de voir son profil comme le ferait un autre utilisateur, générant ainsi des jetons d’accès accordant à l’utilisateur la permission d’accéder aux comptes d’autres utilisateurs.

Incident USPS

Selon le rapport, une autre vulnérabilité concernant le contrôle d’accès à l’API n’a été corrigée que plus d’un an après sa découverte, ce qui permettait à tout utilisateur connecté d’afficher les informations personnelles d’autres utilisateurs simplement en envoyant des requêtes à l’API.

Et il existe également de nombreuses autres façons d’attaquer une application qui ne sont pas mentionnées ici mais qui sont importantes, comme falsification de requête intersite attaques (très fréquent avec des solutions connues), attaques de script entre sites, exécution de code à distance attaques, et les attaques rendues possibles par l’absence de meilleures pratiques de sécurité, telles que hachage et salage des mots de passe.

La plupart des vulnérabilités des applications sont évitables grâce à une bonne conception architecturale axée sur l’authentification et l’autorisation, l’utilisation des meilleures pratiques de sécurité connues et la conception en vue d’atténuer les vecteurs d’attaques connus sur le terrain. Les autres, comme un bug complexe résultant de nombreux petits bugs qui interagissent, comme dans le cas de Facebook, et Heisenbugs qui disparaissent lorsque vous regardez leur chemin, posent un défi à détecter et à corriger.

Remarque: Je sais que, malgré le sujet sur lequel je suis en train d’écrire, est la sécurité de la couche application, je n’ai pas mentionné les attaques par injection. Oui, je suis conscient qu’ils existent toujours. Et ils ne partent pas. En fait, ils sont extrêmement populaire, et leur nombre de rapports publiés ne cesse de se détériorer. En cette année, je suggère que, si votre code est violé en utilisant une attaque par injection, vous preniez immédiatement des vacances. Ne tenez pas compte de l’état actuel du projet ou des délais. Prenez des vacances, partez seul dans un endroit de préférence montagneux et réfléchissez profondément sur vous-même, tout en ne survivant qu’avec ce que la nature vous offre. Lorsque vous revenez, vous reviendrez une nouvelle personne. L’ancien, vous serez mort. Ou vous pouvez envisager de valider, d’assainir et d’échapper à votre saisie et d’utiliser une solution ORM.

Vulnérabilités liées au framework, aux bibliothèques et aux services tiers

Nos infrastructures, bibliothèques et fournisseurs de services tiers ne sont souvent pas nos points forts. Ci-dessous, je vais essayer de démontrer l’étendue réelle de cette situation.

Incident d’Equifax

Si Content-Type est une expression OGNL, allez-y, jambes du gadget.

Violation d’Equifax Une violation de données importante s’est produite en 2017, au cours de laquelle des informations confidentielles personnelles d’environ 148 millions de personnes sont compromises. Selon le rapport la brèche avait deux aspects importants:

  1. Apache Struts 2 2.3.x avant les versions 2.3.32 et 2.5.x avant la version 2.5.10.1 présentait une vulnérabilité dans la fonctionnalité de téléchargement de fichier permettant à un attaquant de s’exécuter commandes shell distantes arbitraires sur le serveur. La vulnérabilité a été révélée et documentée sous le nom CVE-2017–5638 en mars 2017. La violation de données d’Equifax a été annoncée jusqu’en septembre 2017.
  2. La violation de données n’a pas été détectée car le périphérique utilisé pour surveiller le trafic réseau était inactif depuis plus de 10 mois en raison de l’expiration du certificat de sécurité.

CVE-2017–5638 est causée par une valeur d’en-tête (type de contenu) en cours d’évaluation en tant qu’expression Apache OGNL, OGNL être une langue à part entière elle-même. Les attaquants ont utilisé la flexibilité de ce langage d’expression pour concevoir et injecter une expression capable d’exécuter n’importe quel script shell fourni.

Après la rupture, la situation s’est aggravée de manière exponentielle, entraînant des démissions de la direction, des reproches portés aux employés et un manque général de gentillesse.

Après cela, trois autres vulnérabilités d’exécution de code à distance, à savoir: CVE-2017–9791, CVE-2017–9805 et CVE-2018-11776 fait surface au cours de l’année, le dernier annoncé a également été lié aux expressions OGNL.

Selon Fortune article publié en mai 2018, Sonatype, la société qui entretient Le référentiel central, a détecté que “pas moins de 10 801 organisations – y compris 57% des Fortune Global 100 téléchargeait toujours une version ancienne et vulnérable d’Apache Struts.

Magecart

Magecart est un groupe de pirates informatiques très méchant, composé de groupes plus petits et indépendants, chacun d’entre eux ayant pour objectif d’obtenir les informations de votre carte de crédit via une plate-forme de négociation en ligne / un site Web que vous utilisez, et de les vendre en ligne. Et ils sont très réussi dans ce qu’ils font.

Ils fonctionnent principalement au moyen de scripts injectés directement dans les sites Web de commerce électronique ou par le biais de services tiers utilisés par ces sites Web. Les scripts qu’ils injectent sont petits et efficaces: ils saisissent des informations sensibles directement sur le navigateur, dans votre navigateur, et les envoient à un serveur qu’ils configurent, un serveur agréable avec des certificats SSL, etc.

Violation de British Airways, où 380 000 victimes sont signalées, est un exemple de leurs méthodes, telles que la Violation Ticketmaster. Après cela, ils ont apparemment décidé d’attaquer environ mille autres plates-formes. Et comme ils réalisaient qu’ils étaient imparables, ils commencèrent à se bagarrer, modifier les scripts de chacun pour donner à l’autre groupe de faux numéros de carte de crédit.

Aujourd’hui, ils poursuivent leurs activités et le secteur a du mal à trouver une solution pour la détection des infractions par magecart.

Bibliothèques tierces malveillantes

Nos dépendances de tiers peuvent vraiment nous mordre. Dans les années passés, David Gilbertson et Balance de Jordanie déjà publié deux articles hilarants et terrifiants sur la façon dont nos dépendances peuvent être dangereuses. David Gilbertson a déclaré: «Nous vivons à une époque où les gens installent des packages npm comme s’ils faisaient exploser des analgésiques.". C’est en fait vrai; et non sans conséquences.

En fin de compte, toute dépendance vis-à-vis de tiers que nous introduisons sans les efforts nécessaires pour la rechercher (par exemple, «j’avais juste besoin d’une barre de chargement et d’une recherche sur npm») peut potentiellement créer davantage de dépendances inédites. lire le code de, ou même connaître, et chacune de ces dépendances peut également apporter d’autres dépendances d’eux-mêmes. Et tout ce gâchis est exécuté dans la même étendue que la boîte de dialogue de paiement par carte de crédit.

Vulnérabilités de mauvaise configuration

Parfois, l’application en cours de déploiement n’a pas de configuration par défaut sécurisée, et il est en fait attendu de la personne qui la déploie qu’elle active ses fonctionnalités de sécurité. Mais cela ne se produit généralement pas, car de toute façon qui lit toute la documentation, à l’exception de ce type bizarre qui termine moins de tâches que tout le monde, car il examine tous les détails de la configuration.

Vulnérabilité SAP

En 2018, un rapport est publié par Onapsis, indiquant une vulnérabilité de la configuration par défaut pour NetWeaver, un composant clé de SAP fournissant une plate-forme permettant à plusieurs déploiements SAP de fonctionner et de communiquer.

Il s’avère que vous devez le configurer pour le contrôle d’accès en définissant un ACLSinon, les effets secondaires peuvent impliquer que n’importe quel utilisateur du réseau puisse accéder au serveur de messagerie principal qui connecte les serveurs SAP, et prendre ainsi le contrôle de l’intégralité de la plate-forme SAP, ce qui est très bien si vous aimez regarder ou modifier. secrets commerciaux arbitraires de manière non autorisée.

L’aspect le plus intéressant est selon le rapport, cette configuration requise était bien documentée depuis 2005 et se retrouve encore dans de nombreux systèmes.

MongoDBs flottants

MongoDB est une base de données NoSQL géniale, basée sur des documents, qui a souvent été mal utilisée car elle était considérée comme une solution miracle, en particulier au début de sa popularité. Et avant la version 2.6.0, il écoutait 0.0.0.0. Et il a été déployé sur des machines du monde entier. Sans secret d’authentification. Sans pare-feu. Sans changer le port.

Tim Kadlec rapporte que plus 28 000 les déploiements ont été piratés.

Je viens de déployer notre base de données.

Vulnérabilités du système d’exploitation

Les vulnérabilités du système d’exploitation sont des vulnérabilités que nous essayons généralement d’éviter grâce aux mises à jour du système, à l’isolation du réseau et à la prière. Elles sont puissantes, difficiles à trouver et à comprendre et nécessitent plus d’efforts de réparation, en raison de leur niveau fondamental inférieur. Je vais essayer d’expliquer brièvement deux vulnérabilités récentes et importantes, afin de montrer leur apparence et la gravité de leurs conséquences. être.

Vouloir pleurer

En 2016, un groupe appelé Courtiers d’ombres jeté un grand nombre d’exploits qu’ils prétendent être des outils de piratage de la NSA sur l’internet sans méfiance. Les exploits avaient des noms amusants qui n’avaient apparemment rien en cohérence avec la vulnérabilité réelle, ou quoi que ce soit (EPICBANANA est mon préféré). Retour au sujet, un exploit (ETERNALBLUE /CVE-2017–0144) a utilisé une vulnérabilité du protocole SMB (Server Message Block) de Microsoft Windows pour exécuter du code arbitraire sur le serveur. Cette vulnérabilité permettrait ultérieurement Vouloir pleurer être développé et relâché dans la nature. Après qu’il se déchaîne, les systèmes de santé, les systèmes gouvernementaux et les entreprises ont été compromis, des rançons ont été demandées et des batailles ont eu lieu dans le monde entier.

WannaCry se promène dans la nature.

Vulnérabilités de polices Windows TrueType et Duqu

Il se trouve que Le système de rendu de police Windows TrueType a une machine virtuelle et cette machine virtuelle s’exécute dans l’espace noyau, car pourquoi pas (il est parfaitement correct de relire la phrase précédente). Cette situation a entraîné un ensemble de vulnérabilités exploitées par un ensemble de virus non plaisants, notamment Duqu, un successeur de Stuxnet. Pour plus de détails, veuillez vous référer à ici et ici. Ces vulnérabilités et les autres vulnérabilités connectées à celles-ci, ainsi que celles qui ont été révélées plus tard, sont corrigées après leur découverte.

Que pouvons-nous faire?

Comme démontré ci-dessus, notre logiciel peut être compromis de nombreuses manières créatives et inattendues.

Cela peut sembler déprimant. Une seule erreur ou négligence peut nous exposer. Mais tout n’est pas perdu. Nous pouvons faire beaucoup de choses pour assurer la sécurité de nos systèmes. De nombreux systèmes sont vulnérables en raison de la non application des idées tirées des leçons apprises dans l’industrie du logiciel.

Voici une liste des mesures de sécurité que vous pouvez utiliser pour vos systèmes et de votre code pour les protéger contre les vulnérabilités de sécurité connues. En lisant, vous constaterez que beaucoup d’entre eux sont directement liés aux exploits décrits plus haut.

1. Gardez vos systèmes à jour.

Une fois la vulnérabilité documentée, les systèmes d’exploitation, les infrastructures et les bibliothèques sont éventuellement réparés. Ce sont principalement les systèmes qui restent, ceux qui ne sont toujours pas mis à jour plusieurs semaines / mois après la documentation de la vulnérabilité et la publication d’un correctif qui devient une proie. Ce sont des cibles faciles pour quiconque est conscient de la vulnérabilité. Et probablement à ce stade, même un code d’exploitation de validation de concept circule pour que tout le monde puisse le lire, l’adapter et l’utiliser contre vous. Garder vos systèmes à jour est une méthode assez peu coûteuse pour vous protéger, et cela en vaut la peine.

2. Réduisez la surface d’attaque.

De nombreuses cibles faciles de votre système peuvent être éliminées en réduisant l’exposition au minimum requis par l’application. Réduisez la surface d’attaque en désactivant toutes les fonctionnalités que vous n’utilisez pas, en fermant les points de terminaison non exposés, en supprimant les plug-ins / extensions inutiles et en réduisant les autorisations selon le principe des privilèges minimaux.

3. Protégez votre environnement de production / réseau.

Le fait de laisser des parties de votre réseau inutilement ouvertes sur le monde extérieur ou d’utiliser des périphériques réseau dotés de logiciels obsolètes / vulnérables peut exposer vos systèmes à des risques. Les réseaux utilisés dans les environnements de production doivent être limités pour limiter l’exposition au monde extérieur afin que seuls les points de terminaison nécessaires soient accessibles. Ils peuvent également être divisés en plusieurs réseaux isolés, en fonction de l’application / des conteneurs en cours d’exécution dans l’environnement, de leurs points de terminaison possibles et de leurs interactions. Une solution de surveillance doit être déployée pour suivre le réseau et générer des alarmes en cas de problème. L’ensemble du système doit être conçu de manière à être aussi propre, simple et automatisé que possible afin de pouvoir agir facilement en cas d’urgence. Des tests de pénétration peuvent être utilisés.

4. Surveillez votre système.

Déployez des solutions de surveillance et configurez-les pour générer des alarmes efficaces et pouvant être déclenchées pour toute activité suspecte. Les événements à surveiller peuvent inclure des pics de taux d’interrogation de la base de données, des dépassements de limite de flux de données, un dysfonctionnement ou une fermeture du serveur, des pics de taux d’erreur d’application et des activités réseau suspectes.

5. Apprenez la configuration en détail.

L’outil / serveur / base de données que vous utilisez peut ne pas avoir de configuration par défaut sécurisée. C’est une leçon souvent apprise à la dure. Peut-être a-t-il une configuration de développement distincte qui vous permet de l’évaluer localement, ou peut-être pas, et qui reste configuré comme un serveur de développement qui écoute les connexions externes à votre adresse IP publique et fait des choses folles quand on le lui demande. Nous ne pouvons pas savoir avant d’avoir lu et compris la configuration et d’avoir explicitement défini nos choix dans le fichier de configuration.

6. Automatiser si possible.

Les humains font des erreurs, automatisez-vous. Automatisez votre processus de construction, de test, de déploiement et de configuration. Automatisez tout ce que vous pouvez raisonnablement. Tous saluent les robots.

7. Surveillez vos fournisseurs de services.

Les services tiers que nous utilisons, tels que le CMS, le stockage, les fournisseurs de SAAS et de cloud, les fournisseurs de services réseau et d’autres services logiciels peuvent également ouvrir la voie à des attaques potentielles, puisqu’une attaque réussie peut rendre vos mesures de sécurité inutiles. Ces services ne doivent être utilisés qu’après les avoir évalués du point de vue de la sécurité. Des solutions de surveillance peuvent également être déployées pour détecter les modifications suspectes dans les services fournis.

8. Cochez et validez vos dépendances.

Une bibliothèque ou un composant que vous utilisez peut potentiellement exposer l’ensemble de votre application. Par conséquent, il est important de savoir quel code vous utilisez, comment et où il est publié, l’entité / organisation qui le publie, ses cycles de publication et sa visibilité en termes de vulnérabilités. Garder la liste des dépendances courte et des sources fiables rend moins probable les problèmes de sécurité liés aux dépendances externes.

9. Profitez des meilleures pratiques.

Répéter des erreurs connues avec une attitude extrêmement confiante est un passe-temps populaire parmi les développeurs. D’autre part, il existe de bien meilleures alternatives pour passer du temps. Tel que;

  • Utilisation d’un contrôle d’accès à granularité fine.
  • Utilisation du hachage et du salage pour les mots de passe.
  • Connaître les bases du chiffrement et le fonctionnement des chiffrements symétriques / asymétriques à un niveau élémentaire.
  • Sachant ce qu’est TLS / SSL, pourquoi est-ce important et l’utiliser pour toutes les communications avec / entre nos services.
  • Connaître les bases de la mise en réseau et les pare-feu, et faire preuve de prudence à l’égard de votre réseau.
  • Connaître des vecteurs d’ouverture / d’attaque bien connus dans votre domaine spécifique (par exemple, XSRF pour les développeurs front-end).
  • Désactiver cette page d’erreur par défaut.
  • Désactiver cette page d’erreur par défaut.

Remarque: Oui, j’ai écrit «Désactiver cette page d’erreur par défaut» deux fois.

10. Gardez votre code propre et maintenez vos efforts pour une bonne architecture.

Dans un code propre, bien entretenu et doté d’une bonne architecture, les erreurs sont beaucoup plus faciles à détecter et à corriger. Si votre code est rempli de solutions de contournement et de hacks et qu’il ressemble à ce (C’est un Ordinateur 8 bits fabriqué à l’aide de cartes géantes, de cavaliers et de puces logiques. N’est-ce pas cool), vous aurez même du mal à trouver la source d’un bogue / vulnérabilité que vous connaissez déjà, et encore moins à le réparer rapidement, ou à en détecter un inconnu dans le code lors de la révision. De plus, une bonne architecture est une architecture conçue avec des aspects de sécurité, tels que le contrôle d’accès et la validation; Il est donc probable qu’une vulnérabilité ne parvienne pas du tout dans votre code au cours du développement.

11. Écrivez le code avec la sécurité à l’esprit.

Écrire du code pour être sécurisé dès le début est le meilleur moyen d’aborder la sécurité des applications. D’autre part, il est difficile de définir des règles globales pour l’écriture de code sécurisé. mais nous devrions en avoir quand même. Ci-dessous, certaines règles sont compilées en analysant les types de vulnérabilité courants. Elles peuvent donc être atténuées dès le début lors de l’écriture de nouvelles applications.

Bien qu’il puisse y avoir des exceptions aux règles suivantes, il a été prouvé qu’elles étaient fondamentales. Donc, comme toujours, prenez-les avec un grain de sel; mais considérez le fait que ne pas les suivre a provoqué de nombreux exploits dans le passé.

Toujours valider, nettoyer et filtrer.

Y U NON RECONNAÎTRE ENTIÈREMENT LES ENTRÉES AVANT LE TRAITEMENT !?

Les entrées externes doivent toujours être validées par rapport à des règles définissant explicitement ce que les entrées doivent contenir exactement. La longueur de l’entrée, les caractères / symboles binaires qu’elle peut contenir, le modèle des données et les restrictions sur les valeurs pouvant être attribuées à un champ sont parmi les éléments pouvant être validés. De plus, la structure de l’entrée et ses champs doivent être validés s’ils se présentent sous la forme d’un document (par exemple, JSON, XML, YAML). Les données d’entrée doivent être validées le plus tôt possible, avant d’exécuter toute logique, ce qui supposerait qu’elles sont déjà valides. Plusieurs bibliothèques peuvent être trouvées pour cette tâche dans plusieurs langues, telles que validateur commun pour Java et voluptueux pour Python. Si vous développez une API Web, vous pouvez également envisager d’utiliser une norme d’API telle que OpenAPI, qui prend également en charge de nombreuses bibliothèques et plates-formes utilisées dans le développement d’API.

Ne pas utiliser les évaluateurs. Il peut être tentant d’obtenir la requête en tant que paramètre d’entrée et de la transmettre à la base de données, au lieu d’analyser et de valider chaque paramètre de requête et de les transmettre séparément à une abstraction de référentiel soigneusement implémentée. Ou bien, il peut être tentant de choisir la méthode qui sera appelée au moment de l’exécution en évaluant l’entrée avec un moteur de script. Ne fais pas ces choses. Rédigez un code explicite, non sophistiqué et compréhensible, qui ne peut servir à quoi que ce soit pour quoi il est conçu.

Je ne sais pas quoi dire.

N’utilisez pas de scanneurs. Si vous pensez que votre code doit rechercher la méthode à appeler à l’aide d’un scanneur de code (réflexion pour Java, par exemple) en fonction des données contenues dans une chaîne de saisie, je vous conseillerais de reconsidérer votre décision. Une simple instruction switch ne suffirait-elle pas? Si vous n’en avez pas réellement besoin, les scanners peuvent être retirés de la liste. Même si vous en avez besoin, il peut y avoir d’autres options.

Faites attention aux cas d’erreur. Réfléchissez à la manière dont des erreurs / exceptions peuvent être générées et dans quelle combinaison de code, et quels sont les flux résultants. Essayez de garder la gestion des exceptions aussi simple, cohérente et régulière que possible dans votre code. La recherche de messages d’erreur est une méthode utilisée par les attaquants pour obtenir des informations sur le fonctionnement interne d’un programme. Les erreurs elles-mêmes peuvent également être utilisées pour des exploits.

Faites attention à ce que vous retournez dans une réponse. Assurez-vous qu’une réponse ne donne aucune information sur l’état interne ou le fonctionnement du logiciel au monde extérieur. Ceci est également vrai pour tous les messages d’erreur. Limitez les données renvoyées à ce qui est nécessaire pour que le client puisse reprendre le processus.

Ajoutez une journalisation détaillée et significative. Si quelque chose ne va pas, ce ne sera que vous et vos journaux. Concevez vos journaux de manière à pouvoir tracer un récit, une transaction, un processus ou autre, du début à la fin. Ajoutez trop de détails et votre base de données de journaux s’y noyera. Ajoutez-en aussi moins, et vous ne saurez même pas ce qui s’est passé ou s’il s’est passé. Pas drôle.

12. Avoir un plan de sauvetage.

Combien de temps faudrait-il pour tout restaurer à partir de référentiels de code et de sauvegardes à froid, si tous vos systèmes étaient compromis? Et si seulement une partie était brisée? Quel serait votre plan d’action détaillé, du début à la fin? Établir ces plans à l’avance peut s’avérer très utile si un événement se produit et, au mieux, vous aider à découvrir les faiblesses de votre système que vous n’aviez pas réalisées auparavant.

13. Gardez un œil sur les nouvelles.

Gardez un œil sur les blogs et les articles sur la sécurité et les bases de données de vulnérabilités telles que CVE peut vous aider à savoir si votre système / logiciel comporte une vulnérabilité déjà connue afin que vous puissiez corriger / mettre à jour vos systèmes avant qu’ils ne soient détectés et exploités. Des solutions de surveillance de la vulnérabilité sont facilement disponibles pour automatiser cette tâche.

14. Résoudre les problèmes tels que vous les voyez.

Reporter un correctif pour un problème de sécurité est extrêmement risqué et ses coûts peuvent dépasser de loin les avantages qu’il peut procurer. Pourtant, c’est une erreur souvent commise. Donc, une fois qu’une faille de sécurité est détectée, il convient de la corriger immédiatement, une fois pour toutes, avant d’ajouter de nouvelles fonctionnalités. Différer le correctif et espérer que personne ne saura rien à propos de cette vulnérabilité est une erreur très importante et fréquente commise au sujet de la sécurité des logiciels, avec des conséquences néfastes.

Conclusion

Les vulnérabilités de sécurité des logiciels sont de véritables menaces, et maintenir un système sécurisé est une tâche difficile. Mais du bon côté, il est possible de sécuriser un système de manière à forcer l’attaquant à trouver un moyen totalement nouveau et inconnu de l’attaquer. Nous pouvons le faire en ne répétant pas les erreurs commises auparavant.

Cela est possible en suivant les meilleures pratiques de sécurité sur toutes les couches de notre système et, surtout, en allouant les ressources nécessaires au maintien de la sécurité des logiciels dans notre projet et en établissant les priorités appropriées.

Après avoir reconnu ces menaces, on pourrait penser que, comme prochaine étape logique, ne pas répéter les erreurs du passé, nous ne devrions pas modifier l’infrastructure, les systèmes ou les cadres existants, ni en développer de nouveaux. juste pour éviter les risques de sécurité.

Je pense au contraire que les nouveaux outils peuvent être plus sûrs, simples et élégants qu’auparavant, et qu’ils devraient être créés. L’important est que pendant que nous les créons, nous ne devrions pas oublier les leçons du passé et prendre nos décisions de manière éclairée et rationnelle.

Merci pour la lecture. J’espère que vous avez apprécié mon article,


Comment fonctionnent les vulnérabilités liées à la sécurité des logiciels et ce que vous pouvez faire pour rester en sécurité a été publié à l’origine dans Hacker midi sur Medium, où les gens poursuivent la conversation en soulignant et en répondant à cette histoire.

Source

A propos newstrotteur-fr

Découvrez également

Cascadeurs réagissent et offrent un aperçu des bonnes et mauvaises cascades dans The Marvel Movies – Newstrotteur

Suivre ( 0 Abonné(e)s ) X Suivre E-mail : * Suivre Ne plus suivre Corridor …

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *