Nous attirons votre attention sur les 10 meilleurs contrôles proactifs pour les développeurs de logiciels - 10 aspects de sécurité sur lesquels les développeurs de logiciels devraient se concentrer. Cet article contient une liste des techniques de sécurité devant être mises en œuvre lors du développement de chaque nouveau projet.
Un logiciel mal protégé compromet la sécurité des infrastructures essentielles, telles que les soins de santé, la défense, l'énergie ou les finances. Notre infrastructure numérique mondiale devient de plus en plus complexe, le nombre de relations entre ses composants augmente, de sorte que l'importance de la sécurité des applications augmente de façon exponentielle. Les menaces de sécurité relativement simples ne peuvent plus être ignorées.
OWASP
Le projet de sécurité des applications Web ouvertes (OWASP) est un projet de sécurité des applications Web open source. La communauté OWASP comprend des sociétés, des organisations éducatives et des particuliers du monde entier. OWASP travaille sur des articles, des didacticiels, de la documentation, des outils et des technologies accessibles au public.
Le projet OWASP est référencé par de nombreuses normes, outils et organisations, notamment MITRE, PCI DSS, DISA, FTC et bien d'autres.
Le projet Proactive Defense: Top-10 OWASP Requirements est similaire au projet
OWASP Top-10 , mais il se concentre sur les méthodes et recommandations de protection contre les menaces, et non sur les menaces elles-mêmes. Chaque méthode et recommandation de ce document est associée à une ou plusieurs menaces de la liste OWASP Top-10.
Buts et objectifs
L'objectif du projet Proactive Defense: OWASP Top 10 Requirements est d'attirer l'attention sur la sécurité des applications en abordant les aspects les plus importants de la sécurité de l'information que les développeurs de logiciels devraient prendre en considération. Nous encourageons les organisations à tirer parti des recommandations de défense proactive de l'OWASP et enseignons aux développeurs comment prêter attention à la sécurité des applications, en accordant de l'importance aux erreurs qui se sont produites dans d'autres organisations. Nous espérons que les recommandations OWASP vous seront utiles lors de la création d'applications sécurisées.
Public cible
Le document est principalement destiné aux développeurs. Cependant, il sera utile pour les responsables du développement, les chefs de produit, les spécialistes de l'assurance qualité, les chefs de projet, ainsi que d'autres participants au processus de création de logiciels.
Top 10 des exigences de défense proactive
C1: Définition des exigences de sécurité
Les exigences de sécurité décrivent les fonctions qui doivent être implémentées pour fournir certains paramètres de sécurité logicielle. Ils sont basés sur les normes de l'industrie, les lois applicables et les données de vulnérabilité. Les exigences définissent des fonctions qui doivent être développées ou développées pour résoudre des problèmes de sécurité spécifiques ou éliminer les menaces potentielles.
La norme OVASP Application Security Certification Standard (ASVS) est un catalogue des exigences de sécurité et des options de vérification disponibles. OWASP ASVS peut fournir des exigences de sécurité avancées aux équipes de développement.
Les exigences de sécurité sont classées en fonction des fonctions de sécurité de niveau supérieur communes. Par exemple, ASVS contient les catégories suivantes: authentification, contrôle d'accès, gestion et journalisation des erreurs et services Web. Pour chaque catégorie, il existe une liste de paramètres qu'il est recommandé de vérifier.
Le processus d'application réussie des exigences de sécurité comprend quatre étapes: recherche et sélection, documentation, mise en œuvre, confirmation de la mise en œuvre correcte des nouvelles fonctions de sécurité et des fonctionnalités de l'application.
C2: Utilisation de cadres et de bibliothèques sécurisés
Des bibliothèques et des cadres sécurisés avec des fonctionnalités de sécurité intégrées aident les développeurs à éviter les vulnérabilités pendant les phases de développement et de mise en œuvre. Les développeurs qui créent une application à partir de zéro peuvent ne pas avoir suffisamment de connaissances, de temps ou d'argent pour implémenter ou maintenir la sécurité de l'application. L'utilisation de cadres sécurisés peut augmenter le niveau de sécurité des applications.
Lorsque vous incluez des bibliothèques ou des frameworks tiers dans votre logiciel, les recommandations suivantes doivent être prises en compte:
- Utiliser des bibliothèques et des cadres de sources fiables qui sont activement développés et largement utilisés dans les applications;
- compiler et tenir à jour le catalogue de toutes les bibliothèques tierces;
- tenir à jour les bibliothèques et les composants. Utilisez des outils tels que OWASP et Retire.JS dépendances vérifie pour déterminer les dépendances dans les projets, et également vérifier les vulnérabilités connues et publiées dans le code tiers;
- Utilisez l'encapsulation de la bibliothèque et uniquement les fonctionnalités nécessaires à votre logiciel pour réduire la probabilité d'attaques.
C3: Fournir un accès sécurisé aux bases de données
Cette section est dédiée à fournir un accès sécurisé à tous les entrepôts de données, y compris les bases de données relationnelles et les bases de données NoSQL.
L'injection SQL est l'une des menaces les plus sérieuses pour la sécurité des applications. Ce type d'attaque est facile à implémenter: du code SQL peut être injecté si une entrée non fiable est ajoutée dynamiquement aux requêtes SQL, ce qui se produit généralement en les attachant à la ligne principale. L'exploitation de cette vulnérabilité pourrait entraîner le vol, la suppression ou l'altération de bases de données. L'application peut également être utilisée pour exécuter des commandes malveillantes sur un système contenant votre base de données, ce qui permettra à un attaquant de prendre pied dans le réseau.
Pour empêcher les injections SQL, vous devez éviter d'interpréter les entrées non vérifiées dans le cadre des commandes SQL. La meilleure solution serait d'utiliser la méthode de «paramétrage des requêtes». Cette méthode doit être appliquée aux constructions SQL et OQL, ainsi qu'aux procédures stockées.
Des exemples de paramétrage des requêtes pour ASP, ColdFusion, C #, Delphi, .NET, Go, Java, Perl, PHP, PL / SQL, PostgreSQL, Python, R, Ruby et Scheme peuvent être trouvés sur
http://bobby-tables.com et dans le
mémo OWASP pour le paramétrage des requêtes .
C4: Encodage et blindage des données
Le codage et l'échappement sont des méthodes de protection contre l'injection de code. L'encodage, également appelé "encodage de sortie", est la conversion de caractères spéciaux en combinaisons équivalentes qui ne sont pas dangereuses pour l'interpréteur. Par exemple, le caractère <est converti en une combinaison <lorsqu'il est ajouté à une page HTML. L'échappement consiste à ajouter des caractères spéciaux devant des caractères ou des chaînes pour éviter qu'ils ne soient interprétés de manière incorrecte, par exemple, l'ajout du \ caractère avant "(guillemets doubles) vous permet de les interpréter comme faisant partie du texte et non comme un terminateur de ligne.
Il est préférable d'appliquer le codage immédiatement avant de transmettre des données à l'interpréteur. Si vous appliquez cette méthode trop tôt dans le traitement de la demande, l'encodage ou le blindage peuvent affecter l'utilisation du contenu dans d'autres parties du programme. Par exemple, si le contenu HTML est échappé avant d'être enregistré dans la base de données et que l'interface échappe à nouveau automatiquement ces données, le contenu ne s'affichera pas correctement en raison d'un double échappement.
Le codage ou l'échappement peut être utilisé pour empêcher d'autres formes d'intégration dans le contenu. Par exemple, vous pouvez neutraliser certains métacaractères spéciaux lors de la saisie de données pour les commandes système. Cela s'appelle «échapper aux commandes du système d'exploitation», «échapper au shell», etc. Une telle protection peut être utilisée pour empêcher une «injection de commande».
Il existe d'autres formes d'échappement qui peuvent être utilisées pour empêcher les injections, par exemple, l'échappement des attributs XML qui protège contre diverses formes d'intégration de chemins XML et XML, et l'échappement des noms LDAP uniques pour empêcher diverses injections LDAP.
C5: Vérification obligatoire de toutes les entrées
La validation des données d'entrée fait partie d'une technique de programmation qui garantit que seules les données correctement formatées pénètrent dans les composants du programme.
Norme syntaxique et sémantique
L'application doit vérifier la conformité des données avec la norme syntaxique et sémantique (dans cet ordre) avant de les utiliser (y compris l'affichage à l'utilisateur).
La norme syntaxique signifie que les données correspondent à la présentation attendue. Par exemple, dans une application, un utilisateur peut spécifier un «identifiant» à quatre chiffres pour effectuer certaines opérations. Un attaquant peut entrer des données qui lui permettent d'injecter du code SQL, donc l'application doit vérifier que les données entrées sont exactement des nombres et exactement de quatre caractères (en plus d'utiliser le paramétrage de requête approprié).
La norme sémantique signifie l'utilisation uniquement de données d'entrée qui ne dépassent pas une certaine fonctionnalité et un certain contexte. Par exemple, lors de la spécification d'une période, la date de début doit précéder la date de fin.
Listes blanches et noires
Il existe deux approches principales pour vérifier la syntaxe des entrées: la vérification des listes noires et des listes blanches.
La première méthode est conçue pour rechercher du contenu «potentiellement dangereux» dans les données. Par exemple, une application Web peut bloquer l'entrée contenant le mot SCRIPT pour empêcher les scripts intersites. Cependant, cette mesure de protection peut être contournée en utilisant des lettres minuscules ou une combinaison de lettres minuscules et majuscules pour la balise de script.
La deuxième méthode vise à confirmer la conformité des données avec les exigences d'un ensemble de règles "testées". Par exemple, une liste blanche d'État américain rechercherait un code à 2 lettres dans une liste d'États américains existants.
Lors de la création d'un logiciel sécurisé, la liste blanche est recommandée au minimum. Les listes noires peuvent contenir des erreurs, elles peuvent être contournées de diverses manières et, en elles-mêmes, elles peuvent être dangereuses. Bien qu'il soit possible de contourner les restrictions des listes noires, elles peuvent être utiles pour détecter des attaques évidentes. Ainsi, les listes blanches aident à limiter la possibilité d'une attaque en vérifiant que les données sont conformes aux normes syntaxiques et sémantiques, tandis que les listes noires aident à détecter et à prévenir les attaques évidentes.
Vérifications côté client et côté serveur
Pour garantir la sécurité, la vérification des entrées doit toujours être effectuée côté serveur. Les vérifications côté client peuvent être utiles en termes de fonctionnalité et de sécurité, mais elles sont souvent facilement contournées. Par conséquent, la validation côté serveur est préférable pour la sécurité. Par exemple, la vérification de JavaScript peut avertir l'utilisateur que le champ ne doit contenir que des nombres, mais l'application côté serveur doit confirmer que les données d'entrée sont des nombres dans une plage de valeurs acceptable.
C6: Implémenter l'identification numérique
L'identification numérique est une représentation unique de l'utilisateur (ou de tout autre objet) dans les transactions en ligne. L'authentification est le processus de confirmation qu'une personne ou une entité est bien ce qu'elle est. La gestion de session est le processus par lequel le serveur surveille l'état d'authentification de l'utilisateur afin qu'il puisse continuer à utiliser le système sans réauthentification. Édition spéciale
NIST 800-63B : Guide d'identification numérique (authentification et gestion du cycle de vie) fournit des directives détaillées pour la mise en œuvre des exigences d'identification numérique, d'authentification et de gestion de session.
C7: Contrôle d'accès obligatoire
Le contrôle d'accès (ou autorisation) consiste à autoriser ou à interdire des demandes spécifiques d'utilisateurs, de programmes ou de processus, et implique également la délivrance et la révocation de ces privilèges.
Il est à noter que l'autorisation (confirmation du droit d'accès aux fonctions ou ressources spéciales) n'est pas synonyme d'authentification (vérification d'identité).
Le contrôle d'accès affecte généralement de nombreux aspects du logiciel, selon la complexité du système de contrôle d'accès. Par exemple, la gestion ou la mise en cache des métadonnées de contrôle d'accès à des fins d'évolutivité sont généralement des composants supplémentaires d'un système de contrôle d'accès qui doivent être créés ou maintenus. Il existe plusieurs approches différentes du contrôle d'accès:
- contrôle d'accès sélectif (DAC) - implique de restreindre l'accès aux objets (par exemple, fichiers ou éléments de données) en fonction de l'identifiant, ainsi que du principe de la "connaissance nécessaire" des sujets (par exemple, des utilisateurs ou des processus) et / ou des groupes auxquels les objets appartiennent;
- Contrôle d'accès obligatoire (MAC) - implique de restreindre l'accès aux ressources du système en fonction de la criticité des données (définies par des étiquettes) contenues dans ces ressources et de l'autorité formelle (c'est-à-dire l'accès) des utilisateurs pour accéder aux informations d'importance spécifiée;
- Modèle de contrôle d'accès basé sur les rôles (RBAC) - implique de contrôler l'accès aux ressources en fonction des rôles qui définissent les actions autorisées avec les ressources, et non en fonction des identificateurs de sujet;
- contrôle d'accès basé sur les attributs (ABAC) - implique d'autoriser ou de refuser les demandes des utilisateurs en fonction des attributs des utilisateurs et des attributs des objets, ainsi que des éléments environnementaux qui peuvent être définis globalement et être plus pertinents pour les politiques applicables.
C8: Protection des données omniprésente
Les données confidentielles telles que les mots de passe, les numéros de carte de crédit, les dossiers médicaux, les données personnelles et les secrets commerciaux nécessitent une protection supplémentaire, en particulier si elles sont soumises à la loi sur la confidentialité des données, comme le Règlement général sur la protection des données (RGPD) de l'UE ou la loi sur la protection des données financières, telles que la norme de sécurité des données des cartes de paiement (PCI DSS).
Les attaquants peuvent voler des données d'applications Web et de services Web de différentes manières. Par exemple, un attaquant peut se connecter à un réseau sans fil partagé et afficher ou voler des données confidentielles à d'autres utilisateurs si elles sont transmises via une connexion Internet non sécurisée. Un attaquant peut également utiliser l'injection SQL pour voler des mots de passe et d'autres informations d'identification dans les applications, puis les placer dans le domaine public.
Classification des données
Vous devez classer les données dans votre système et déterminer le niveau de criticité de chaque bloc de données. Chaque catégorie de données peut ensuite être associée à des règles de protection définies pour chaque niveau de criticité. Par exemple, des informations de marketing public qui ne sont pas confidentielles peuvent être attribuées à des données accessibles au public qui peuvent être publiées sur un site Web accessible au public. Les numéros de carte de crédit peuvent être attribués aux données personnelles des utilisateurs qui nécessitent un cryptage lors de leur stockage ou de leur transfert.
Cryptage de transmission
Lors du transfert de données sensibles via n'importe quel réseau, une protection de connexion de bout en bout (ou cryptage) doit être appliquée. TLS est de loin le protocole cryptographique le plus largement utilisé et pris en charge qui fournit des connexions sécurisées. Il est utilisé dans de nombreux domaines (applications Web, services Web, applications mobiles) pour la transmission sécurisée de données sur un réseau. Pour garantir la sécurité des connexions TLS, vous devez les configurer correctement.
Le principal avantage du protocole TLS est la protection des données des applications Web contre les accès non autorisés et les modifications lors de leur transfert entre les clients (navigateurs Web) et le serveur d'applications Web, ainsi qu'entre le serveur d'applications Web et le serveur interne ou autre non-navigateur. , composantes de l'organisation.
Cryptage des données
La première règle de gestion des données sensibles consiste à éviter de stocker des données sensibles dans la mesure du possible. Si vous devez enregistrer des données confidentielles, assurez-vous qu'elles disposent d'une protection cryptographique contre les accès et les modifications non autorisés.
La cryptographie est l'un des domaines les plus avancés de la sécurité de l'information; sa compréhension nécessite des connaissances et une expérience approfondies. Il est difficile de choisir une seule solution, car il existe de nombreuses approches différentes du cryptage, et chacune d'elles a ses avantages et ses inconvénients, que les architectes et développeurs Web doivent comprendre clairement. De plus, une recherche cryptographique sérieuse est généralement basée sur des mathématiques et une théorie des nombres plus élevées, ce qui crée un seuil d'entrée élevé.
C9: implémenter la journalisation et la surveillance des événements de sécurité
La plupart des développeurs utilisent déjà la journalisation pour le débogage et les diagnostics. Il est également important d'enregistrer les événements de sécurité (données liées à la sécurité) pendant que l'application est en cours d'exécution. La surveillance est une analyse en direct des journaux d'application et de sécurité à l'aide de divers outils d'automatisation. Les mêmes outils et modèles peuvent être appliqués aux opérations en cours, au débogage et à la sécurité.
Avantages de la journalisation des événements de sécurité
Les journaux des événements de sécurité peuvent être utilisés pour:
- fournir un système de détection d'attaque avec des données;
- analyse et enquête sur les incidents;
- respect des exigences réglementaires.
Implémentation de la journalisation des événements de sécurité
Voici des recommandations pour implémenter la journalisation des événements de sécurité.
- Utilisez des formulaires et des méthodes standard pour enregistrer les événements dans le système et entre les systèmes de votre organisation. Apache Logging Services, qui fournit une compatibilité de journalisation entre les applications Java, PHP, .NET et C ++, est un exemple de plate-forme de journalisation d'événements standard.
- N'enregistrez pas trop ou trop peu de données. Par exemple, assurez-vous d'enregistrer les horodatages et les informations d'identification, tels que l'adresse IP source et l'ID utilisateur, mais n'enregistrez jamais de données personnelles ou confidentielles.
- Portez une attention particulière à la synchronisation de l'heure entre les nœuds pour garantir la cohérence de l'horodatage.
Journalisation pour détecter et contrer les attaques
Utilisez la journalisation pour déterminer l'activité qui indique un comportement d'utilisateur malveillant. Activité potentiellement dangereuse à enregistrer:
- Les données d'entrée sont en dehors de la plage numérique attendue;
- les données d'entrée modifient les composants qui doivent rester inchangés (liste de sélection, cases à cocher, autres composants à entrée limitée);
- les demandes qui violent les règles de contrôle d'accès côté serveur;
- Une liste plus détaillée des marqueurs d'attaque peut être trouvée ici .
Lorsqu'une application détecte une telle activité, elle doit au moins enregistrer cet événement et le marquer comme dangereux. Idéalement, l'application devrait contrer l'attaque, par exemple en annulant la session de l'utilisateur et en bloquant son compte. Le mécanisme de contre-mesure permet au programme de répondre aux attaques détectables en temps réel.
C10: Traitement obligatoire de toutes les erreurs et exceptions
La gestion des exceptions permet à une application de répondre à diverses erreurs (par exemple, une panne de réseau ou une connexion à une base de données) de différentes manières. Un traitement correct des exceptions et des erreurs est simplement nécessaire pour garantir la fiabilité et la sécurité de votre code.
Les erreurs et les exceptions sont gérées à tous les niveaux de l'application, y compris la logique métier critique, les fonctionnalités de sécurité et les infrastructures.La gestion des erreurs est également importante pour détecter les attaques. Certaines attaques sur les applications peuvent provoquer des erreurs qui peuvent détecter une attaque dans le processus.Traitement d'erreur incorrect
Des chercheurs de l'Université de Toronto ont découvert que même une petite erreur lors du traitement des erreurs ou de leur ignorance peut entraîner des dysfonctionnements critiques dans les systèmes distribués .Une gestion incorrecte des erreurs peut entraîner diverses vulnérabilités.- . . , , , . (, ) . , , , .
- TLS. Apple «goto fail» , TLS- Apple.
- . . . .
- , try/catch . .
- Assurez-vous que les messages d'erreur affichés ne contiennent pas de données critiques, mais qu'ils contiennent suffisamment d'informations pour répondre correctement.
- Assurez-vous que les exceptions sont consignées afin que les membres du support technique, du contrôle qualité, de l'enquête sur les incidents ou de l'équipe d'intervention disposent de suffisamment de données pour résoudre le problème.
- Testez et vérifiez soigneusement le code de gestion des erreurs.
Conclusion
Ce document doit être considéré comme un point de départ et non comme un ensemble exhaustif de méthodes et de pratiques. Encore une fois, nous tenons à noter que les documents présentés sont destinés à vous familiariser avec les bases du développement de logiciels sécurisés.Lors de la création d'un programme de sécurité d'application, nous vous recommandons d'effectuer les étapes suivantes:
La version complète de la traduction et l' original . Dans la traduction et l'adaptation ont participé: JZDLin , Alexey Skachkov , Ivan Kochurkin et Taras Ivashchenko .
Ce document a été publié sous la licence Creative Commons Attribution ShareAlike 3.0, traduit et adapté avec la participation de la branche russe du consortium OWASP .