Exigences [PDF]

Zitiervorschau

´curisez une application du SI Projet n°4 : Se

Exigences de s´ecurit´e pour l’application

R´edige par Joachim Techtache

Table des mati` eres 1 Introduction

3

2 Liste des exigences de s´ ecurit´ e 2.1 S´ecuriser l’authentification des utilisateurs . . . . . . 2.1.1 Protocole de chiffrement des communications . 2.1.2 Forcer l’utilisation de HTTPS . . . . . . . . . 2.2 S´ecuriser les manipulations en base de donn´ees . . . . 2.2.1 Requˆetes SQL pr´epar´ees . . . . . . . . . . . . 2.3 Prot´eger le stockage des informations sensibles . . . . 2.3.1 Fonction de hachage cryptographique . . . . . 2.3.2 M´ethode de salage cryptographique . . . . . . 2.4 S´ecuriser l’interface utilisateur . . . . . . . . . . . . . 2.4.1 Validation des donn´ees en entr´ee . . . . . . . 2.4.2 Encodage des donn´ees en sortie . . . . . . . . 2.5 S´ecuriser l’interface de commande . . . . . . . . . . . 2.5.1 Production des identifiant d’acc`es uniques . . 2.5.2 Transmission des identifiant d’acc`es uniques . 2.5.3 Validation des identifiant d’acc`es uniques . . . 2.6 S´ecuriser la configuration des serveurs . . . . . . . . . 2.6.1 D´esactivation du listage des r´epertoires . . . . 2.6.2 Personnalisation des messages d’erreurs . . . .

Page 2

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

4 4 4 4 5 5 6 6 6 7 7 7 8 8 8 8 9 9 9

1

Introduction

