novembre 2010

OWASP Sécuriser les pratiques de codage

Guide de référence rapide

Droit d'auteur et licence

Copyright © 2010 La Fondation OWASP.

Ce document est publié sous la licence Creative Commons Attribution 3.0. Pour toute réutilisation ou distribution, vous devez faire apparaître
clairement aux autres les conditions de licence de ce travail.
http://creativecommons.org/licenses/by-sa/3.0/

version 2.0 1
 novembre 2010

Table des matières

Introduction ................................................. ................................................. 3
Sécurité Logiciel et principes du risque Vue d'ensemble ............................................ . 4
Sécuriser les pratiques de codage Liste de contrôle .............................................. .................... 5
Validation Entrée: ............................................... ........................................... 5
Encodage de sortie: ............................................... .......................................... 5
Authentification et mot de passe de gestion: ............................................. ........ 6
Session de gestion: ............................................... ..................................... sept
Contrôle d'accès: ............................................... ............................................. 8
Pratiques: ............................................... Cryptographic ................................. 9
Gestion des erreurs et l'exploitation forestière: ............................................. ............................ 9
Protection des données:............................................... ............................................dix
Sécurité Communication: ............................................... ..............................dix
Configuration du système:............................................... ................................... 11
Base de données de sécurité: ............................................... ........................................ 11
Gestion de fichiers: ............................................... ......................................... 12
Gestion de la mémoire: ............................................... .................................. 12
Général de codification Pratiques: .............................................. ............................... 13
Annexe A: ............................................... .................................................. 14
Références externes: ............................................... ..................................... 14
Annexe B: Glossaire .............................................. ..................................... 15

version 2.0 2
 novembre 2010

introduction

Cette technologie agnostique le document définit un ensemble de sécurité logicielle générale les pratiques de codage, dans un format de liste de contrôle, qui peut
être intégré dans le cycle de vie du développement logiciel. La mise en œuvre de ces pratiques atténuera la plupart des vulnérabilités logicielles communes.

En général, il est beaucoup moins coûteux de construire des logiciels sûrs que les problèmes de sécurité correctes après que le logiciel a
été achevé, sans parler des coûts qui peuvent être associés à une atteinte à la sécurité.

Sécurisation des ressources logicielles critiques est plus important que jamais que l'attention des attaquants n'a cessé déplacé vers la couche d'application.
Une étude réalisée en 2009 Sans 1 ont constaté que les attaques contre les applications web représentent plus de 60% des tentatives d'attaque totales
observées sur Internet.

Lors de l'utilisation de ce guide, les équipes de développement devraient commencer par évaluer la maturité de leur cycle de vie du développement logiciel sécurisé
et le niveau de connaissances de leur personnel de développement. Étant donné que ce guide ne couvre pas les détails de la façon de mettre en œuvre chaque
pratique de codage, les développeurs devront soit avoir les connaissances ou disposer de ressources suffisantes qui fournissent les orientations nécessaires. Ce
guide fournit des pratiques de codage qui peuvent être traduites en exigences de codage sans qu'il soit nécessaire pour le développeur d'avoir une compréhension
approfondie des failles de sécurité et les exploits. Cependant, d'autres membres de l'équipe de développement devraient avoir la responsabilité, une formation
adéquate, des outils et des ressources nécessaires pour valider que la conception et la mise en œuvre du système complet est sécurisé.

Un glossaire des termes importants dans le présent document, y compris des titres et mots affichés dans italique, il est prévu dans l'appendice B.

Lignes directrices sur la mise en œuvre d'un cadre de développement de logiciels de sécurité est au-delà de la portée de cet article, mais les
pratiques et les ressources générales suivantes sont recommandées:

• Définir clairement les rôles et responsabilités ly

• Fournir aux équipes de développement ayant une formation de sécurité du logiciel adéquat

• Mettre en œuvre un cycle de vie de développement logiciel sécurisé

o OWASP projet COALITION

• Établir des normes de codage sécurisées

o Guide OWASP Projet de développement

• Construire une bibliothèque d'objets réutilisables

o OWASP API Enterprise Security Project (ESAPI)

• Vérifier l'efficacité des contrôles de sécurité

o OWASP application standard de vérification de sécurité (ASVS) Projet)

• Mettre en place des pratiques de développement externalisés sécurisés, y compris la définition des exigences de sécurité et les méthodes de
vérification à la fois la demande de propositions (DP) et le contrat.
o OWASP Projet juridique

version 2.0 3
 novembre 2010

Sécurité Logiciel et principes du risque Vue d'ensemble

Construire un logiciel sécurisé nécessite une compréhension de base des principes de sécurité. Même si un examen complet des
principes de sécurité dépasse le cadre de ce guide, un aperçu rapide est fourni.

L'objectif de la sécurité du logiciel est de maintenir la confidentialité , intégrité , et disponibilité des ressources d'information afin de permettre des
opérations commerciales réussies. Cet objectif est atteint grâce à la mise en œuvre de les contrôles de sécurité . Ce guide met l'accent sur les
contrôles techniques spécifiques circonstances atténuantes l'apparition d'un logiciel commun vulnérabilités . Bien que l'objectif principal est les
applications Web et leur infrastructure de soutien, la plupart des directives peuvent être appliquées à toute plate-forme de déploiement de logiciels.