De nous jours, la s´ecurit´e des applications est devenu beaucoup plus importante, car les applications d’aujourd’hui sont souvent disponibles sur divers r´eseaux et connect´ees au Cloud, ce qui augmente leur vuln´erabilit´e aux menaces et aux violations de s´ecurit´e. On constate de plus en plus de pression et d’incitations a` ne pas uniquement garantir la s´ecurit´e au niveau du r´eseau, mais ´egalement au sein des applications elles-mˆemes. L’une des raisons a` cela est le fait que les attaquants s’attaquent davantage aux applications que par le pass´e. Les tests de s´ecurit´e des applications peuvent r´ev´eler les d´efauts au niveau des applications, afin d’empˆecher ces attaques. La s´ecurit´e des applications n’est pas une technologie individuelle en soi, il s’agit plutˆot d’un ensemble de bonnes pratiques, de fonctions ou de caract´eristiques venant s’ajouter aux logiciels de l’entreprise pour aider a` pr´evenir et a` contrer des menaces, des violations de donn´ees et d’autres sources. Il existe diff´erents types de programmes, services et dispositifs de s´ecurit´e des applications qu’une entreprise peut utiliser. Les pare-feux, les syst`emes antivirus et le chiffrement des donn´ees ne sont que quelques exemples d’outils servant `a empˆecher les utilisateurs non autoris´es de p´en´etrer dans un syst`eme. Si une entreprise souhaite pr´evoir des ensembles de donn´ees sp´ecifiques et sensibles, elle peut ´etablir des politiques uniques de s´ecurit´e des applications pour ces ressources. La s´ecurit´e des applications peut ˆetre int´egr´ee `a diff´erents stades, mais l’adoption des bonnes pratiques se fait le plus souvent lors des phases de d´eveloppement des applications. Dans ce document, nous apporterons des m´ethodes ou des solutions techniques afin de r´epondre aux diff´erents besoins list´e ci-dessous , afin de garantir la s´ecurit´e du d´eveloppement de la fonction d’authentification, de la fonction de commande de produit et de la configuration globale de l’application. 1. Les utilisateurs doivent s’authentifier avec leur mot de passe. Ce mot de passe ne doit pas ˆetre accessible `a une personne tierce sur le r´eseau et mˆeme en cas de vol de la base de donn´ees 2. Les interfaces clients de l’application ne doivent pas afficher d’autres informations que celles voulues par le cahier des charges, ni ˆetre modifi´ee par un attaquant. 3. Un attaquant ne doit pas pouvoir se connecter `a un compte sans le bon mot de passe ni acc´eder ou modifier les informations des autres comptes. 4. Un utilisateur ne doit pas pouvoir faire de commande sans s’en rendre compte. 5. Un attaquant ne doit pas pouvoir lister les fichiers de l’application ni avoir acc`es aux informations de configuration du serveur web.

Page 3

2 2.1

Liste des exigences de s´ ecurit´ e S´ ecuriser l’authentification des utilisateurs

L’application doit chiffrer correctement toutes les communications authentifi´ ees et sensibles, avec des algorithme de hachage cryptographiques sp´ ecifiques afin d’´ eviter le reniflage des informations sensibles. 2.1.1

Protocole de chiffrement des communications

L’application doit utiliser le protocole de s´ecurisation des ´echanges Transport Layer Security (TLS), qui est un protocole cryptographique con¸cu pour assurer la s´ecurit´e des communications sur un r´eseau informatique. Ce protocole doit fournir une s´ecurit´e pour toutes les connexions authentifi´ees entre les clients et les serveurs de l’application et qui transmettent des donn´ees sensibles, tel que des ´el´ements d’authentification ou d’autres informations priv´ees concernant les utilisateurs. HTTPS doit donc empˆecher des intrus d’´ecouter les communications entre l’application et les utilisateurs de mani`ere `a garantir l’int´egrit´e, la confidentialit´e et l’authenticit´e des connexions et des donn´ees. L’activation du protocole HTTPS pour l’application implique de mani`ere obligatoire, l’obtention d’un certificat de s´ecurit´e de confiance. Ce certificat doit ˆetre d´elivr´e et sign´e par une autorit´e de certification de confiance, afin d’indiquer que le serveur a d´emontr´e la propri´et´e du domaine a` une autorit´e de certification approuv´ee au moment de l’´emission du certificat. Lors de la configuration du certificat, il est imp´eratif de s’assurer que les cl´es de chiffrement b´en´eficient d’un haut niveau de s´ecurit´e et d’une taille d’au moins de 2 048 bits. 2.1.2

Forcer l’utilisation de HTTPS

L’application doit utiliser HTTP Strict Transport Security (HSTS) qui est un en-tˆete de r´eponse et qui permet de forcer les navigateurs des utilisateurs `a utiliser le HTTPS pour toutes les requˆetes ult´erieures qu’ils envoient a` l’application. Cela signifie qu’une visite sur l’application est automatiquement redirig´ee sans qu’il soit n´ecessaire d’envoyer au pr´ealable une demande pour la page HTTP. Cela permet ´egalement d’´eviter une attaque de niveau inf´erieur lors d’une attaque de type ”Man in the Middle” qui obligerait le trafic a` passer par une connexion non s´ecuris´ee au lieu de la connexion HTTPS crypt´ee. Le HSTS fonctionne de telle mani`ere que non seulement le trafic direct vers le site web en question est automatiquement converti en une connexion HTTPS. Les liens qui se trouvent sur une page externe et qui renvoient a` la page HTTP sont ´egalement automatiquement envoy´es a` la page HTTPS. En outre, l’utilisation forc´ee du HTTPS empˆeche ´egalement le d´etournement de la cl´e de session par les cookies. Cela signifie donc qu’un attaquant qui r´eussit `a usurper la r´esolution DNS de l’application, doit ´egalement cr´eer une connexion HTTPS valide. Cela rend l’usurpation de DNS aussi difficile et coˆ uteuse que l’attaque HTTPS en g´en´eral.

Page 4

2.2

S´ ecuriser les manipulations en base de donn´ ees

L’application doit utiliser des requˆ etes pr´ epar´ ees ou pr´ ecompil´ ees du cˆ ot´ e de la base de donn´ ees et ˆ etre appel´ ees directement depuis le code source afin de prot´ eger les donn´ ees encapsul´ ees dans les requˆ etes. 2.2.1

Requˆ etes SQL pr´ epar´ ees

La plupart des instances d’injection SQL peuvent ˆetre ´evit´ees en utilisant des requˆetes param´etr´ees, plutˆot qu’utiliser la concat´enation de chaˆınes de caract`eres dans la requˆete. Lors de l’´etablissement d’une requete SQL, si l’entr´ee utilisateur est concat´en´ee directement dans la requˆete, celle-ci sera vuln´erable a` l’injection SQL. Grˆace aux requˆetes pr´epar´ees, il est possible de r´e´ecrire facilement ces requˆetes de mani`ere `a empˆecher l’entr´ee de l’utilisateur d’interf´erer avec la structure de la requˆete. Les requˆetes param´etr´ees peuvent ˆetre utilis´ees dans toutes les situations o` u une entr´ee non fiable apparaˆıt sous forme de donn´ees dans la requˆete, y compris dans les clauses WHERE, les valeurs dans les INSERT ou les d´eclarations UPDATE. Cependant, ils ne peuvent pas ˆetre utilis´es pour g´erer les entr´ees non fiables dans d’autres parties de la requˆete, telles que les noms des tables ou des colonnes. Pour qu’une requˆete param´etr´ee empˆeche efficacement l’injection SQL, la chaˆıne utilis´ee dans la requˆete doit toujours ˆetre une constante cod´ee en dur et ne doit jamais contenir de donn´ees variables d’aucune origine. La premi`ere ´etape consiste a` cr´eer un mod`ele de d´eclaration. Au lieu des valeurs concr`etes pour les param`etres pertinents, les variables de liaison sont ins´er´ees. Ceux-ci sont en g´en´eral marqu´es d’un ” ?”. Les requˆetes pr´epar´ees sont ensuite transmises au syst`eme de gestion de la base de donn´ees correspondante. Ensuite, le syst`eme de gestion de la base de donn´ees commence par analyser le mod`ele de d´eclaration afin qu’il puisse ˆetre compil´e a` l’´etape suivant, c’est-`a-dire converti en une d´eclaration ex´ecutable. Au cours de ce processus, la requˆete pr´epar´ee est ´egalement optimis´ee. Par la suite, le mod`ele trait´e peut ˆetre ex´ecut´e dans le syst`eme de base de donn´ees aussi souvent que n´ecessaire. La seule condition pr´ealable a` cela est une entr´ee appropri´ee de l’application connect´ee ou une source de donn´ees qui doit fournir des valeurs correspondantes pour les champs de caract`ere de remplissage. Cette fonctionnalit´e est propos´ee sur la plupart des syst`emes de gestion de base de donn´ees relationnelle telle ` noter qu’il n’est pas n´ecessaire d’´echapper les ´el´ements devant que MySQL, MariaDB, etc. A etre ins´er´e dans une instruction pr´epar´ee car ceux-ci sont automatiquement ´echapp´es.

Page 5

2.3

Prot´ eger le stockage des informations sensibles

Le m´ ecanisme d’authentification doit reposer sur une m´ ethode de stockage des informations d’identification s´ ecuris´ ee afin de prot´ eger correctement les identit´ es ainsi que les droits associ´ es. 2.3.1

Fonction de hachage cryptographique

Le hachage de mot de passe est l’une des pratiques de s´ecurit´e les plus basiques qui doit ˆetre effectu´e. Cette op´eration doit permettre de chiffrer un mot de passe sans possibilit´es d’op´eration inverse et produire une chaine unique et de longueur fixe appel´ee hash. Sans m´ecanisme de hachage, chaque mot de passe stock´e peut ˆetre vol´e si les bases de donn´ees sont compromissent, permettant a` un attaquant d’ˆetre imm´ediatement utilis´e pour acc´eder frauduleusement a` l’application. Pour mettre en place ce processus il est n´ecessaire d’utiliser des fonctions math´ematiques de hachage robustes afin d’appliquer une transformation aux mots de passe afin de rendre impossible la r´ecup´eration d’un mot de passe d’origine a` partir du r´esultat fourni par la fonction de hashage, mais ´egalement de rendre possible la r´ecup´eration d’un r´esultat pour n’importe quel mot de passe en entr´ee. Ainsi, lors d’une phase d’authentification, on ne compare plus deux mots de passe en clair mais deux hashes du mot de passe. 2.3.2

M´ ethode de salage cryptographique

Un sel al´eatoire doit ˆetre g´en´er´e et appliqu´e durant le processus de hachage pour ´eliminer la possibilit´e d’attaques par dictionnaires. Le sel est une donn´ee additionnelle qui permet de renforcer significativement la puissance du hachage pour le rendre beaucoup plus difficile `a d´echiffrer, car celui-ci est fabriqu´e a` l’aide d’une fonction permettant de g´en´erer al´eatoirement des chaˆınes de caract`eres diff´erents pour chaque utilisateur, `a l’aide g´en´erateur de nombres al´eatoires adapt´e `a la cryptographie. Cette chaˆıne de caract`eres doit ˆetre ajout´ee au d´ebut du mot de passe avant d’hasher afin de renforcer la s´ecurit´e des mots de passe de mani`ere a` empˆecher que deux informations identiques conduisent a` la mˆeme empreinte. Le but du salage est de lutter contre les attaques par analyse fr´equentielle, les attaques utilisant des rainbows tables, les attaques par dictionnaire et les attaques par force brute. Il est capital de se fier a` des impl´ementations qui sont support´ees et mises a` jour r´eguli`erement pour de la cryptographie. Les fonctions du langage ou du framework doivent ˆetre privil´egi´ee car ce sont les impl´ementations les mieux maintenues. Il est fortement d´econseill´e d’installer des portages des meilleurs algorithmes si le langage de programmation cible ne le propose pas.