Il est utile de comprendre ce qu'on entend par risque, afin de protéger l'entreprise contre les risques inacceptables liés à sa dépendance sur le logiciel. Le
risque est une combinaison de facteurs qui menacent la réussite de l'entreprise. Cela peut être décrit conceptuellement comme suit: a agent de menace coopère
avec un système , Qui peut avoir un vulnérabilité qui peut être exploité afin de provoquer une impact . Bien que cela puisse sembler un concept abstrait,
pensez de cette façon: un cambrioleur de voiture (agent de menace) passe par une voiture de contrôle beaucoup de stationnement (le système) pour les
portes non verrouillées (la vulnérabilité) et quand ils trouvent un, ils ouvrent la porte (l'exploit) et prendre tout ce qui est à l'intérieur (l'impact). Tous ces
facteurs jouent un rôle dans le développement de logiciels sécurisés.

Il y a une différence fondamentale entre l'approche adoptée par une équipe de développement et pris par quelqu'un d'attaquer une demande. Une
équipe de développement se rapproche généralement une application basée sur ce qu'il est censé faire. En d'autres termes, ils conçoivent une
application pour exécuter des tâches spécifiques en fonction des exigences fonctionnelles documentées et les cas d'utilisation. Un attaquant, d'autre
part, est plus intéressé par ce que la demande peut être faite à faire et fonctionne sur le principe selon lequel « toute action non expressément refusée,
est autorisé ». Pour y remédier, certains éléments supplémentaires doivent être intégrés dans les premières étapes du cycle de vie du logiciel. Ces
nouveaux éléments exigences de sécurité et cas d'abus . Ce guide est conçu pour aider à identifier les exigences de sécurité de haut niveau et compte
des nombreux scénarios d'abus communs.

Il est important pour les équipes de développement Web pour comprendre que les contrôles côté client comme la validation d'entrée en fonction du client, les
champs cachés et des contrôles d'interface (par exemple, démoraliser et boutons radio), offrent peu ou pas de prestation de sécurité. Un attaquant peut utiliser des
outils comme proxy Web côté client (par exemple OWASP WebScarab, Burp) ou des outils de capture de paquets réseau (par exemple, WireShark) pour analyser
le trafic des applications et soumettre des demandes construites sur mesure, sans passer par l'interface tous ensemble. En outre, Flash, Java Applets et autres
objets côté client peut être décompilé et analysé les défauts.

les failles de sécurité du logiciel peuvent être introduits à tout stade du cycle de vie de développement de logiciels, y compris:

• Ne pas identifier les exigences de sécurité à l'avant

• La création de modèles conceptuels qui ont des erreurs logiques

• L'utilisation de mauvaises pratiques de codage qui introduisent des vulnérabilités techniques

• Déploiement du logiciel mal
• Présentation de défauts lors de l'entretien ou la mise à jour

En outre, il est important de comprendre que les vulnérabilités logicielles peuvent avoir une portée au-delà du logiciel lui-même. En fonction
de la nature du logiciel, la vulnérabilité et l'infrastructure de soutien, les impacts d'une exploitation réussie peuvent inclure des compromis à
tout ou partie des éléments suivants:

• Le logiciel et les informations associées

• Les systèmes d'exploitation des serveurs associés
• La base de données back-end

• D'autres applications dans un environnement partagé

• Le système de l'utilisateur

• D'autres logiciels que l'utilisateur interagit avec

version 2.0 4
 novembre 2010

Sécuriser les pratiques de codage Liste de contrôle

Validation d'entrée:

• Effectuer toutes les validations de données sur un système de confiance (par exemple, le serveur)

• Identifier toutes les sources de données et les classer en confiance et non fiable. Valider toutes les données provenant de sources non fiables (par
exemple, les bases de données, flux fichiers, etc.)

• Il devrait y avoir une routine de validation d'entrée centralisé pour l'application

• Spécifiez ensembles de caractères appropriés, tels que UTF-8, pour toutes les sources d'entrée

• les données Encode à un jeu de caractères commun avant de valider ( canonicalize )

• Tous les échecs de validation devraient entraîner le rejet d'entrée

• Déterminer si le système prend en charge les jeux de caractères UTF-8 étendues et si oui, après décodage validate UTF-8 est terminée

• Valider tous les clients ont fourni des données avant le traitement, y compris tous les paramètres, les URL et le contenu en-tête HTTP (par
exemple, Cookie noms et valeurs). Assurez-vous d'inclure le dos post automatisé de JavaScript, Flash ou tout autre code intégré

• Vérifiez que les valeurs d'en-tête dans les deux demandes et les réponses ne contiennent que des caractères ASCII

• Valider les données de redirection (Un attaquant peut présenter un contenu malveillant directement à la cible de la redirection, contournant
ainsi la logique d'application et aucune validation effectuée avant la redirection)

• Valider pour les types de données attendus

• Valider plage de données

• Valider longueur de données

• Valider toutes les entrées sur une liste « blanche » de caractères autorisés, chaque fois que possible

• Si l'un potentiellement caractères dangereux doit être admis comme entrée, assurez-vous que vous mettre en œuvre des contrôles
supplémentaires comme l'encodage de sortie, des API spécifiques de tâches sécurisées et représente l'utilisation de ces données dans toute
l'application. Des exemples de caractères dangereux courants: <> " '% () et + \ \' \"

• Si votre routine de validation standard ne peut pas répondre aux entrées suivantes, alors ils devraient être contrôlés discrètement

o Vérifiez les octets nuls (% 00)

o Vérifiez les caractères de nouvelle ligne (% 0D% 0A,, \ r \ n)

o Vérifier « point-point-slash » (ou ../ .. \) chemin caractères altérations. Dans les cas où UTF-8 étendu
le jeu de caractères de codage est prise en charge, l'adresse représentation alternative comme:% c0% ae ae% c0% / (Utiliser canonicalisation
pour répondre à double codage ou d'autres formes d'obscurcissement attaques)

Encodage de sortie:

• Effectuer tous les encodages sur un système de confiance (par exemple, le serveur)

• Utiliser une routine standard, testé pour chaque type de codage sortant
• encode de sortie Contextuellement toutes les données retournées au client qui a pris naissance en dehors des applications de la limite la confiance . le
codage d'entité HTML est un exemple, mais ne fonctionne pas dans tous les cas

• Encodez tous les caractères à moins qu'ils sont connus pour être sans danger pour l'interprète prévu

• contextuellement désinfecter toutes les sorties de données non fiables aux requêtes pour SQL, XML et LDAP

• Désinfecter toutes les sorties de données non fiables à des commandes du système d'exploitation

version 2.0 5
 novembre 2010

Authentification et mot de passe de gestion:

• Exiger l'authentification pour toutes les pages et les ressources, à l'exception de ceux spécifiquement destinés à être publics

• Tous les contrôles d'authentification doivent être appliquées sur un système de confiance (par exemple, le serveur)

• Mettre en place et utiliser standard, testés, les services d'authentification à chaque fois que possible

• Utiliser une application centralisée pour tous les contrôles d'authentification, y compris les bibliothèques qui font appel des services d'authentification
externes

• la logique d'authentification de la ressource SÉGRÉGATION étant redirection demandée et l'utilisation de et du contrôle d'authentification
centralisée

• Tous les contrôles d'authentification doivent échouer en toute sécurité

• Toutes les fonctions de gestion administrative et compte doivent être au moins aussi sûr que le principal mécanisme
d'authentification

• Si votre application gère un magasin de crédit, il doit veiller à ce que seuls cryptographiquement forte hash salée unidirectionnels de mots de
passe sont stockés et que la table / fichier qui stocke les mots de passe et les clés est en écriture seule mesure par l'application. (Ne pas
utiliser l'algorithme MD5 si elle peut être évitée)

• hashage doit être mis en œuvre sur un système de confiance (par exemple, le serveur).

• Valider les données d'authentification uniquement à la fin de toutes les entrées de données, en particulier pour authentification séquentielle mises
en œuvre

• réponses d'échec d'authentification ne doivent pas indiquer quelle partie des données d'authentification était incorrecte. Par exemple, au lieu de «
nom d'utilisateur non valide » ou « Mot de passe incorrect », il suffit d'utiliser « nom d'utilisateur non valide et / ou mot de passe » pour les deux.
les réponses d'erreur doivent être vraiment identiques dans l'affichage et le code source

• Utiliser l'authentification des connexions à des systèmes externes qui impliquent des informations sensibles ou fonctions

• informations d'identification d'authentification pour l'accès aux services externes à l'application doivent être cryptés et stockés dans un emplacement
protégé sur un système de confiance (par exemple, le serveur). Le code source n'est pas un endroit sûr

• Utilisez uniquement des requêtes HTTP POST à ​des informations d'authentification de transmission

• Seuls les mots de passe envoyer des non temporaires sur une connexion chiffrée ou sous forme de données chiffrées, comme dans un e-mail crypté. les
mots de passe temporaires aux messages électroniques remet à zéro peut être une exception

• Faire respecter le mot de passe des exigences de complexité établies par la politique ou la réglementation. informations d'authentification devraient
être suffisantes pour résister aux attaques qui sont typiques des menaces dans l'environnement déployé. (Par exemple, ce qui nécessite l'utilisation
de l'alphabet ainsi que des caractères numériques et / ou spéciaux)

• Faire respecter les exigences de mot de passe longueur établies par la politique ou la réglementation. Huit caractères sont couramment
utilisés, mais 16 est mieux ou d'envisager l'utilisation de phrases de passe de plusieurs mots

• entrée de mot de passe doit être obscurci sur l'écran de l'utilisateur. (Par exemple, sur des formulaires Web utilisent le type d'entrée « password
»)

• Faire respecter compte après la désactivation d'un nombre déterminé de tentatives de connexion non valides (par exemple, cinq tentatives est
commune). Le compte doit être désactivé pour une période de temps suffisante pour décourager la force brutale de deviner des pouvoirs, mais pas aussi
longtemps que pour permettre une attaque par déni de service à effectuer

• Mot de passe remis à zéro et les opérations de changement exigent le même niveau de contrôle que la création de compte et l'authentification.

• les questions de réinitialisation de mot de passe doivent supporter des réponses suffisamment aléatoires. (Par exemple, « livre préféré » est une
mauvaise question parce que « La Bible » est une réponse très courante)

• Si vous utilisez remet à zéro en fonction e-mail, email envoyer uniquement à une adresse enregistrée avant avec un lien temporaire /
mot de passe

• les mots de passe temporaires et les liens doivent avoir un court laps de temps d'expiration

• Faire appliquer le changement des mots de passe temporaires sur la prochaine utilisation

version 2.0 6
 novembre 2010

• Informer les utilisateurs de réinitialisation de mot de passe se produit

• Empêcher un mot de passe réutilisation

• Les mots de passe doivent être au moins d'un jour avant de pouvoir être modifiés, pour prévenir les attaques sur le mot de passe réutilisation

• Faire appliquer les changements de mot de passe en fonction des exigences établies dans la politique ou la réglementation. Les systèmes critiques
peuvent nécessiter des changements plus fréquents. Le temps entre les réinitialisations doit être contrôlé sur le plan administratif

• Désactiver la fonctionnalité « remember me » pour les champs de mot de passe

• La dernière utilisation (réussi ou non) d'un compte d'utilisateur doit être signalé à l'utilisateur lors de leur prochaine connexion réussie

• Mettre en œuvre le suivi pour identifier les attaques contre plusieurs comptes d'utilisateurs, en utilisant le même mot de passe. Ce modèle d'attaque est
utilisé pour contourner les verrouillages standard, lorsque les ID utilisateur peuvent être récoltées ou devinées

• Changer tous les mots de passe par défaut fournis par les fournisseurs et les ID utilisateur ou désactiver les comptes associés

• Les utilisateurs réauthentifier avant d'effectuer des opérations critiques

• Utilisation Multi-facteurs d'authentification pour les comptes transactionnels très sensibles ou à forte valeur ajoutée

• Si vous utilisez le code tiers pour l'authentification, inspectez soigneusement le code pour assurer qu'il est pas affecté par un code malveillant

Session de gestion:
• Utilisez le serveur ou les contrôles de gestion de session cadres. L'application ne doit reconnaître ces identifiants de session comme
valides

• Session de création d'identifiant doit toujours être fait sur un système de confiance (par exemple, le serveur)

• les contrôles de gestion de session doivent utiliser des algorithmes qui garantissent bien soumis à une sélection des identifiants de session
suffisamment aléatoires

• Définir le domaine et le chemin pour les cookies contenant des identifiants de session authentifiées à une valeur appropriée restreinte pour le
site

• fonctionnalité Déconnexion devrait mettre fin à la session pleinement associée ou connexion

• fonctionnalité de déconnexion devrait être disponible à partir de toutes les pages protégées par autorisation

• Mettre en place un délai d'inactivité de session qui est aussi courte que possible, en fonction des risques et équilibre entre les exigences fonctionnelles
affaires. Dans la plupart des cas, il ne devrait pas dépasser plusieurs heures

• Connexions persistantes et Disallow appliquer les terminaisons de session périodiques, même lorsque la session est active. En particulier pour les
applications supportant des connexions de réseau riches ou la connexion à des systèmes critiques. temps de résiliation doivent répondre aux
exigences d'affaires et l'utilisateur doivent recevoir une notification suffisante pour atténuer les effets négatifs de

• Si une session a été créé avant la connexion, à proximité de cette session et d'établir une nouvelle session après une connexion réussie

• Générer un nouvel identifiant de session sur une ré-authentification

• Ne pas autoriser les connexions simultanées avec le même ID utilisateur

• Ne pas exposer les identifiants de session dans les URL, les messages d'erreur ou les journaux. identifiants de session ne doivent être situés dans
l'en-tête de cookie HTTP. Par exemple, ne passent pas des identifiants de session en tant que paramètres GET

• les données de session Protéger côté serveur d'accès non autorisé, par d'autres utilisateurs du serveur, en mettant en place des
contrôles d'accès appropriés sur le serveur

• Générer un nouvel identifiant de session et de désactiver l'ancien périodiquement. (Cela peut atténuer certains scénarios de
Détournement de session où l'original identif ier a été compromise)

• Générer un nouvel identifiant de session si la sécurité de connexion passe de HTTP vers HTTPS, qui peut se produire lors de
l'authentification. Au sein d'une application, il est recommandé d'utiliser systématiquement plutôt que HTTPS commutation entre HTTP vers
HTTPS.

version 2.0 sept

 novembre 2010

• Supplément de gestion de session standard pour les opérations côté serveur sensibles, comme la gestion des comptes, en utilisant des jetons
forts au hasard par session ou paramètres. Cette méthode peut être utilisée pour empêcher Cross Site Request Forgery attaques

• Supplément de gestion de session standard pour les opérations très sensibles ou critiques en utilisant perrequest, par opposition à par
session, jetons forts aléatoires ou des paramètres

• Définissez l'attribut « sécurisé » pour les cookies transmis via une connexion TLS

• Placer des cookies avec l'attribut HttpOnly, sauf si vous avez besoin spécifiquement des scripts côté client dans votre application pour lire ou définir la
valeur d'un cookie

Contrôle d'accès:

• Utilisez uniquement des objets du système de confiance, par exemple des objets de session côté serveur, pour prendre des décisions
d'autorisation d'accès

• Utilisez un seul composant l'ensemble du site pour vérifier l'autorisation d'accès. Cela inclut les bibliothèques qui font appel des services
d'autorisation externes

• Les contrôles d'accès doivent échouer en toute sécurité

• Refuser tous les accès si l'application ne peut pas accéder à ses informations de configuration de sécurité

• Faire respecter les contrôles d'autorisation à chaque demande, y compris celles qui sont faites par des scripts côté serveur, « comprend » et
les demandes des riches technologies côté client comme AJAX et Flash

• logique privilégié séparer de tout autre code d'application

• Restreindre l'accès aux fichiers ou d'autres ressources, y compris celles échappant au contrôle direct, aux seuls utilisateurs autorisés de l'application

• Restreindre l'accès aux URL protégées aux seuls utilisateurs autorisés

• Limiter l'accès aux fonctions protégées aux seuls utilisateurs autorisés

• Restreindre les références d'objets directs aux seuls utilisateurs autorisés

• Restreindre l'accès aux services aux utilisateurs autorisés

• Limiter l'accès aux données d'application aux seuls utilisateurs autorisés

• Limiter l'accès aux attributs utilisateur et des données et des informations sur les politiques utilisées par les contrôles d'accès

• Limiter l'accès des informations de configuration relatives à la sécurité aux seuls utilisateurs autorisés

• représentations de mise en œuvre du côté serveur et la couche de présentation des règles de contrôle d'accès doivent correspondre

• Si données d'état doivent être stockés sur le client, utiliser de contrôle de chiffrement et de l'intégrité du côté du serveur à l'état de capture falsification.

• Faire appliquer la logique d'application des flux de se conformer aux règles commerciales

• Limiter le nombre de transactions un seul utilisateur ou appareil peut effectuer dans une période de temps donnée. Les opérations / heure doit être
au-dessus de l'exigence commerciale réelle, mais suffisamment faible pour décourager les attaques automatisées

• Utilisez l'en-tête « referer » comme un chèque supplémentaire seulement, il ne devrait jamais être le seul contrôle d'autorisation, car il est peut être usurpée

• Si les longues sessions sont autorisées authentifiées, revalider régulièrement l'autorisation d'un utilisateur de veiller à ce que leurs privilèges ont
pas changé et si elles ont, connectez-vous à l'utilisateur et de les forcer à réauthentifier

• Mettre en œuvre la vérification des comptes et de faire appliquer la désactivation des comptes non utilisés (par exemple, après pas plus de 30 jours à
compter de l'expiration du mot de passe d'un compte.)

• L'application doit prendre en charge la désactivation des comptes et mettre fin aux sessions d'autorisation lorsque cesse (par exemple, les
modifications au rôle, le statut de l'emploi, des processus d'affaires, etc.)

• Les comptes de service ou des comptes de soutien ou de connexions à des systèmes externes devraient avoir le moindre privilège possible

version 2.0 8
 novembre 2010

• Créer une politique de contrôle d'accès pour documenter les règles métier d'une application, les types de données et les critères d'autorisation d'accès
et / ou processus afin que l'accès peut être correctement provisionné et contrôlé. Cela comprend l'identification des conditions d'accès pour les
données et les ressources du système

Pratiques cryptographiques:

• Toutes les fonctions cryptographiques utilisées pour les secrets de l'utilisateur protègent d'application doivent être mises en œuvre sur un système de
confiance (par exemple, le serveur)

• Protéger les secrets des maîtres de l'accès non autorisé

• Les modules cryptographiques doivent échouer en toute sécurité

• Tous les nombres aléatoires, les noms de fichiers aléatoires, au hasard, et GUIDs des chaînes aléatoires devraient être générés en utilisant le générateur
de nombres aléatoires approuvé du module cryptographique lorsque ces valeurs aléatoires sont destinées à être non devinables

• modules cryptographiques utilisées par l'application doivent être conformes à la norme FIPS 140-2 ou une norme équivalente. (Voir http://csrc.nist.gov/groups/S
)

• Mettre en place et utiliser une politique et le processus de la façon dont les clés de chiffrement seront gérées

Gestion des erreurs et l'exploitation forestière:

• Ne pas divulguer des informations sensibles dans les réponses d'erreur, y compris les détails du système, des identifiants de session ou des
informations de compte

• Utiliser des gestionnaires d'erreurs qui ne présente pas les informations de débogage ou trace de la pile

• Mettre en œuvre des messages d'erreur génériques et l'utilisation des pages d'erreur personnalisées

• L'application doit gérer les erreurs d'application et ne pas compter sur la configuration du serveur

• correctement la mémoire allouée gratuite en cas d'erreur se produisent

• Erreur logique de gestion associée à des contrôles de sécurité doit refuser l'accès par défaut

• Tous les contrôles de l'exploitation forestière devraient être mis en œuvre sur un système de confiance (par exemple, le serveur)

• contrôle la journalisation devrait soutenir à la fois le succès et l'échec des événements de sécurité spécifiés

• Assurez-vous les journaux contiennent d'importantes enregistrer les données d'événements

• Assurez-vous les entrées du journal qui incluent des données non fiables ne seront pas exécutés code dans le journal prévu l'interface de
visualisation ou d'un logiciel

• Restreindre l'accès aux journaux seulement aux personnes autorisées