Page 6

2.4

S´ ecuriser l’interface utilisateur

L’application doit disposer d’un m´ ecanisme pour l’encodage et la validation des donn´ ees en entr´ ee et en sortie, afin d’empˆ echer toute injection de script de se produire et de de v´ erifier la conformit´ e des donn´ ees issues de sources externes. 2.4.1

Validation des donn´ ees en entr´ ee

Une validation des donn´ees doit ˆetre appliqu´e aussi strictement que possible au moment o` u elle est re¸cue pour la premi`ere fois d’un utilisateur. Si un utilisateur soumet une URL qui sera renvoy´ee dans les r´eponses. Par exemple, il est imp´eratif de v´erifier que celle-ci commence par un protocole sˆ ur tel que HTTPS, dans le cas contraire l’application pourrait ˆetre exploitable par un attaquant, a` l’aide de protocoles nuisibles. La validation des entr´ees devrait id´ealement fonctionner en bloquant les entr´ees invalides. Une approche alternative, consistant a` essayer de nettoyer une entr´ee invalide pour la rendre valide, mais celle-ci est plus sujette aux erreurs et doit ˆetre ´evit´ee dans la mesure du possible. La validation des entr´ees doit utiliser des listes blanches plutˆot que des listes noires. En effet, au lieu d’essayer de faire une liste de tous les protocoles nuisibles, nous devons simplement cr´eer une liste de protocoles sˆ urs et interdire tout ce qui ne figure pas sur la liste. Cela garantira que la d´efense de l’application ne se brisera pas lorsque de nouveaux protocoles nuisibles apparaˆıtront et la rendront moins sensible aux attaques qui cherchent a` masquer des valeurs invalides pour ´echapper a` une liste noire. 2.4.2

Encodage des donn´ ees en sortie

L’encodage doit ˆetre appliqu´e directement avant que les donn´ees contrˆolables par l’utilisateur ne soient ´ecrites sur une page, car le contexte dans lequel celles-ci sont ´ecrites, d´etermine le type d’encodage que l’application doit utiliser. Les valeurs a` l’int´erieur d’une chaˆıne de caract`eres en Javascript n´ecessitent un type d’´echappement diff´erent de celles d’une chaine de caract`eres en HTML. Dans un contexte HTML, il est n´ecessaire de convertir les valeurs qui ne figurent pas sur la liste blanche des entit´es HTML. Par exemple, le symbole de l’euro doit etre converti avec ”&euro ;”, etc... Il est ´egalement important de v´erifier que les pages de l’application ne sont pas configur´es avec plusieurs encodages diff´erents, l’application doit toujours utiliser le codage de caract`eres UTF-8, car l’utilisation d’UTF-8 simplifie non seulement la cr´eation de pages, mais ´evite ´egalement des r´esultats inattendus lors de la soumission de formulaires et des encodages d’URL, qui utilisent l’encodage de caract`eres du document par d´efaut.

Page 7

2.5

S´ ecuriser l’interface de commande

L’application doit impl´ ementer un m´ ecanisme de cr´ eation d’identifiant d’acc` es unique, bas´ e sur une valeur secr` ete al´ eatoire pour chaque action qui d´ epend de l’utilisateur qui l’ex´ ecute, afin d’´ eviter toute action inattendue. 2.5.1

Production des identifiant d’acc` es uniques

Les identifiant d’acc`es unique doivent contenir une entropie importante et ˆetre fortement impr´evisibles, avec les mˆemes propri´et´es que les jetons de session en g´en´eral. Nous devons donc utiliser un g´en´erateur de nombre de force cryptographique, afin de g´en´erer une s´equence de nombres dont les propri´et´es se rapprochent des propri´et´es des s´equences de nombres al´eatoires. Il est ´egalement possible de g´en´erer des jetons individuels en concat´enant sa sortie avec une entropie sp´ecifique a` l’utilisateur et utiliser un hachage fort permettant de mettre en place une barri`ere suppl´ementaire pour un attaquant qui tenterait d’analyser les jetons sur la base d’un ´echantillon qui leur est d´elivr´e. 2.5.2

Transmission des identifiant d’acc` es uniques