• Utiliser une routine principale pour toutes les opérations d'exploitation forestière

• Ne pas stocker des informations sensibles dans les journaux, y compris les détails du système inutiles, des identifiants de session ou les mots de passe

• Assurez-vous qu'il existe un mécanisme pour effectuer une analyse du journal

• Consigner tous les échecs de validation d'entrée

• Se connecter toutes les tentatives d'authentification, en particulier les échecs

• Connectez-vous toutes les défaillances de contrôle d'accès

• Que tous les événements apparents trafiquage, y compris des changements inattendus aux données d'état

• Connectez-vous tente de se connecter avec des jetons de session non valides ou périmés

• Se connecter toutes les exceptions du système

• Connectez-vous toutes les fonctions administratives, y compris les modifications apportées aux paramètres de configuration de sécurité

• Consigner tous les échecs de connexion backend TLS

• Se connecter échecs module cryptographique

• Utilisez une fonction de hachage cryptographique pour valider l'intégrité d'entrée de journal

version 2.0 9
 novembre 2010

Protection des données:

• Mettre en œuvre le moindre privilège, limiter les utilisateurs à uniquement les informations, les données et la fonctionnalité système qui est nécessaire
pour accomplir leurs tâches

• Protéger toutes les copies mises en cache ou temporaires de données sensibles stockées sur le serveur d'un accès non autorisé et purger les
fichiers de travail temporaire a dès qu'ils ne sont plus nécessaires.

• Chiffrer informations stockées très sensibles, comme les données de vérification d'authentification, même sur le côté serveur. Toujours utiliser des
algorithmes bien soumis à une sélection, consultez la section « Cryptographic » pour des directives supplémentaires

• code source de protection du côté du serveur d'être téléchargé par un utilisateur

• Ne pas stocker les mots de passe, les chaînes de connexion ou d'autres informations sensibles en clair ou de quelque manière que
noncryptographically sûr du côté client. Cela inclut l'intégration dans des formats non sécurisés tels que: MS viewstate, Adobe flash ou un code
compilé

• Supprimer les commentaires dans le code de production accessible par l'utilisateur qui peut révéler système back-end ou d'autres informations
sensibles

• Supprimer l'application inutile et la documentation du système, car cela peut révéler des informations utiles aux attaquants

• Ne pas inclure des informations sensibles dans les paramètres de requête HTTP GET

• Désactiver les fonctionnalités complètes automatiques sur les formulaires devraient contenir des informations sensibles, y compris
l'authentification

• Désactiver la mise en cache côté client sur des pages contenant des informations sensibles. Cache-Control: no-store, peut être utilisé en
conjonction avec le contrôle d'en-tête HTTP "Pragma: no-cache", ce qui est moins efficace, mais est HTTP / 1.0 rétrocompatible

• L'application devrait soutenir la suppression des données sensibles lorsque ces données ne sont plus nécessaires. (Par exemple, des informations
personnelles ou certaines données financières)

• Mettre en œuvre des contrôles d'accès appropriés pour les données sensibles stockées sur le serveur. Cela inclut les données mises en cache, les
fichiers temporaires et les données qui doivent être accessibles que par les utilisateurs du système spécifiques

Sécurité Communication:
• Mettre en œuvre le cryptage pour la transmission de toutes les informations sensibles. Cela devrait inclure TLS pour protéger la
connexion et peut être complété par un cryptage discret de fichiers sensibles ou des connexions à base nonHTTP

• certificats TLS doit être valide et le nom de domaine correct, pas expiré, et être installés avec des certificats
intermédiaires en cas de besoin
• connexions défaillantes TLS ne devrait pas revenir à une connexion non sécurisée

• Utiliser les connexions TLS pour tous les contenus nécessitant un accès authentifié et pour toutes les autres informations sensibles

• Utiliser TLS pour les connexions aux systèmes externes qui impliquent des informations sensibles ou fonctions

• Utiliser une seule implémentation standard de TLS qui est configuré de manière appropriée

• Spécifiez codages de caractères pour toutes les connexions

• paramètres de filtre contenant des informations sensibles à partir du référent HTTP, lors de la liaison à des sites extérieurs

version 2.0 dix

 novembre 2010

Configuration du système:

• Assurez-vous des serveurs, des cadres et des composants du système sont en cours d'exécution de la dernière version approuvée

• Assurez-vous des serveurs, des cadres et des composants du système ont tous les correctifs émis pour la version en cours d'utilisation

• Désactiver le listes d'annuaire

• Restreindre le serveur Web, le processus et le service des comptes aux moins de privilèges possibles

• Lorsque des exceptions se produisent, ne parviennent en toute sécurité

• Supprimer toutes les fonctionnalités inutiles et les fichiers

• Supprimer le code de test ou d'une fonctionnalité non destinés à la production, avant le déploiement