Les jetons CSRF ne doivent pas ˆetre transmis dans les cookies et n´ecessitent d’ˆetre trait´es comme des secrets. C’est-`a-dire, ˆetre g´er´es de mani`ere s´ecuris´ee tout au long de leur cycle de vie. Une approche normalement efficace consiste a` transmettre le jeton au client dans un champ masqu´e d’un formulaire HTML soumis `a l’aide de la m´ethode POST. Le jeton sera alors inclus en tant que param`etre de requˆete lors de la soumission du formulaire. Pour plus de s´ecurit´e, le champ contenant le jeton CSRF doit ˆetre plac´e le plus tˆot possible dans le document HTML, id´ealement avant tout champ de saisie non masqu´e et avant tout emplacement o` u des donn´ees contrˆolables par l’utilisateur sont int´egr´ees dans le code HTML. Cela permet d’att´enuer diverses techniques dans lesquelles un attaquant peut utiliser des donn´ees sp´ecialement con¸cues pour manipuler le document HTML et capturer des parties de son contenu. 2.5.3

Validation des identifiant d’acc` es uniques

Lorsqu’un jeton CSRF est g´en´er´e, il doit ˆetre stock´e cˆot´e serveur dans les donn´ees de session de l’utilisateur. Lorsqu’une demande ult´erieure est re¸cue et n´ecessite une validation, l’application cˆot´e serveur doit v´erifier que la demande inclut un jeton qui correspond `a la valeur qui a ´et´e stock´ee dans la session de l’utilisateur. Cette validation doit ˆetre effectu´ee quelle que soit la m´ethode HTTP ou le type de contenu de la requˆete. Si la demande ne contient aucun jeton, elle doit ˆetre rejet´ee de la mˆeme mani`ere que lorsqu’un jeton invalide est pr´esent.

Page 8

2.6

S´ ecuriser la configuration des serveurs

Les diff´ erents composants de l’infrastructure sur laquelle reposent l’application ne doivent pas exposer des vuln´ erabilit´ es li´ ees ` a des mauvaises configurations de s´ ecurit´ e. 2.6.1

D´ esactivation du listage des r´ epertoires

Par d´efaut, les serveurs Web de l’application peuvent ˆetre configur´es pour lister automatiquement le contenu des r´epertoires qui n’ont pas de page d’index pr´esente. Cela peut aider un attaquant en lui permettant d’identifier rapidement les ressources sur un chemin donn´e et de proc´eder directement a` l’analyse et a` l’attaque de ces ressources. Cela augmente particuli`erement l’exposition des fichiers sensibles dans le r´epertoire qui ne sont pas destin´es `a ˆetre accessibles aux utilisateurs, tels que les fichiers temporaires. Les listes d’annuaires ellesmˆemes ne constituent pas n´ecessairement une vuln´erabilit´e de s´ecurit´e. Cependant, toutes les ressources sensibles au sein de la racine Web doivent dans tous les cas ˆetre correctement contrˆol´ees et ne doivent pas ˆetre accessibles par une partie non autoris´ee qui connaˆıt ou devine l’URL. Mˆeme lorsque les listes de r´epertoires sont d´esactiv´ees, un attaquant peut ´ deviner l’emplacement des fichiers sensibles `a l’aide d’outils automatis´es. Etant donn´e qu’il n’y a aucune bonne raison de fournir des listes de r´epertoires de l’application, et que leur d´esactivation peut cr´eer des obstacles suppl´ementaires sur le chemin d’un attaquant. Les serveurs doivent donc ˆetre configur´e de mani`ere `a empˆecher les listes de r´epertoires pour tous les chemins sous la racine Web. 2.6.2

Personnalisation des messages d’erreurs

Empˆecher compl`etement la divulgation d’informations est d´elicat en raison de la grande vari´et´e de fa¸cons dont cela peut se produire. Cependant, il existe certaines bonnes pratiques g´en´erales que nous devons suivre pour minimiser le risque que ces types de vuln´erabilit´es s’infiltrent dans l’application. Il est d’abord n´ecessaire d’utiliser autant que possible des messages d’erreur g´en´eriques afin de ne pas fournir inutilement aux attaquants des indices sur le comportement des applications.

Page 9