• divulgation Empêcher la structure de votre répertoire dans le fichier robots.txt en plaçant des répertoires non destinés à l'indexation du
public dans un répertoire parent isolé. Puis « Disallow » que répertoire parent entier dans le fichier robots.txt plutôt que chaque répertoire
individuel Interdire

• Définir les méthodes HTTP, GET ou POST, l'application soutiendra et si elle sera traitée différemment dans les différentes
pages de l'application
• Désactiver les méthodes HTTP inutiles, tels que les extensions WebDAV. Si une méthode HTTP étendue qui supporte la gestion de fichiers est
nécessaire, utiliser un mécanisme d'authentification bien Info brute

• Si les poignées de serveur Web à la fois HTTP 1.0 et 1.1, assurez-vous que les deux sont configurés dans un manoir similaire ou vous assurer que vous
comprenez toute différence qui peut exister (par exemple la manipulation des méthodes HTTP étendues)

• Supprimer les informations inutiles des en-têtes de réponse HTTP liées aux OS, la version serveur web et l'application des
cadres

• Le magasin de configuration de sécurité pour l'application devrait pouvoir être émis sous forme lisible par l'homme à l'audit de soutien

• Mettre en œuvre un système de gestion d'actifs et d'enregistrer les composants du système et des logiciels dans ce

• Isoler les environnements de développement du réseau de production et offrent un accès uniquement aux groupes de développement et de test autorisés.
Les environnements de développement sont souvent configurées moins sécurisée que les environnements de production et les attaquants peuvent utiliser
cette différence pour découvrir les faiblesses partagées ou comme un moyen d'exploitation

• Mettre en place un système de contrôle de changement de logiciel pour gérer et enregistrer des modifications au code à la fois dans le
développement et la production

Sécurité de base de données:

• Utilisez fortement typé requêtes paramétrées

• Utiliser la validation d'entrée et l'encodage de sortie et assurez-vous adresse des caractères meta. Si ceux-ci échouent, ne pas exécuter la commande
de base de données

• Assurez-vous que les variables sont fortement typés

• L'application doit utiliser le niveau le plus bas de privilège possible lors de l'accès à la base de données

• Identifiants sécurisés pour l'accès base de données

• Les chaînes de connexion ne doivent pas être codées en dur dans l'application. Les chaînes de connexion doivent être stockés dans un fichier de
configuration séparé sur un système de confiance et ils doivent être chiffrés.

• Utilisez des procédures stockées pour l'accès aux données abstrait et permettre le retrait des autorisations aux tables de base dans la base
de données

• Fermez la connexion le plus tôt possible

• Supprimer ou modifier les mots de passe d'administration de base de données par défaut. Utiliser des mots de passe / phrases ou mettre en œuvre
l'authentification multi-facteurs

• Désactivez toutes les fonctionnalités de base de données inutiles (par exemple, les procédures ou services inutiles stockés, les paquets utilitaires, installer
uniquement l'ensemble minimal de fonctionnalités et d'options nécessaires (réduction de la surface))

version 2.0 11
 novembre 2010

• Supprimer le contenu du fournisseur par défaut inutiles (par exemple, les schémas d'échantillons)

• Désactivez tous les comptes par défaut qui ne sont pas nécessaires pour répondre aux besoins d'affaires

• L'application doit se connecter à la base de données avec des informations d'identification différentes pour chaque distinction de confiance (par
exemple, l'utilisateur, l'utilisateur en lecture seule, invité, administrateurs)

Gestion de fichiers:

• Ne laissez pas les données fournies par l'utilisateur directement à une dynamique fonction include

• Exiger l'authentification avant d'autoriser un téléchargement de fichier

• Limiter le type de fichiers qui peuvent être téléchargés sur uniquement les types qui sont nécessaires à des fins commerciales

• Valider les fichiers téléchargés sont le type prévu en vérifiant les en-têtes de fichier. Vérification de type de fichier par extension seule ne
suffit pas

• Ne pas enregistrer les fichiers dans le même contexte que l'application Web. Fichiers soit devrait aller au serveur de contenu ou dans la base de
données.

• Prévenir ou limiter le téléchargement de tout fichier qui peut être interprété par le serveur web.

• Désactivez les privilèges d'exécution sur les répertoires de téléchargement de fichiers

• Mettre en œuvre sous UNIX L'ajout de sécurité en installant le répertoire du fichier ciblé comme un lecteur logique en utilisant le chemin associé ou
l'environnement chroot

• Lorsque vous faites référence les fichiers existants, utilisez une liste blanche des noms de fichiers autorisés et les types. Valider la valeur du paramètre
passé et si elle ne correspond pas à l'une des valeurs attendues, soit la rejeter ou utiliser une valeur de fichier par défaut codé en dur pour le contenu à la
place

• Ne pas transmettre des données fournies par l'utilisateur dans une redirection dynamique. Si cela doit être pris, alors la redirection ne doit
accepter que valider, URL de chemin relatif

• Ne pas passer les chemins de répertoire ou un fichier, les valeurs d'index d'utilisation mis en correspondance avec la liste prédéfinie des chemins

• Ne jamais envoyer le chemin de fichier absolu au client

• Assurer que les fichiers d'application et les ressources sont en lecture seule

• utilisateur analyse les fichiers téléchargés pour les virus et les logiciels malveillants

Gestion de la mémoire:

• Utiliser commande d'entrée et de sortie pour des données non fiables

• Vérifier que le tampon est aussi grande que spécifié

• Lorsque vous utilisez les fonctions qui acceptent un certain nombre d'octets à copier, comme strncpy (), sachez que si la taille du tampon de
destination est égale à la taille de la mémoire tampon source, il ne peut pas NULL mettre fin à la chaîne

• Vérifier le tampon de limites si vous appelez la fonction dans une boucle et assurez-vous qu'il n'y a aucun danger de ition wr passé l'espace alloué

• Tronquer toutes les chaînes d'entrée à une longueur raisonnable avant de les transmettre aux fonctions de copie et de concaténation

• Plus précisément les ressources proches, ne reposent pas sur la collecte des ordures. (Par exemple, les objets de connexion, poignées de fichiers, etc.)

• Utilisez des piles non exécutables lorsqu'ils sont disponibles

• Évitez l'utilisation des fonctions vulnérables connues (par exemple, printf, strcat, strcpy etc.)

• Bien mémoire allouée libre à l'accomplissement des fonctions et à tous les points de sortie

version 2.0 12
 novembre 2010

Pratiques générales de codage:

• Utilisez le code managé testé et approuvé plutôt que de créer un nouveau code non managé pour les tâches courantes

• Utiliser intégré spécifique de tâches API pour exécuter des tâches de système d'exploitation. Ne laissez pas l'application d'émettre des commandes
directement au système d'exploitation, en particulier par l'utilisation de coquilles de commande lancé d'application

• Utilisez checksums ou hash pour vérifier l'intégrité du code interprété, les bibliothèques, les exécutables et les fichiers de configuration

• Utiliser de verrouillage pour empêcher de multiples demandes simultanées ou utiliser un mécanisme de synchronisation pour éviter les conditions
de course

• Protéger les variables et les ressources partagées d'un accès simultané inappropriée

• initialiser Explicitement toutes vos variables et d'autres magasins de données, que ce soit au cours de déclaration ou juste avant la première utilisation

• Dans les cas où l'application doit être exécutée avec des privilèges élevés, des privilèges soulèvent le plus tard possible, et de les déposer le plus
tôt possible

• Évitez les erreurs de calcul par la compréhension représentation sous-jacente de votre langage de programmation et la façon dont elle interagit
avec le calcul numérique. Portez une attention particulière aux différences de taille des octets, précision, signés / distinctions non signées,
troncature, conversion et coulée entre types, « non un nombre » calculs et comment vos poignées de langue des chiffres qui sont trop grands ou
trop petits pour sa représentation sous-jacente

• Ne pas transmettre des données fournies par l'utilisateur à une fonction d'exécution dynamique

• Empêcher les utilisateurs de générer un nouveau code ou modifier le code existant

• Passez en revue toutes les applications secondaires, le code tiers et les bibliothèques afin de déterminer la nécessité d'affaires et de valider la
fonctionnalité en toute sécurité, car ils peuvent introduire de nouvelles vulnérabilités

• Mettre en œuvre la mise à jour de sécurité. Si l'application utilisera les mises à jour automatiques, puis utilisez les signatures cryptographiques pour
votre code et vous assurer que vos clients de téléchargement vérifier ces signatures. Utiliser les canaux cryptés pour transférer le code du serveur
hôte

version 2.0 13
 novembre 2010

Annexe A:

Références externes:
1. Référence citée
Sans et TippingPoint « Les risques de sécurité Top Cyber ​»
http://www.sans.org/top-cyber-security-risks/

• Consortium Web Application Security

http://www.webappsec.org/

• La faiblesse commune Enumeration (CWE)

http://cwe.mitre.org/

• Département de la sécurité intérieure Construire la

sécurité dans le portail
https://buildsecurityin.us-cert.gov/daisy/bsi/home.htm l

• Cert codage sécurisé

http://www.cert.org/secure-coding/

• Sécurité MSDN Developer Center

http://msdn.microsoft.com/en-us/security/default.aspx

• Cheat Sheet SQL Injection

http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/

• Cross Site Scripting (XSS) Cheat Sheet

http://ha.ckers.org/xss.html

Sites consultatif sur la sécurité:

Ressources utiles pour vérifier les vulnérabilités connues contre l'infrastructure de soutien et des cadres

Secunia Citrix Liste de vulnérabilité:

• http://secunia.com/advisories/search/?search=citrix

Vulnérabilité Security Focus Recherche:

• http://www.securityfocus.com/vulnerabilities

Open Source Vulnerability Database (OSVDB):

• http://osvdb.org/search/web_vuln_search

Vulnérabilité commune Enumeration:

• http://www.cve.mitre.org/

version 2.0 14
 novembre 2010

Annexe B: Glossaire

Cas abus: Décrit les mésusages intentionnelles et non intentionnelles du logiciel. les cas de violence devraient remettre en question les hypothèses de
la conception du système.

Contrôle d'accès: Un ensemble de contrôles qui accordent ou dénier à un utilisateur ou une autre entité, l'accès à une ressource système. Ceci est généralement
basé sur des rôles hiérarchiques et privilèges individuels dans un rôle, mais comprend également le système d'interactions du système.

Authentification: Un ensemble de contrôles qui sont utilisés pour vérifier l'identité d'un utilisateur, ou une autre entité, en interaction avec le logiciel.

Disponibilité: Une mesure de l'accessibilité et la facilité d'utilisation d'un système.

canoniser: Pour réduire divers codages et les représentations de données à une seule forme simple.

Sécurité Communication: Un ensemble de contrôles qui permettent d'assurer les poignées de logiciels l'envoi et la réception d'informations de manière
sécurisée.

Confidentialité: Pour veiller à ce que l'information est divulguée uniquement aux parties autorisées.

Encodage de sortie contextuelle: L'encodage des données de sortie en fonction de la façon dont il sera utilisé par l'application. Les méthodes spécifiques varient
en fonction de la façon dont les données de sortie est utilisée. Si les données doivent être inclus dans la réponse au client, compte des scénarios d'inclusion
comme: le corps d'un document HTML, un attribut HTML, dans JavaScript, CSS dans un ou dans une URL. Vous devez également tenir compte d'autres cas
d'utilisation comme des requêtes SQL, XML et LDAP.

Cross Site Request Forgery: Une des forces de site Web ou une application externe d'un client pour faire une demande non intentionnelle à une autre
application que le client a une session active avec. Les applications sont vulnérables lorsqu'ils utilisent connus ou prévisibles, les URL et les paramètres;
et lorsque le navigateur transmet automatiquement toutes les informations de session nécessaires à chaque demande à l'application vulnérable. (Ceci est
l'une des seules attaques spécifiquement abordées dans le présent document et est inclus uniquement parce que la vulnérabilité associée est très
fréquente et mal compris.)

Pratiques cryptographiques: Un ensemble de commandes qui assurent les opérations de chiffrement dans l'application sont traités en toute sécurité.

Protection des données: Un ensemble de contrôles qui permettent d'assurer le logiciel gère le stockage d'informations de manière sécurisée.

Sécurité de base de données: Un ensemble de commandes qui assurent qui interagit de logiciel avec une base de données d'une manière sécurisée, et que la
base de données est configuré en toute sécurité.

Gestion des erreurs et l'exploitation forestière: Un ensemble de pratiques qui assurent les poignées d'application des erreurs en toute sécurité et la
journalisation des événements conduits approprié.

Exploit: Pour profiter d'une vulnérabilité. Typiquement, cela est une action intentionnelle visant à compromettre les contrôles de sécurité du
logiciel en tirant parti d'une vulnérabilité.

Gestion de fichiers: Un ensemble de contrôles qui couvrent l'interaction entre le code et d'autres fichiers système.

version 2.0 15
 novembre 2010

Pratiques générales de codage: Un ensemble de contrôles qui couvrent les pratiques de codage qui ne rentrent pas facilement dans d'autres catégories.

Caractère dangereux: Tout caractère ou représentation codée d'un caractère qui peut effectuer l'opération prévue de l'application ou le système
associé en étant interprété comme ayant une signification particulière, en dehors de l'utilisation prévue du caractère. Ces caractères peuvent être
utilisés pour:
• Modifier la structure du code existant ou déclarations
• Insertion d'un nouveau code involontaire
• chemins altérant
• Causer des résultats inattendus des fonctions du programme ou des routines
• Causer des conditions d'erreur
• Avoir l'un des effets ci-dessus sur le bas des applications ou des systèmes flux

Entité HTML Encode: Le processus de remplacement de certains caractères ASCII avec leurs équivalents d'entité HTML. Par exemple, l'encodage
remplacerait moins que le caractère « < » avec l'équivalent HTML « & lt; ». entités HTML sont « inertes » dans la plupart des interprètes, en particulier
les navigateurs, qui peuvent atténuer certaines attaques côté client.

Impact: Une mesure de l'effet négatif de l'entreprise qui résulte de la survenance d'un événement indésirable; quel serait le
résultat d'une vulnérabilité soit exploitée.

Validation d'entrée: Un ensemble de contrôles qui vérifient les propriétés de tous les matches de données d'entrée ce qui est attendu par l'application, y compris
les types, longueurs, plages, jeux de caractères acceptables et ne comprend pas connus des caractères dangereux.

Intégrité: L'assurance que l'information est exacte, complète et valide, et n'a pas été modifié par une action non autorisée.

Les données du journal de l'événement: Cela devrait comprendre les éléments suivants:
1. Horodatage d'un composant système de confiance
2. Degré de gravité pour chaque événement
3. Tagging de sécurité des événements pertinents, si elles sont mélangées avec d'autres entrées du journal
4. Identité du compte / utilisateur qui a provoqué l'événement
5. Adresse IP source associée à la demande
6. Résultat de l'événement (succès ou échec)
7. Description de l'événement

Gestion de la mémoire: Un ensemble de commandes que la mémoire d'adresses et l'utilisation du tampon.

Atténuer: Les mesures prises pour réduire la gravité d'une vulnérabilité. Ceux-ci peuvent inclure la suppression d'une vulnérabilité, ce qui rend une
vulnérabilité plus difficile à exploiter, ou réduire l'impact négatif d'une exploitation réussie.

Multi-facteurs d'authentification: Un processus d'authentification qui demande à l'utilisateur de produire plusieurs types distincts d'informations d'identification.
Typiquement, cela repose sur quelque chose qu'ils ont (par exemple, carte à puce), quelque chose qu'ils savent (par exemple, une broche), ou quelque chose qu'ils
sont (par exemple, les données d'un lecteur biométrique).

Encodage de sortie: Un ensemble de commandes d'adressage l'utilisation de codage pour assurer une sortie de données par l'application est en sécurité.

Requêtes paramétrées (Statements préparés): Conserve la requête et des données séparées par l'utilisation d'espaces réservés. La structure de requête
est définie par les détenteurs de place, l'instruction SQL est envoyée à la base de données et préparé, puis la déclaration préparée est combinée avec les
valeurs des paramètres. Les requêtes empêche la

version 2.0 16
 novembre 2010

d'être modifié, car les valeurs des paramètres sont associés à la déclaration compilé, pas une chaîne SQL.

Désinfecter données: Le processus de mise en sécurité des données potentiellement nuisibles grâce à l'utilisation de la suppression des données, le
remplacement, encodage ou fuite des personnages.

Contrôles de sécurité: Une action qui atténue une vulnérabilité potentielle et aide à faire en sorte que le logiciel se comporte uniquement de la
manière attendue.

Exigences de sécurité: Un ensemble de conception et les exigences fonctionnelles qui permettent d'assurer le logiciel est construit et déployé de manière
sécurisée.

Authentification séquentielle: Lorsque les données d'authentification est demandée sur les pages successives plutôt que d'être demandé à la fois sur une
seule page.

Session de gestion: Un ensemble de contrôles qui permettent d'assurer des applications Web de gestion des sessions HTTP de manière sécurisée.

État des données: Lorsque des données ou des paramètres sont utilisés, par l'application ou un serveur, pour émuler une connexion persistante ou
suivre l'état d'un client à travers un processus multi-demande ou de la transaction.

Système: Un terme générique couvrant les systèmes d'exploitation, serveur Web, les cadres d'application et de l'infrastructure.

Configuration du système: Un ensemble de contrôles qui permettent d'assurer les composants d'infrastructure supportant le logiciel sont déployés en toute
sécurité.

Agent des menaces: Toute entité qui peut avoir un impact négatif sur le système. Cela peut être un utilisateur malveillant qui veut compromettre les contrôles
de sécurité du système; cependant, il pourrait aussi être un mauvais usage accidentel du système ou une menace plus physique comme le feu ou une
inondation.

Limites confiance: Généralement, une limite de confiance constitue les composantes du système sous votre contrôle direct. Toutes les
connexions et les données des systèmes hors de votre contrôle direct, y compris tous les clients et les systèmes gérés par d'autres parties,
devraient être considérer non fiable et validée à la limite, avant de permettre une interaction plus du système.

Vulnérabilité: Une faiblesse qui rend le système vulnérable aux attaques ou des dommages.

version 2.0 17