Sécurité Des Applications Web (2702)

FORMATION SÉCURITÉ
DES APPLICATIONS WEB

SOMMAIRE
INTRODUCTION
CONSTITUANTS D’UNE APPLICATION WEB
PROTOCOLE HTTP
LES MÉTHODES DE REQUÊTE HTTP :
PDU, GET, POST, PUT, DELETE, HEAD ET TRACE
LES VULNÉRABILITÉS DES APPLICATIONS WEB
AUTHENTIFICATION
LE FIREWALL RÉSEAU DANS LA PROTECTION
D'APPLICATIONS HTTP
SÉCURISATION DES FLUX AVEC SSL/TLS
CERTIFICATS NUMÉRIQUE X.509
CONFIGURATION DU SYSTÈME ET DES LOGICIELS
PRINCIPE DU DÉVELOPPEMENT SÉCURISÉ
INTRODUCTION
L'histoire
Depuis les débuts de l'informatique, les utilisateurs s'intéressaient

principalement à comment exploiter au mieux la puissance de cet
outil.
Une course effrénée fut alors menée au développement de
programmes de plus en plus performants et de plus en plus
complexes.
Ce qui importait le plus c'était l'exactitude et la précision des
calculs et opérations.
L'histoire
Cependant, plus les programmes devenaient conséquents, plus ils

étaient truffés de bugs et de dysfonctionnements qui
compromettaient les résultats retournés.
Ces bugs furent généralement l'œuvre du hasard ou de légers

oublis de la part des développeurs.
Dans l'ombre naquit un groupe d'utilisateurs qui avaient comme

intention de porter atteinte aux réalisations informatiques.
L'histoire
Au fil des années, les pirates devenaient de plus en plus actifs et

déterminés à causer davantage de dégâts aux systèmes :
en détruisant les données,
en espionnant les informations confidentielles,
en condamnant des systèmes entiers en les empêchant de
fonctionner normalement ou en les faisant systématiquement
crasher.
La sécurité informatique devenue une nécessité
Depuis pas mal de temps, la sécurité est devenue une branche

incontournable dans le domaine de l'informatique.
Elle évolue sans cesse pour être en mesure de déjouer les subterfuges
des pirates.
Les pirates sortent de nouvelles techniques et découvrent de nouvelles
vulnérabilités.
Un défi qui devient de plus en plus coriace à soulever surtout dans le
monde où tous les équipements de toute sorte sont connectés.
Pourquoi les vulnérabilités existent-elles ?
Une vulnérabilité est une faille (ou défaut de conception ou de

réalisation) qui peut être présente dans un système informatique.
Elles sont découvertes au moment des tests avant la sortie officielle
d'un logiciel informatique par exemple.
Cependant, les vulnérabilités les plus dangereuses restent à l'abri des
regards jusqu'à ce qu'elles soient trouvées accidentellement par les
utilisateurs, ou détraquées délibérément par des pirates qui passent
au peigne fin tout ce qui se présente sous leurs mains.
Pourquoi les vulnérabilités existent-elles ?
En général, les vulnérabilités sont toujours là, dans chaque système,

chaque réseau, chaque logiciel.
On ne peut pas les éliminer à 100% car, tout simplement, on ignore leur
existence.
Mais le jour où elles font surface, les éditeurs de logiciels ne tardent pas à
sortir des correctifs pour les combler.
La sécurité applicative
Les 3 niveaux les plus connus :

Sécurité réseau : dans ce cas, on cherche à instaurer la sécurité au niveau
d'un réseau (ou sous-réseau) entier de telle sorte à empêcher toute atteinte
à n'importe quel élément faisant partie de ce réseau là. Les firewalls et les
NIPS (Network-based Intrusion Prevention System) sont des solutions
souvent envisagées dans cette situation.
Sécurité système : dans ce cas de figure, le système et les services tournés sur
un ordinateur (serveur, station de travail, terminal...) est ciblé par la sécurité.
Les antivirus constituent une solution très populaire, mais aussi les HIPS (Host-
based Intrusion Prevention System) ou HIDS (Host-based Intrusion Detection
System).
Sécurité applicative : Ici ce n'est ni le réseau ni le système entier d'un
ordinateur qui nous intéresse, mais un logiciel ou une application en
particulier (site, application web...). Dans ce cas de figure on peut utiliser des
correctifs, des filtres, des IPS applicatifs, des WAF (Web Application Firewall)...
D’après des enquêtes récentes, trois sites Web sur quatre sont
vulnérables aux agressions, et la vaste majorité de ces offensives
vise la sécurité des applications.
Les entreprises font confiance à la sécurité du réseau et de l’hôte,
mais souvent, ces mesures ne suffisent pas pour empêcher ces
attaques contre les applications Web.
La sécurité des applications diffère de celle du réseau et du système
hôte. Les approches traditionnelles d’implémentation de la sécurité
du réseau et de l’hôte ne conviennent pas à ce niveau.
Les obligations en matière de sécurité des applications, pour peu qu’elles aient été
définies, sont souvent perçues comme impossibles à mettre en pratique, elles sont
dotées d’une connotation négative (interdictions), ou encore elles s’avèrent trop floues.
Le test de la sécurité des applications est effectué uniquement en cas d’audit.
Les équipes chargées de la conception et de la définition des exigences des
applications considèrent que la sécurité concerne l’équipe réseau ou informatique.
Les procédures de test standard concernent principalement le comportement
fonctionnel.
Seuls les quelques rares « spécialistes de la sécurité » de l’entreprise sont conscients
des menaces pesant sur la sécurité des applications.
Le test de la sécurité des applications se limite à de courts créneaux au cours desquels
des pirates dits éthiques tentent de simuler ce que feraient les vrais pirates.
USURPATION D’IDENTITÉ
Exemples :
L’agresseur entre les informations d’authentification d’un autre utilisateur.
L’agresseur modifie le contenu d’un cookie ou d’un paramètre afin de se faire passer
pour un autre utilisateur ou de faire croire que le cookie provient d’un autre serveur.
Erreurs courantes :
Utilisation d’une authentification basée sur les communications pour autoriser l’accès
aux données d’un utilisateur.
Utilisation d’informations d’authentification non chiffrées qui peuvent être interceptées
et réutilisées par un espion.
Stockage d’informations d’authentification dans des cookies ou des paramètres.
Utilisation de méthodes d’authentification « bricolées maison » ou non testées.
Le logiciel client n’est pas autorisé à authentifier l’hôte lorsque cela est nécessaire.
Utilisation d’une authentification provenant d’un domaine sécurisé erroné.
FALSIFICATION
Exemples :
Défiguration d’un site Web.
Modification des données pendant leur transit.
Erreurs courantes :
Autorisation accordée à des sources de données sans validation préalable.
Assainissement des données en entrée afin d’empêcher l’exécution de
code indésirable.
Droits d’exécution accordés à des comptes dont les privilèges ont été
augmentés.
Absence de chiffrement des données sensibles.
RÉPUDIATION
Exemples :
Suppression de journaux.
Usurpation d’identités pour faire une demande de modifications.
Erreurs courantes :
Processus d’autorisation et d’authentification insuffisant, voire inexistant.
Journalisation inadaptée.
Autorisation de présence d’informations sensibles sur des canaux de
communications non sécurisés.
DIVULGATION D’INFORMATIONS
Exemples :
Vol de mots de passe.
Obtention d’informations de carte de crédit ou d’autres informations
personnelles identifiables (PII) similaires.
Obtention d’informations sur le code source de l’application et/ou de ses
systèmes hôte.
Erreurs courantes :
Possibilité pour un utilisateur authentifié d’accéder aux données d’autres
utilisateurs.
Autorisation de présence d’informations sensibles sur des canaux de
communications non sécurisés.
Choix inadapté des algorithmes et des clefs de chiffrement.
DÉNI DE SERVICE (DOS)
Exemples :
Envoi d’un trop grand nombre de requêtes simultanées à l’application.
Envoi de requêtes qui provoquent le redémarrage de l’application ou des
temps de réponse très longs.
Erreurs courantes :
Placement d’un trop grand nombre d’applications ou d’applications
conflictuelles sur un seul serveur.
Test d’unités incomplet.
ELÉVATION DES PRIVILÈGES
Exemples :
Un utilisateur se voit affecter des droits d’administration.
Un employé accède à un rôle de manager.
Erreurs courantes :
Exécution de processus du serveur Web avec les droits « root »
ou « administrateur ».
Erreurs de codage permettant des dépassements de la mémoire tampon,
plaçant l’application dans un état de déboguage élevé.
Erreurs au stade de la conception
Si vous avez défini un ensemble d’exigences approprié, à quel moment

votre équipe de conception peut-elle faire fausse route ?
Cette équipe doit-elle aussi être sensibilisée aux menaces liées à la
sécurité de l’application ?
Un choix technologique insatisfaisant ou mal adapté peut laisser penser
aux concepteurs, à tort, qu’ils ont pris les bonnes mesures pour répondre
à une exigence de sécurité particulière.
Erreurs au stade du codage
Vous êtes doté d’une conception saine à partir de laquelle vos

développeurs vont pouvoir travailler
En général, l’erreur se produit si, au lieu de rédiger du code entièrement
nouveau, ils réutilisent du code comportant des imperfections, ou
génèrent du code à l’aide d’un assistant IDE non sécurisé.
Le danger est d’effectuer une validation des données incorrecte ou de ne
pas utiliser correctement les fonctions de sécurité du système choisi pour
l’application.
Erreurs se produisant à un stade ultérieur
Dans la plupart des entreprises, les connaissances en matière de

sécurité des applications sont souvent détenues par une poignée
de collaborateurs membres d’équipes d’audit de sécurité chargées
de réaliser des intrusions ou des piratages volontaires.
Ils opèrent dans des créneaux limités et examinent l’application
vers la fin du cycle de vie du développement logiciel, dans l’espoir
d’intercepter des erreurs de sécurité avant la commercialisation de
l’application.
La centralisation de cette fonction est due au fait qu’un pirate éthique
compétent est rare (comprendre cher), et que ces équipes réalisent
souvent des audits commandés de systèmes de production.
SOMMAIRE
INTRODUCTION
PROTOCOLE HTTP
AUTHENTIFICATION
D'APPLICATIONS HTTP
CONSTITUANTS
D’UNE
APPLICATION WEB
Triptyque d'une application
Présentation
Interface utilisateur pour interagir avec l'application

Interface classique type GUI (ex : traitement de texte)
Interface Web, plus légère
Persistance
Enregistrement sur support physique des données de l'application

Fichiers (texte, binaire, XML, ...)
Base de données relationnelles
Simple
Avec redondance pour fiabilité
Multiples : fédération de bases de données
…
Services métier
Partie applicative
Intègre la logique métier
Ex : un document est composé de sections, elles mêmes composées de
sous-sections...
Services offerts aux utilisateurs
Ex : créer un document, le modifier, ajouter des sections, l'enregistrer...
Trois parties
Sont intégrées et coopèrent pour le fonctionnement de l'application.
En anglais, on les appelle aussi des « tiers » (étages)

Application « 3 – tiers » quand les 3 parties sont clairement distinctes.
Dans un contexte distribué
Les tiers sont / peuvent être exécutés sur des machines différentes
Certains tiers peuvent être sous-découpés
De nombreuses variantes de placement des tiers et de leur distribution
Modèle centralisé
Tout est sur la même machine

Architecture 2 – tiers
Client / serveur de base, avec 2 éléments

Client : présentation, interface utilisateur
Serveur : partie persistance, gestion physique des données
Les services métier / la partie applicative peuvent être :

Soit entièrement coté client, intégrés avec la présentation
La partie serveur ne gère que les données
Ex : traitement de texte avec serveur de fichiers distants
Ex : application accédant à une BDD distante
Soit entièrement coté serveur

La partie client ne gère que l'interface utilisateur
L'interface utilisateur peut même être exécutée sur le serveur
Fonctionnement mode terminal / mainframe
L'utilisateur a simplement devant lui écran / clavier / souris pour interagir à distance avec
l'application s'exécutant entièrement sur le serveur
Soit découpés entre la partie serveur et la partie client

Client : présentation + applicatif

Serveur : applicatif + gestion donnée

Terminal : client intègre un minimum de la partie présentation

Applicatif : découpé entre client et serveur

Les 3 principaux tiers s'exécutent chacuns sur une machine différente

Présentation
Machine client
Applicatif / métier
Serveur d'applications
Persistance
Serveur de (base de) données
Architecture 3 – tiers sur le web
Très développée de nos jours

Avec généralement un fonctionnement au dessus du Web
Couche présentation
Navigateur web sur machine cliente
Client léger
Affichage de contenu HTML
Couche applicative / métier
Serveur d'applications
Serveur HTTP exécutant des composants / éléments logiciels qui génèrent
dynamiquement du contenu HTML
Via des requêtes à des BDD distantes
Couche persistance
Serveur(s) de BDD de données
Architecture n – tiers
Rajoute des étages / couches en plus

La couche applicative n'est pas monolithique
Peut s'appuyer et interagir avec d'autres services
Composition horizontale
Service métier utilise d'autres services métiers
Composition verticale
Les services métiers peuvent aussi s'appuyer sur des services techniques
Sécurité,
Transaction
...
Chaque service correspond à une couche
D'où le terme de N-tiers
Intérêts d'avoir plusieurs services /
couches (3 ou plus)
Réutilisation de services existants

Découplage des aspects métiers et technique et des services entre
eux : meilleure modularité
Facilite l’évolution : nouvelle version de service
Facilite le passage à l'échelle : évolution de certains services
On recherche en général un couplage faible entre les services
Permet de faire évoluer les services un par un sans modification du reste
de l'application
Inconvénients
En général, les divers services s'appuient sur des technologies très

variées : nécessité de gérer l'hétérogénéité et l'interopérabilité
Utilisation de framework / outils supplémentaires
Les services étant plus découpés et distribués, pose plus de

problèmes liés à la distribution
Logique de présentation
Les tâches liées à la présentation requièrent

L'interaction avec l'utilisateur
La logique de présentation
Le traitement des données retournées par les services métiers et leur présentation à
destination de l'utilisateur
Pour un client lourd

Interaction avec utilisateur
Réalisée par la GUI (Graphic User Interface) d'un client lourd : boutons, listes, menus, zones
graphiques …
Toute la puissance d'une librairie de widgets dédiée dans un langage de programmation
Ex : Java FX
Client lourd fait directement l'appel des services métiers sur le serveur et met en forme les
données retournées dans la GUI
Pour un client Web

Fonctionnement basique
Interaction avec l'utilisateur : liens vers des URLs, formulaires ...
Navigateur se contente d'afficher du code HTML qui ne peut pas être statique ici vu
que le contenu dépend des données récupérées en BDD
Serveur appelle les services métiers qui renvoient les données et met lui-même en
forme les données dans le code HTML retourné au client
Réalisé de préférence dans une couche à part sur le serveur
Fonctionnement évolué grâce à la généralisation de Javascript et nouvelles
normes HTML/CSS
Possibilité d'exécuter du code coté client et interactions plus riches
Affichage de la page peut varier selon l'interaction avec l'utilisateur
Client peut exécuter une partie de la logique de présentation
Y compris de manière dynamique : requêtes pour récupérer des données sur le
serveur et les insérer dans la page affichée
Ex : technologies AJAX ou WebSocket
Persistance
Couche de persistance
Stockage et manipulation des données de l'application
Supports physiques variés
Fichiers binaires
Fichiers textes « de base » ou structurés (JSON)
Fichiers XML
Une base de données relationnelle ou un ensemble de bases de données
relationnelles
Pour ce dernier cas
Nécessité d'envoyer à distance des requêtes de type SQL et d'en récupérer les
résultats
Pour réaliser cela
Soit c'est natif dans le langage utilisé (ex : PHP)
Soit on passe par des frameworks ou des API dédiés
Persistance
Quelques standards / outils d'accès à distance à des BDD

RDA (Remote Data Access) de l'ISO
ODBC (Open Data Base Connectivity) de Microsoft
JDBC (Java Data Base Connectivity) d'Oracle
Framework pour le langage Java
Fonctionnement général
Gestion de requêtes SQL mais avec indépendance du SGBDR utilisé (mySQL,
PostgreSQL, Oracle ...)
En général, seule la phase de connexion au SGBDR est spécifique
Pour des fichiers XML, outils gérant la navigation dans l'arbre de données
DOM : norme W3C permettant de naviguer et modifier un contenu XML ou HTML
Utilisé notamment coté client Web avec du Javascript
JAXP : framework JAVA pour lecture/édition fichiers XML
Persistance
En programmation orientée objet, les données

Sont des objets avec des attributs valués et des références vers d'autres objets
Forment une structure globale sous forme de graphe
Données stockées dans des supports externes
Schéma relationnel pour SGBDR
Arbre pour XML
Problème de différence de format de stockage et de manipulation
de données coté programme
Doit écrire du code qui permet de passer d'un objet au format de stockage
physique
Peut être rapidement lourd et répétitif à faire
Persistance
Peut à la place utiliser des frameworks de plus haut niveau

Correspondances objet-relationnel
ORM : Object-Relationnal Mapping
Sérialisation XML
Principes
On définit la correspondance entre la structure des classes objet et le schéma
relationnel/XML
On manipule directement des objets dans le code
Le framework fait la lecture/enregistrement du contenu des objets sur le support
physique
Plus besoin de coder des requêtes SQL
Même si un langage de requête orienté objet reste utile
Exemples
JPA (Java Persistence API) ou Hibernate pour ORM en Java
JAXB pour sérialisation XML en Java
Une application 3/N – tiers intègre un grand nombre de technologies
Présentation : HTML/CSS, librairies graphiques...
Applicatif : objets, composants, scripts exécutables, services ...
Données : fichiers XML, SGBDR, ...
Protocoles de communication : RPC/RMI, HTTP, messages, ...
Pour faciliter l'intégration de ces technologies et le développement d'applications

Éditeurs offrent des frameworks globaux
Java EE chez Oracle
.Net chez Microsoft
Serveur d'application
Serveur permettant d'exécuter les parties applicatives dans le contexte de
ces frameworks
Frontal (serveur)
il s'agit de la mise en place d'un serveur permettant la dissimulation d'un

autre. Dans ce cas, le serveur frontal intercepte les requêtes utilisateur et les
ré-envoie vers le serveur backend. Le serveur frontal agit donc comme un
proxy. La mise en place d'un tel système crée un temps de latence relatif à la
distance entre les deux serveurs.
En informatique, un frontal peut désigner une interface de communication

entre plusieurs applications hétérogènes ou un point d'entrée uniformisé
pour des services différents. Par exemple, dans les architectures web, on peut
utiliser un serveur frontal HTTP pour traiter les requêtes générales et renvoyer
certaines demandes de service vers un conteneur d'application (comme
Tomcat) ou un serveur d'applications (comme JBoss, GlassFish, TomEE (en),
Resin (en), ...).
Serveur Web frontal
Rôle d’un serveur Web frontal

La sécurité : Le serveur Web frontal sert de bastion pour toute requête
entrante et isole la JVM de l’Internet.
La performance : Chacun des deux serveurs remplit pleinement son rôle :

servir les pages et les calculer sont deux choses différentes. Le serveur
applicatif est d’autant plus proche des sources de données.
Evolutivité : Un serveur Web frontal permet l’évolutivité verticale /

horizontale.
Fonctionnalité : Il ajoute des fonctionnalités de chiffrement, de réécriture,

de pare-feu applicatif, de protection de type OWASP, etc.
SOMMAIRE
INTRODUCTION
PROTOCOLE HTTP
AUTHENTIFICATION
D'APPLICATIONS HTTP
PROTOCOLE HTTP
TCP (Transmission Control Protocol)
TCP est un protocole qui va servir a la transmission de données entre

deux machines
Ce protocole est présent sur la couche transport du modèle OSI
Une session TCP possède 3 phases (l’établissement de la connexion,
le transfert des données et la fin de la connexion)
TCP (Transmission Control Protocol)
HTTP (HyperText Transfer Protocol)
HTTP est un protocole qui permet la transmission de fichier hyper média

(comme HTML). Il a été conçu pour communiquer entre les serveurs
WEB et les navigateurs (Chrome, Firefox, Edge…)
HTTP suit le modèle classique du « client-serveur », le client ouvre une
connexion et effectue une requête vers le serveur quant à lui le serveur
envoie une réponse par la suite au client
HTTP est un protocole client-serveur, les requêtes sont envoyées par une
entité : l’agent utilisateur (ou le proxy qui agit a son nom). La majorité du
temps l’agent utilisateur est un navigateur WEB, mais cela pourrait bien
être aussi un robot indexeur (notamment celui de google) ou pour un
autre moteur de recherche
Chaque requête individuelle est envoyée au serveur, ce dernier la traite

et fournit une « réponse ». Entre la requête et la réponse se trouve de
nombreuses entités qui porteront le terme de proxies (les proxies
exécutent les différentes opérations et agissent comme passerelles
ou comme caches)
L’agent utilisateur correspond à n’importe quel outil qui agit pour

l’utilisateur. Ce rôle est principalement rempli par un navigateur web.
Les exceptions sont les programmes crées par des ingénieurs ou
développeurs WEB pour le débogage des applications.
Pour afficher une page WEB le navigateur envoie une requête pour
récupérer le document HTML de base (index.html). Il analyse ensuite
le fichier et récupère les requêtes additionnels correspondant aux
scripts, aux informations de mise en page (CSS) et les sous contenus
(image et vidéo). Le navigateur assemble le tout afin de construire la
page qui va être affichée par la suite.
HTTP persistent connection
Le « HTTP Persistent Connexion » consiste a créer une seule connexion

TCP avec le serveur au lieu d’en créer plusieurs pour chaque requête.
Malheureusement le « HTTP persistent connexion » possède de
nombreux défaut, lorsqu’un client ouvre une connexion un autre client
lui ne peut pas faire de demande et le bloque. Une fois que la connexion
est finie un client peut faire une nouvelle requête.
HTTP persistant connection
Il possède aussi de nombreuses qualités. La latence dans les requêtes

est réduite (pas de handshaking), la réduction d’utilisation du
processeur étant donné que les déconnexion et reconnexion sont
réduites, le pipelinning HHTP est activé (vu plus tard dans les slides),
réduction de la congestion du réseau du à la baisse des connexions
TCP, les erreurs peuvent être signalées sans le temps d’attente de la
fermeture de connexion.
Handshaking
Le handshaking, c’est le fait de devoir à chaque fois recommencer une

nouvelle connexion avec l’accord des deux participants (client + serveur
dans le cas HTTP) pour entamer le transfert de données.
Pipeline HTTP
Le pipeline est une technique qui envoie plusieurs requête HHTP en

une seule connexion TCP sans attendre ses réponses.
Le pipelining donne une amélioration sur le web car il permet aux
pages HTML de se charger plus vite notamment sur les connexions à
faible débit (connexions satellite / ADSL saturé). L’amélioration se
verra moins sur les connexions haut débits car la limitation de HTTP1.1
est toujours appliqué (première requête envoyé première sortie).
Pour palier à ce problème le HTTP2.2 car il possède un
fonctionnement asynchrone.
Pipeline HTTP
Certains navigateurs prennent le pipelining en charge mais le

désactivent par défaut pour éviter les problèmes avec les anciens
serveurs (Firefox, SeaMonkey, Camino et Konqueror2.0).
SOMMAIRE
INTRODUCTION
PROTOCOLE HTTP
AUTHENTIFICATION
D'APPLICATIONS HTTP
LES MÉTHODES DE
REQUÊTE HTTP
PDU, GET, POST, PUT,
DELETE, HEAD ET TRACE
PDU (Protocol Data Unit)
Le PDU est l’unité de mesure des informations dans un réseau

informatique, il diffère selon les couches du modèle OSI.
La couche physique est le bit, la couche liaison est la trame,
la couche réseau est le paquet, la couche transport est le segment
pour TCP et le datagramme pour UDP (Le TCP et UDP font partie
de la même couche).
GET & POST
GET et POST sont 2 méthodes utilisées dans les formulaires en PHP.

La méthode GET va envoyer les données au serveur mais celles-ci
seront notés dans l’URL. Son principal défaut va être le manque de
sécurité étant donné que toutes les données enregistrées
apparaissent dans l’URL.
www.example.com/register.php?firstname=peter&name=miller&age=55&gender=male
GET & POST
POST est la méthode utilisée pour transmettre des données en vue d’un
traitement à une ressource (formulaire HTML en général). L’URI fournit
est l’URI d’une ressource à laquelle s’appliqueront les données envoyées
au préalable par la requête POST. Le résultat peut varier, de la création
d’une ressource a la modification d’une autre existante.
La mauvaise implémentation des méthodes HTTP par certains

navigateur (et la norme HTML qui ne supporte que les méthodes GET
et POST pour les formulaires) cette méthode est souvent utilisée en
remplacement de la requête PUT (qui devrait être utilisé pour la mise
à jour des ressources).
PUT (mettre en anglais)
La méthode PUT est une méthode utilisée pour le remplacement ou

l’ajout d’une ressource sur le serveur. Lorsqu’elle est utilisée elle fourni
une URI qui est l’URI de la ressource en question.
PUT a une différence avec la méthode POST (vu auparavant) qui est
qu’elle est idempotente. Si elle est envoyée une seule fois ou plusieurs
fois le résultat sera toujours le même (si elle est envoyée avec succès). Si
on fait plusieurs fois la même requête le résultat elles peuvent avoir des
effets additionnels.
DELETE
La méthode DELETE va supprimer la ressource demandée sur le

serveur.
Lorsque l’on effectue une requête DELETE nous allons avoir plusieurs
codes de réponse différents, le code de statut 202 (Accepted) si l’action
est en passe de réussir mais n’a pas été confirmé, 204 (no content) si
l’action a été confirmée et qu’aucune information supplémentaire n’est
à fournir et 200 (Ok) si l’action a été confirmée et que le message de
réponse inclut une représentation décrivant le statut.
HEAD
La méthode HEAD demande les en-têtes qui seraient retournées si la

ressource était demandée avec une méthode HTTP GE. Une telle
requête peut être envoyée avant de procéder au téléchargement
d’une ressource volumineuse afin d’économiser la bande passante.
Lorsqu’une réponse issue d’une requête HEAD possède un corps elle
doit être ignorée. Toutefois, les entêtes d’entité décrivant le contenu
du corps comme « Content-Length » peuvent être inclus dans la
réponse. Ils ne sont pas liés au corps de la réponse HEAD qui doit être
vide, mais au corps d’une réponse issue d’une requête similaire
utilisant la méthode GET.
TRACE
La méthode TRACE demande au serveur de retourner ce qu’il a reçu,

dans le but de tester et effectuer un diagnostic sur la connexion.
Cette méthode permet de fournir un mécanisme de débogage utile
grâce a son test de rebouclage vers la ressource cible.
SOMMAIRE
INTRODUCTION
PROTOCOLE HTTP
AUTHENTIFICATION
D'APPLICATIONS HTTP
LES VULNÉRABILITÉS
DES APPLICATIONS
WEB
Les vulnérabilités des applications Web
Injection :
Les injections SQL sont les techniques de piratage Web les plus courantes.
Une attaque par injection SQL consiste en l’insertion de code malveillant
via l’entrée de requête SQL du client vers l’application.
Si elle n’est pas traitée correctement, une telle injection de code peut avoir
un impact sérieux sur l’intégrité et la sécurité des données.
Des injections SQL peuvent avoir lieu lorsque des données non filtrées du
client (un champ de recherche par exemple), pénètrent dans l’interpréteur
SQL de l’application elle-même.
Un exploit d’injection SQL réussi peut ainsi :
Lire et modifier des données sensibles de la base de données.
Exécuter des opérations d’administration sur la base de données :
Audit d’arrêt ou SGBD
Tronquer les tables et les journaux
Ajouter des utilisateurs
Récupérer le contenu d’un fichier présent sur le système de fichiers SGBD.
Émettre des commandes au système d’exploitation.
Les attaques par injection SQL permettent aux attaquants :
L’usurpation d’identité
La falsification des données existantes
De créer des problèmes de répudiation tels que l’annulation de
transactions
De permettre la divulgation de toutes les données sur le système
De détruire les données ou de les rendre indisponibles
De devenir administrateur du serveur de base de données
La gravité des attaques par injection SQL est limitée par :
Les compétences et l’imagination de l’attaquant
Le système de défense (contre-mesures) :
La validation des entrées
L’intégralité des privilèges
Toutes les bases de données ne prennent pas en charge le chainage
de commande :
Microsoft Access
Connecteur MySQL / J et C
Oracle
Les injections SQL les plus courantes sont :
en PHP
ASP classique
Cold Fusion
Certains langages anciens
Toutes les bases de données ne sont pas égales (SQL Server)
Shell de commande : master.dbo.xp_cmdshell ‘cmd.exe dir c ;’
Commandes de registre : xp_regread, xp_regdeletekey,
Compromettre la confidentialité avec l’injection de string SQL :
Si un système est vulnérable aux injections SQL, certains aspects de la triade
CIA (Confidentiality, Integrity, Availability - Confidentialité, intégrité,
disponibilité) peuvent être facilement compromis.
Qu’est ce que l’injection String SQL ?
Si des requêtes sont créées dynamiquement dans l’application en y
concaténant des chaînes, cela la rend très sensible à l’injection de String
SQL.
Si l’entrée prend une chaîne qui est insérée dans une requête en tant que
paramètre de chaîne, vous pouvez facilement manipuler la requête de
génération à l’aide de guillemets pour former la chaîne selon vos besoins
spécifiques.
Qu’est-ce que le chaînage de requête SQL ?
Lors du chaînage de requêtes, vous essayez d’ajouter une ou plusieurs
requêtes à la fin de la requête réelle.
Vous pouvez le faire en utilisant le ; métacaractère qui marque la fin
d’une requête et permet ainsi d’en démarrer une autre juste après dans
la même ligne.
Compromis de disponibilité :
Il existe de nombreuses façons différentes de violer la disponibilité.
Si un compte est supprimé ou si le mot de passe est modifié, le propriétaire
actuel ne peut plus y accéder.
Les attaquants pourraient également essayer de supprimer des parties de
la base de données, la rendant inutile ou même en supprimant toute la
base de données.
Une autre façon de compromettre la disponibilité serait de révoquer les
droits d’accès des administrateurs ou de tout autre utilisateur, afin que
personne n’ait accès à tout ou partie de la base de données.
Broken Authentication
Contournement d’authentification :
Entrées masquées :
La forme la plus simple est une dépendance à une entrée cachée qui se
trouve dans la page Web / DOM.
Suppression de paramètres :
Si un attaquant ne connaît pas la valeur correcte d’un paramètre, il peut
supprimer complètement le paramètre de la soumission pour voir ce qu’il se
passe.
Navigation forcée :
Si une zone d’un site n’est pas correctement protégée par la configuration,
cette zone du site est accessible par forçage brut.
Jetons JWT
De nombreuses applications utilisent des jetons Web JSON (JWT) pour

permettre au client d’indiquer son identité pour un échange ultérieur
après authentification.
Structure d’un jeton JWT :
Le jeton est codé en base64-url et se compose de trois parties
header.claims.signature
En fonction de l’algorithme, la signature sera ajoutée au jeton. De cette façon,
vous pouvez vérifier que quelqu’un n’a pas apporté le jeton (une modification
au jeton invalidera la signature)
Jetons JWT
Une séquence de base pour obtenir un jeton est la suivante

Jetons JWT
Lorsque le client effectue un appel successif vers le serveur, il attache

le nouveau jeton dans l’en-tête « autorisation ».
Le serveur lit le jeton et valide d’abord la signature.
Après une vérification réussie, le serveur utilise les informations du
jeton pour identifier l’utilisateur.
Réclamations :
Le jeton contient des revendications permettant d’identifier l’utilisateur
et toutes les autres informations nécessaires au serveur.
Pour répondre à la demande, il faut être conscient de ne pas stocker
d’informations sensibles dans le jeton et de toujours les envoyer sur un
canal sécurisé.
Jetons JWT
Signature JWT :
Chaque jeton JWT doit au moins être signé avant de l’envoyer à un client.
Si un jeton n’est pas signé, l’application cliente pourra modifier le contenu
du jeton.
Vous utilisez la fonction « HMAC avec fonction SHA-2 » ou « signature
numérique avec RSASSA-PKCS1-v1_5 / ECDSA / RSASSA-PSS » pour signer
le jeton.
Fissuration JWT :
Avec le HMAC avec les fonctions SHA-2, vous utilisez une clé secrète pour
signer et vérifier le jeton.
Une fois que nous avons compromis cette clé, nous pouvons créer un
nouveau jeton et le signer. Il est donc très important que la clé soit
suffisamment puissante pour qu’une attaque par brute force ou par
dictionnaire hors ligne.
Jetons JWT
Types de jetons :
En général, il existe deux types de jetons :
le jeton d’accès
le jeton d’actualisation.
Le jeton d’accès est utilisé pour effectuer des appels d’API vers le serveur.
Les jetons d’accès ont une durée de vie limitée
c’est là qu’intervient le jeton d’actualisation.
Une fois que le jeton d’accès n’est plus valide, une demande peut être faite
auprès du serveur pour obtenir un nouveau jeton d’accès en présentant le
jeton d’actualisation.
Le jeton d’actualisation peut expirer mais leur durée de vie est beaucoup
plus longue. Cela résout le problème d’un utilisateur devant s’authentifier à
nouveau avec ses informations d’identification.
Réinitialisation du mot de passe :
Comment utiliser les questions de sécurité pour la vérification des
utilisateurs :
Les questions de sécurité sont un moyen facile de trouver des informations
sur la validité de l’utilisateur sans lui demander de données de vérification.
Le problème est qu’il n’y a pas beaucoup de types de questions de sécurité et
les réponses sont les mêmes pour de nombreux utilisateurs.
Cela permet à un attaquant de deviner facilement la question et la réponse.
Un moyen facile de rendre plus difficile la question est de laisser
l’utilisateur décider lui-même de la question à laquelle il souhaite
répondre.
A propos du jeton de réinitialisation de mot de passe :
Les jetons de réinitialisation de mot de passe permettent à un utilisateur
de réinitialiser un mot de passe sans informations sûres sur la vérification
de l’utilisateur.
Ils devraient donc être en sécurité. Il devrait être difficile de deviner un tel
jeton.
Le jeton ne doit également être valide que pendant une courte période et
ne doit pas être valide une fois que l’utilisateur a réussi à réinitialiser son
mot de passe.
Journalisation des actions des utilisateurs :
La journalisation à elle seule ne peut empêcher aucune attaque, mais elle
peut faciliter la détermination de l’attaque et la manière dont l’attaquant
a tenté de contourner la sécurité.
Vous pouvez également utiliser des journaux pour déterminer si un
compte a vraiment été détourné et s’il doit être retourné à l’utilisateur
légitime.
Mots de passe sécurisés :
Apprendre à créer des mots de passe forts et comment les stocker de manière
sécurisée.
Nous examinerons les recommandations les plus importantes faites par la
norme de mot de passe NIST.
L’institut national des normes et de la technologie (NIST) est une
agence fédérale non réglementaire au sein du département américain
du commerce.
Sa mission, est de promouvoir l’innovation et la compétitivité
industrielle aux Etats-Unis en faisant progresser la science, les normes
et la technologie de mesure à améliorer la sécurité économique et à
améliorer notre qualité de vie.
Norme de mot de passe NIST :
La norme de mot de passe NIST est une directive qui fournit des
recommandations pour la mise en œuvre de système de mot de passe
sécurisés.
Règle de mot de passe :
Pas de règles de composition.
Aucun indice de mot de passe.
Pas de questions de sécurité.
Pas de changement de mot de passe inutile.
Taille minimale de 8 caractères.
Prendre en charge tous les caractères.
Indicateur de force.
Vérification par rapport aux mauvais choix.
Convivialité :
Autoriser le collage dans la saisie de MdP
Permettre d’afficher le MdP
Offrir un indicateur de force
Violation de comptes :
Il est possible de savoir si l’un de vos comptes a été piraté à l’aide de « Have I
Been Pwned » ou « DEHASHED », si tel est le cas, mieux vaut changer vos
mots de passes dès que possible.
Améliorer la sécurité de vos comptes :
Utiliser des mots de passes différents pour vos différents comptes.
Utiliser des phrases de passe.
Utiliser un gestionnaire de mots de passe.
Utiliser l’authentificateur a deux facteurs.
Stockage des mots de passe :
Une fois qu’un mot de passe fort et sécurisé a été créé, il doit également être
stocké de manière sécurisée.
Le NIST donne des recommandations sur la façon dont les applications
doivent gérer les mots de passe et comment les stocker en toute sécurité.
Utiliser le chiffrement et un canal protégé pour demander des mots de passe.
Résistant aux attaques hors ligne.
Utiliser des sels.
Utiliser le hachage.
La dérivation de clé mémoire dur.
Facteur de coût élevé.
Sensitive data exposure
Problèmes :
Transit de donnée non chiffrée
Les données peuvent être sniffées
Xxe
Le xml permet de définir des balises qui seront remplacées par du

contenu lors de l’analyse du document xml.
Il existe 3 types d’entités
Entités internes
Entités externes
Entités paramètre
Une entité doit être créée dans la définition de type de document DTD
Une attaque xxe est une attaque contre une application qui analyse
une entrée xml.
Elle se produit lorsque l’entrée xml contenant une référence à une
entité externe est traitée par un analyseur xml faiblement configuré.
Cette attaque peut entrainer la divulgation de donnée confidentiel,
DOS, la falsification de requête côté serveur, la numérisation des ports
de la machine sur laquelle l’analyseur se trouve.
Les attaques peuvent inclure la divulgation de fichier locaux, qui
peuvent contenir des données sensible telles que les mots de passe
ou données d’utilisateurs privées.
En utilisant des schémas de fichier ou des chemins relatifs dans
l’identifiant du système.
Etant donné que l’attaque se produit par rapport à l’application qui
traite le document xml, un attaquant peut utiliser cette application de
confiance pour pivoter vers d’autres systèmes internes et divulguer
d’autres contenus internes via des requêtes http ou en lançant une
attaque CSRF sur tout service intégré non protégé.
Dans certaines situations, une bibliothèque de processeurs XML, qui est
vulnérable aux problèmes de corruption de mémoire côté client, peut
être exploitée en déréférençant un uri malveillant, permettant
éventuellement l’exécution de code arbitraire sous le compte de
l’application.
D’autres attaques peuvent accéder à des ressources locales qui peuvent
ne pas arrêter de renvoyer des données.
En général, nous pouvons distinguer les types d’attaque xxe suivants :
Classique dans ce cas une entité est incluse dans une dtd locale
Aveugle aucune sortie et ou erreur ne sont affichés dans la réponse
Erreur essayez d’obtenir le contenu d’une ressource dans le message
d’erreur
Pour notre exemple
On peut définir une dtd dans un fichier externe

Email .dtd sera donc
Si l’analyseur prend en charge les dtd externes, nous pouvons donc faire
Exemple xxe dos
Blind xxe
Dans certains cas, vous ne verrez aucune sortie car bien que votre attaque
ait fonctionné, le champ n’est pas reflété dans la sortie de la page.
Ou la ressource que vous essayez de lire contient un caractère XML illégal
qui provoque l’échec de l’analyseur.
XXE mitigation
Afin de vous protéger contre les attaques xxe, vous devez vous assurer de
valider l’entre reçue d’un client non fiable. Dans le monde Java ,vous
pouvez également demander à l’analyseur d’ignorer complètement la dtd.
Si vous n’êtes pas en mesure de désactiver complètement la dtd, vous
pouvez également demander à l’analyseur xml d’ignorer les entités
externes.
Broken Access Control
Référence directes aux objets
Les références d’objet directes sont lorsqu’une application utilise une
entrée fournie par le client pour accéder aux données et aux objets
Cela peut ressembler à :
Insecure references objet direct
Celles-ci sont considérées comme non sécurisées lorsque la référence

n’est pas correctement gérée. Elle permet des contournements
d’autorisation ou la divulgation de donnée privées qui pourraient être
utilisées pour effectuer des opérations ou accéder à des donnes que
l’utilisateur ne devrait pas être en mesure d’effectuer ou accéder.
Disons qu’en tant qu’utilisateur, vous allez voir votre profil et l’url
ressemble a quelque chose comme ça :
Et vous pouvez y voir votre profil.
Que se passe-t’il si vous accédez à :
Ou utilisez un autre numéro à la fin. Si vous pouvez manipuler le

numéro et afficher le profil d’un autre, la référence d’objet n’est pas
sécurisée.
Bien sûr, cela peut être vérifié ou étendu au-delà de la méthode
get pour afficher les données, mais aussi pour les manipuler.
Contrôle d’accès horizontal et vertical
Souvent, nous pensons au contrôle d’accès en terme de rôle. C’est

le contrôle d’accès vertical.
Cependant les utilisateurs ayant le même rôle peuvent accéder
aux données les uns des autres. Il s’agit du contrôle d’accès
horizontal.
Utilisation de références correctes
Peu d’applications l’utilisent, mais vous pouvez utilisez des références

indirectes.
Dans ce cas vous pouvez exécuter vos références via un hachage, un
codage ou une autre fonction sur le serveur afin que l’id que le client
voit ne soit pas la référence réelle que le serveur gère. Cela réduira en
partie l’efficacité et est toujours susceptible d’être deviné, forcé par la
force ou inversé.
Contrôle d’accès et API
Les bonnes options telles que les jetons web json jwt sont une bonne
option pour l’authentification API et le contrôle d’accès en utilisant
une combinaison des revendications et une signature
numérique/cryptographique pour valider le consommateur.
Security Misconfiguration
Les attaquants tenteront souvent d'exploiter des failles non corrigées
ou d'accéder aux comptes par défaut, aux pages inutilisées, aux
fichiers et répertoires non protégés, etc. pour obtenir un accès non
autorisé ou une connaissance du système.
Une mauvaise configuration de la sécurité peut se produire à

n'importe quel niveau d'une pile d'applications
La plate-forme, le serveur Web, le serveur d'applications, la base de

données, les infrastructures, le code personnalisé et les machines
virtuelles, conteneurs ou stockage préinstallés
Les scanners automatisés sont utiles pour détecter les erreurs de

configuration
XSS
Le cross site scripting est une vulnérabilité qui combine l’allocation de

balises html/script en entrée qui sont rendues sur un navigateur sans
encodage ni désinfection
Emplacement courant :
Champs de recherche renvoyant à l’utilisateur une chaine de
recherche
Champs de saisie qui font echo aux données utilisateurs
Message d’erreur renvoyant le texte fourni par l’utilisateur
Toute page qui affiche des données fournies par l’utilisateur
Message board
Commentaire sous form libre
En-têtes http
XSS
Vol de cookie de session
Création de fausses demandes
Création de faux champs sur une page pour collecter les informations
d’identification
Rediriger votre page vers un site ‘’non convivial’’
Création de demandes qui se font passer pour des utilisateurs valides
Vol d’informations confidentielles
Exécution de code malveillant sur un système d’utilisateur final
Insertion de contenu hostile et inapproprié
Les attaques xss donnent du crédit au phishing en utilisant des noms de
domaine existant et sûr
XSS
Réflechi
Le contenu malveillant d’une demande utilisateur est affiché à
l’utilisateur d’un navigateur web
Le contenu malveillant est écrit dans la page après la réponse
du serveur
L’ingénierie sociale est requise
Fonctionne avec les privilèges du navigateur hérités de
l’utilisateur dans le navigateur
XSS
Dom based
Le contenu malveillant d’une demande de l’utilisateur est utilisé
par les scripts côté client pour écrire du html sur sa propre page
Similaire au xss réfléchi
Fonctionne avec les privilèges du navigateur hérités de l’utilisateur
dans le navigateur
XSS
Stocké
Le contenu malveillant est stocké sur le serveur (bdd, fichier) et
affiché ultérieurement aux utilisateurs
L’ingénierie sociale n’est pas requise
Insecure Deserialization
La sérialisation est le processus de transformation d’un objet en un

format de données qui peut être restauré ultérieurement.
Les gens sérialisent souvent des objets afin de les enregistrer dans
le stockage ou de les envoyer dans le cadre de communication.
La désérialisation est l’inverse de ce processus qui prend des
données structurées à partir d’un certain format et les reconstruit
en un objet.
Aujourd’hui le format de données le plus populaire pour la
sérialisation des données est le JSON avant cela c’était le XML.
De nombreux langages de programmation offrent une capacité
native de sérialisation d’objet.
Ces formats natifs offrent généralement plus de fonctionnalités
que le JSON ou le XML, y compris la personnalisation du processus
de sérialisation. Malheureusement, les fonctionnalités de ces
mécanismes de désérialisation natifs peuvent être réutilisées pour
un effet malveillant lors de l’utilisation de données non fiables.
Il a été constaté que les attaques contre les désérialiseurs
permettaient des attaques par déni de service, contrôle d’accès et
exécution de code à distance.
Langage affecté connu
PHP
Python
Rubis
Java
C
C++
Vulnérabilités connues
La façon dont nous créons des logiciels a changé.

La communauté open source est entrain de mûrir et la
disponibilité des logiciels open source est devenue prolifique sans
égard à la détermination de la provenance des bibliothèques
utilisées dans nos applications.
Plus de 10 millions de référentiels de code GitHub
1 million de référentiels de code sourceForge
2500 référentiels binaires publics
Certains référentiels ont des normes d’éditeur strictes
Certains référentiels appliquent la distribution du code source
Aucune garantie que le code source publié est le code binaire publié
Certains référentiels permettent la republication d’un ensemble différent
de bits pour la même version
Certains référentiels vous permettent de supprimer les artefacts publiés
De nombreux systèmes d’emballage diffèrent : y compris pour le même
langage
Différents systèmes de coordonnées et niveaux de granularité
Questions à se poser
Mon composant est-il ancien ou/et stable ?

Mon composant est-il impopulaire ?
Mon manque de mises à niveau était-il un choix délibéré ou un
manque de connaissances ?
Pour les composants analysés dans 25 000 applications,
il a été constaté que :
8% des composants de 2 ans n’avaient pas de version plus récente
23% des composants de 11 ans n’avaient pas de version plus récente
Les composants les plus anciens constituent la majorité des risques
Manque de supervision et gestion log
L'exploitation de manque de supervision et de gestion de log est le

fondement de presque tous les incidents majeurs.
Les attaquants comptent sur le manque de surveillance et de
réponse rapide pour atteindre leurs objectifs sans être détectés.
Une stratégie pour déterminer si vous disposez d'une surveillance
suffisante consiste à examiner les journaux après les tests de
pénétration.
Les actions des testeurs doivent être enregistrées suffisamment
pour comprendre les dommages qu'ils ont pu infliger.
La plupart des attaques réussies commencent par une détection
de vulnérabilité. Permettre à de telles sondes de se poursuivre
peut augmenter la probabilité de réussite de l'exploitation à près
de 100%.
En 2016, l'identification d'une violation prenait en moyenne

191 jours - beaucoup de temps pour que les dommages soient
infligés.
SOMMAIRE
INTRODUCTION
PROTOCOLE HTTP
AUTHENTIFICATION
D'APPLICATIONS HTTP
AUTHENTIFICATION
Authentification HTTP Basic Access
ÉTAPE 1 : le client fait une demande d'information, en envoyant un

nom d'utilisateur et mot de passe au serveur en clair.
ÉTAPE 2 : le serveur répond avec l'information désirée ou une erreur.
base64 encoding (not cryptage) pour générer notre chaîne
cryptographique qui contient les informations de nom d'utilisateur et
de mot de passe. HTTP Basic n'a pas besoin d'être implémenté sur SSL,
mais si vous ne le faites pas, il n'est pas du tout sécurisé. Donc, je ne
vais même pas à l'idée de l'utiliser sans.
Pour :
C'est simple à mettre en œuvre, de sorte que vos développeurs clients auront moins de travail à faire et prendre
moins de temps à livrer, de sorte que les développeurs pourraient être plus susceptible de vouloir utiliser votre
API.
contrairement à Digest, vous pouvez stocker les mots de passe sur le serveur dans n'importe quelle méthode
de cryptage que vous aimez, comme bcrypt, ce qui rend les mots de passe plus sûr.
un seul appel au serveur est nécessaire pour obtenir l'information, ce qui rend le client légèrement plus rapide
que les méthodes d'authentification plus complexes pourraient être.
Inconvénients:
SSL est plus lent à exécuter que le HTTP de base, donc les clients sont un peu plus lents.
Si vous n'avez pas le contrôle des clients, et ne pouvez pas forcer le serveur à utiliser SSL, un développeur
pourrait ne pas utiliser SSL, causant un risque de sécurité.
En résumé – si vous avez le contrôle des clients, ou pouvez vous assurer qu'ils utilisent SSL, HTTP Basic est un
bon choix. La lenteur de la SSL peut être annulée par la vitesse de une seule demande.
Authentification D'accès par HTTP Digest
L'authentification d'accès Digest utilise le hachage (I. e digest signifie "couper en

petits morceaux") méthodes pour générer le résultat cryptographique.
L'authentification HTTP Digest access est une forme plus complexe
d'authentification qui fonctionne comme suit :
ÉTAPE 1 : un client envoie une requête à un serveur.
ÉTAPE 2 : le serveur répond avec un code spécial (appelé nonce i.e. n umber used
only once ), une autre chaîne représentant le "1519710920 realm 1519660920" (un
hash) et demande le client à authentifier.
ÉTAPE 3 : le client répond avec ce nonce et une version cryptée du nom
d'utilisateur, du mot de passe et du domaine (un hachage).
ÉTAPE 4 : le serveur répond avec les informations demandées si le hachage du
client correspond à leur propre hachage du nom d'utilisateur, mot de passe et
domaine, ou une erreur sinon.
Pour :
Pas de noms d'utilisateur ou des mots de passe sont envoyés au serveur en clair,
ce qui rend une connexion non-SSL plus sûre qu'une requête HTTP de base qui
n'est pas envoyée via SSL. Cela signifie que SSL n'est pas nécessaire, ce qui rend
chaque appel un peu plus rapide.
Inconvénients :
Pour chaque appel nécessaire, le client doit en faire 2, ce qui rend le processus
légèrement plus lent que HTTP Basic.
HTTP Digest est vulnérable à un homme-dans-le-milieu attaque de sécurité qui
signifie essentiellement qu'il pourrait être piraté.
HTTP Digest empêche l'utilisation du cryptage de mot de passe fort, ce qui
signifie que les mots de passe stockés sur le serveur pourraient être piraté.
SOMMAIRE
INTRODUCTION
PROTOCOLE HTTP
AUTHENTIFICATION
D'APPLICATIONS HTTP
LE FIREWALL RÉSEAU
DANS LA PROTECTION
D'APPLICATIONS HTTP
Définition
Un pare-feu, est un outil permettant de protéger un ordinateur

connecté à un réseau ou à l’internet.
Il protège d’attaques externes (filtrage entrant) et souvent de

connexions illégitimes à destination de l’extérieur (filtrage sortant)
initialisées par des programmes ou des personnes.
Le pare-feu filtre les flux grâce aux politiques de filtrage qui sont des
règles qui autorise ou non les flux
Le firewall réseau, son rôle et ses fonctions.
Pare-feu ou firewall : filtre les accès entre l’Internet et le réseau

local ou entre 2 réseaux locaux
Localisation stratégique (avant/après le routeur, avant/après NAT…)
Suivant la politique de sécurité, le filtrage est appliqué
différemment sur les interfaces d’entrées et de sorties (blocage
des adresses IP privées entrantes…)
Filtrage de paquets
Permet de router les paquets entre les hôtes internes et externes de

manière sélective
Intervient à différents niveaux, du moment où chaque paquet possède
un en-tête spécifique
Adresse IP source ou destination
Port TCP ou UDP source ou destination
Flags d’en-tête TCP (SYN, ACK…)
Type de message ICMP ou HTTP filtrage applicatif…)
Peut également intervenir au niveau des en-têtes
de trame (filtrage des adresses MAC
source ou destination)
Filtrage sur les entrées
Le pare-feu peut également empêcher les connexions entrantes en opérant sur

le bit ACK de l’en-tête TCP
Lors d’une demande de connexion, le bit ACK du premier segment TCP est à 0,
les bits ACK des segments suivants sont généralement tous à 1
Il suffit donc de bloquer les segments entrants avec le bit ACK à 0, les segments
suivants pour cette connexion ne seront pas pris en compte
Règles d’un pare-feu
Les règles décrivent l’ensemble des services qui

doivent être acceptés par le pare-feu
La stratégie appliquée est : tout ce qui n’est pas
explicitement autorisé est interdit (et non le
contraire…)
Elles sont basées sur les informations des
segments ou des paquets
Les caractéristiques de chaque paquet sont
comparées aux règles, les unes après les autres
Si la règle correspond aux caractéristiques du
paquet, celui-ci est acceptée
DMZ : principe
Zone démilitarisée (DMZ

DeMilitarised Zone) : zone de réseau
privée ne faisant partie ni du réseau
interne ni de l’Internet
À la manière d'une zone franche au

delà de la frontière, la DMZ permet
de regrouper des ressources
nécessitant un niveau de protection
intermédiaire.
DMZ : 2 niveaux de pare-feu
Un niveau supplémentaire de
sécurité peut être introduit avec
un 2ème pare-feu
Les règles d’accès sur le pare-feu

du réseau Interne sont plus
restrictives.
La DMZ est située entre les 2 pare-

feux (DMZ « en sandwich ») avec
des règles moins restrictives
introduites par le 1er pare-feu
Architecture Pare-feu
Selon les risques et moyens financiers d’une entreprise, plusieurs

architectures de déploiements de firewalls existent.
Concept de tiering :
Le tier est le nombre de zones protégées par un ou plusieurs firewalls.
Selon la taille et les besoins de l’entreprise, il est intéressant d’adopter le
tiering adéquat sachant que plus le tier est élevé et plus la sécurité est
renforcée.
Tier 1
Cette architecture protège un réseau local simple face à un réseau non fiable tel
qu’internet.
C’est le genre d’architecture que vous pouvez avoir à votre domicile
Problème 1 : les flux depuis Internet vers le serveur web traversent
systématiquement le LAN.
Problème 2 : le pare-feu est un point névralgique de l'architecture
Problème 3 : l'architecture ne propose aucune mesure de protection contre la
défiguration du site web
Tier 2
Le premier problème peut être aisément corrigé en connectant directement le
serveur web de l'entreprise sur une des interfaces réseau du pare-feu.
Cette architecture corrige correctement le premier problème (les flux à destination
des serveurs Web ne circulent plus au travers du LAN) mais pas les deux autres dans
la mesure où le pare-feu constitue toujours un point critique de l'architecture et où
aucune protection spécifique n'est mise en place pour prendre en compte le risque
de défiguration du site web.
Afin de prendre en compte le second problème, il convient de mettre en place deux pares-feux
L'un est placé en entrée de LAN (pare-feu interne, FWi) et l'autre à la frontière du WAN (pare-feu externe,
FWe). Le nœud entre DMZ, FWi et FWe est par exemple assuré par un commutateur réseau
La mise en place de ces deux pares-feux rend chacun de ces équipements non critiques. La compromission
de FWe ne permet pas à un attaquant d'attaquer directement le LAN (FWi est toujours en coupure), et la
compromission de FWi n'est pas aisée car, sauf en cas de compromission de FWe, aucun paquet de
l'attaquant n'est routé vers Fwi
La mise en place de ces deux pares-feux rend chacun de
ces équipements non critiques. La compromission de FWe
ne permet pas à un attaquant d'attaquer directement le
LAN (FWi est toujours en coupure), et la compromission
de FWi n'est pas aisée car, sauf en cas de compromission
de FWe, aucun paquet de l'attaquant n'est routé vers Fwi
Plus les équipements seront différents, plus le risque qu'un attaquant ait
connaissance d'une vulnérabilité exploitable sur les deux pares-feux sera faible
Par ailleurs, il est fortement recommandé d'ajouter sur la DMZ un serveur mandataire (proxy) en charge
d'effectuer un filtrage applicatif des échanges (dépollution, filtrage des contenus dangereux, maintien d’une
liste blanche des sites accessibles et/ou d’une liste noire des sites interdits) entre les machines du LAN et les
serveurs auxquels elles accèdent sur Internet
Il est important de noter que, sur cette nouvelle architecture, la DMZ est en
coupure sur l'ensemble des flux. Il est donc préférable de la placer en coupure
physique sur les flux selon le principe présenté sur la Figure 5. L'utilisation d'une
coupure physique en lieu et place d'une coupure logique permet physiquement
de garantir qu'aucune communication n'est possible entre les deux pare-feux
sans passer par la DMZ. Sans cette coupure, il existe un risque qu’un flux sortant
soit adressé au WAN directement sans qu’il ne soit filtré au niveau applicatif
L'architecture obtenue est malheureusement encore imparfaite car elle ne
fournit toujours aucun mécanisme permettant de protéger le serveur web
contre une éventuelle défiguration.
Tier 3
La prise en compte de cette dernière menace nécessite de mettre en place deux DMZ : - une zone de service dite interne DMZi
connectée directement à FWi et destinée à recevoir un ensemble de services fonctionnels ; - une zone de service dite externe
DMZe connectée directement à FWe et destinée à recevoir des services de sécurité.
Ainsi, pour les flux entrants :

La zone de service DMZi contient le serveur web proprement dit ;
Tandis que la zone DMZe contient un reverse proxy dont le rôle est d'assurer un filtrage des requêtes applicatives des
internautes. Différents types de filtrage peuvent ainsi être effectués (analyse de requêtes suspectes avec des tailles d'URL trop
grandes, contenant des mots clefs associés à des bases de données, etc.). Contrairement au proxy qui analyse prioritairement
les réponses des serveurs externes aux requêtes, le reverse proxy analyse prioritairement les requêtes émanant de l’extérieur
Pour les flux sortants :

La zone DMZi fournit un proxy cache destiné à stocker temporairement les dernières pages ayant été consultées sur Internet.
Ce service permet une accélération substantielle des requêtes ultérieures vers cette même page ;
La zone DMZe fournit un proxy tel que celui décrit dans les précédentes architectures
La protection du serveur web contre la défiguration s'effectue essentiellement grâce au reverse proxy de la DMZe
Cependant, il est important de comprendre que cette mesure seule ne permet pas de garantir la sécurité du serveur web.
En effet, il existe de nombreuses façons de défigurer une page web
Les deux DMZ de la figure précédente étant en coupure logique, il apparaît à

nouveau sensé de les placer en coupure physique. Si l'on effectue une telle
modification, il est nécessaire de faire apparaître un troisième pare-feu entre ces
deux DMZ (FWm pour « filtre médian »). Le rôle de ce pare-feu est de permettre
un cloisonnement physique entre les serveurs eux-mêmes
SOMMAIRE
INTRODUCTION
PROTOCOLE HTTP
AUTHENTIFICATION
D'APPLICATIONS HTTP
SÉCURISATION
DES FLUX
AVEC SSL/TLS
Rappels des techniques cryptographiques
utilisées dans SSL et TLS.
La maîtrise de SSL nécessite la compréhension des algorithmes de

chiffrement, des fonctions relatives aux empreintes de messages
(comme les fonctions de type hash ou non réversibles), et des signatures
numériques. Ces techniques pourraient faire l'objet d'un ouvrage à elles
seules (voir par exemple [AC96]) et constituent les bases de la
confidentialité, de l'intégrité et de l'authentification.
Il existe deux types de chiffrement :
1. Chiffrement à clé partagée → symétrique

2. Chiffrement par paire de clé → asymétrique
Bien sûr, il n’est pas étonnant de trouver le mixte de ces deux types
Algorithmes de chiffrement
La différence en termes de sécurité

Le chiffrement symétrique implique que l’émetteur et le récepteur connaissent
tout deux la clé secrète, dans le cas d’un échange
Alors que le chiffrement asymétrique ne nécessite aucun partage de données
secrètes, mais d’une donnée publique, nommé « la clé public » entre les
différents interlocuteurs
La combinaison des deux
Il est possible de combiner ces deux types de chiffrements, pour plus de
sécurité, mais cela implique plus d’instructions donc plus de consommation
énergétique et plus long sera le déchiffrement total
Les échanges par certificats TLS fonctionnent ainsi
Afin de permettre l'établissement d'un canal de communication chiré et intègre,
les deux parties doivent s'entendre sur les algorithmes et les clés à utiliser. Dans
cette étape de négociation, plusieurs messages sont échangés. Un exemple
complet est donné à la Figure 1. On suppose pour l'exemple que la suite
cryptographique négociée est TLS_RSA_WITH_RC4_128_MD5, ce qui est assez
classique.
ClientHello
La négociation commence avec l'envoi par le client d'un message ClientHello.

Dans ce message, le client propose un ensemble de suites cryptographiques
qu'il est capable de mettre en œuvre.
Chacune de ces suites cryptographiques décrivent les mécanismes
cryptographiques qui seront utilisés pour les quatre fonctions suivantes :
établir les éléments secrets de session ; authentifier les parties ;
chiffrer les données applicatives ; protéger les
données applicatives en intégrité.
Réponse du serveur
Lorsque le serveur reçoit le ClientHello, deux cas peuvent se produire:

aucune des propositions du client n'est jugée acceptable. Le serveur met alors n
à la connexion avec un message de type Alert ;
dans le cas contraire, le serveur choisit une suite cryptographique parmi celles
proposées par le client et émet le message ServerHello qui fait état de son choix.
Ce message contient également une valeur aléatoire, nommée ServerRandom.
Le serveur envoie ensuite son certificat (dans le message Certificate) et envoie un
message ServerHelloDone pour indiquer qu'il attend maintenant une réponse du client.
Fin de la négociation
Une fois la suite choisie et le certificat reçu, le client vérifie la chaîne de certification.
Si le certificat n'est pas validé, le client émet une alerte qui met fin à la connexion. Sinon, il poursuit et envoie
un message contenant le pre master secret chiffré : le ClientKeyExchange.
À partir de là, le client et le serveur disposent tous les deux du pre master secret (le client l'a tiré au hasard, et
le serveur peut déchiffrer le ClientKeyExchange), ainsi que d'éléments aléatoires publics échangés lors des
messages ClientHello et ServerHello.
Ces éléments partagés sont alors dérivés pour fournir les clés symétriques qui seront utilisées pour protéger
le trac en condentialité
Des messages ChangeCipherSpec sont échangés pour indiquer l'activation des paramètres
(algorithmes et clés) négociés. Les messages Finished sont
donc les premiers à être protégés cryptographiquement,
et contiennent un haché de l'ensemble des messages
échangés pendant la négociation, afin de garantir a
posteriori l'intégrité de la négociation.
Die-Hellman éphémère
Un défaut du mécanisme d'échange de clé par chiffrement RSA est qu'il

ne protège pas les communications passées contre une divulgation de la
clé privée du serveur. En et, il est facile de se convaincre qu'une fois la clé
privée récupérée, il suffit à un attaquant de s'en servir pour déchirer le
message ClientKeyExchange, récupérer le pré master secret et obtenir
les clés de session : une attaque passive est possible sur toutes les
communications passées et futures.
SOMMAIRE
INTRODUCTION
PROTOCOLE HTTP
AUTHENTIFICATION
D'APPLICATIONS HTTP
CERTIFICATS
NUMÉRIQUE
X.509
X.509 est une norme spécifiant les formats pour les certificats à clé
publique, les listes de révocation de certificat, les attributs de certificat,
et un algorithme de validation du chemin de certification, définie par
l'Union internationale des télécommunications
Ce format garantit l’authenticité de la clé publique transmise
Un certificat de type X.509 est délivré par une Autorité de Certification

(CA en anglais), donc un moyen sûr de garantir l’authenticité lors d’un
échange
X.509 contient différent attribut :
Version
Numéro de série
Algorithme de signature du certificat
DN (Distinguished Name) du délivreur (autorité de certification)
Validité (dates limites) ➢Pas avant ➢Pas après
DN de l'objet du certificat
Informations sur la clé publique ➢Algorithme de la clé publique
➢Clé publique
En cryptographie, une Autorité de Certification (CA pour Certificate
Authority en anglais) est un tiers de confiance permettant
d'authentifier l'identité des correspondants
Un CA délivre des certificats décrivant des identités numériques et met
à disposition les moyens de vérifier la validité des certificats qu'elle a
fournis
Grâce aux CAs, nous sommes en mesure de chiffrer nos flux tout en
garantissant l’authenticité du fournisseur
Vous pouvez voir les informations d’un CA en ouvrant la fiche
d’information depuis votre navigateur Web une fois connecté sur un
site en HTTPS
Il existe deux types de CA :
CA reconnu : autorité étant un organisme reconnu, les logiciels tel
que les navigateurs Web implémentent dans leur code source les
certificats des CA, afin de les vérifier lors d’une connexion
CA autonome : l’inverse, ce sont les CAs n’étant pas un organisme

reconnu, les navigateurs Web n’implémentent pas leurs certificats,
de ce fait, le navigateur prévient l’utilisateur de l’utilisation d’un
certificat non reconnu (le petit cadenas rouge)
Assurez-vous de choisir une AC dont les racines et les « ancres de confiance »
sont intégrées à un maximum de navigateurs, systèmes d’exploitation,
applications et périphériques. C’est ce qu’on appelle l’ubiquité.
La confiance d’une AC se mesure à l’ampleur de son intégration.[I1] Ce facteur
est d’une importance capitale : personne ne veut d’une AC « moins universelle »
ou qui rencontre des problèmes avec ses ancres de confiance.
L’histoire de l’entreprise et son ancienneté comptent également. Si une AC
existe depuis 20 ans, ce n’est sûrement pas un hasard. Elle a travaillé dur à
établir sa réputation et des relations de confiance avec ses clients, et a prouvé
qu’elle pouvait également préconiser les meilleures solutions, forte de son
expérience et de son expertise.
Quelle autorité de certification choisir ?
Leur sérieux
Leur gamme de produits
Leur capacité à répondre à vos besoins
Outre les critères techniques (qui sont normalement la base de votre
choix), vous pourrez sélectionner une autorité en fonction de sa notoriété
(auprès de votre public) et de ses prix.
Pourquoi choisir X509 TBS ?
Un très bon rapport qualité/prix

Un service en français
Une bonne reconnaissance dans les navigateurs
La réputation : créé en 1996, TBS CERTIFICATS a fait ses preuves
Un service qui s'appuie sur une infrastructure de certification aux normes
WebTrust
Les délais : 3 jours à réception de votre dossier complet
Un service optionnel de livraison clef-en-main
Le support technique : premier niveau en français avec deuxième niveau
ouvert 24h/24 en anglais
Pourquoi choisir Thawte ?
Un très bon rapport qualité/prix

Des certificats délivrés uniquement après authentification forte
La réputation : Créé en 1996, Thawte est membre de la famille DigiCert.
La part de marché : 40 à 50% du marché mondial, plus de 50% du
marché français (certificats serveurs)
Les délais : 2 à 3 jours à réception de votre dossier complet
Les principaux types de certificats X509 serveur !
Le support technique Thawte : disponible 24h/24 5j/7 (en anglais par
téléphone, email ou chat en ligne).
Pourquoi choisir DigiCert ?
La plus grande notoriété auprès du grand public.

Des certificats délivrés uniquement après authentification forte.
Le suivi client par TBS CERTIFICATS : Nous conservons l'historique de vos
certificats, nul besoin de renvoyer la documentation à chaque nouvelle
demande !
Le support technique : premier niveau en français avec deuxième niveau
en anglais.
WAF
Un pare-feu applicatif Web (WAF) protège la couche application et est

spécifiquement conçu pour analyser chaque requête HTTP/S au niveau de la
couche application.
Il est généralement conscient de l’utilisateur, de la session et de l’application, et
connaît les applications Web impliquées et les services qu’elles offrent.
De ce fait, on peut considérer un WAF comme un intermédiaire entre l’utilisateur
et l’application elle-même, analysant toutes les communications avant qu’elles
n’atteignent l’application ou l’utilisateur.
Les WAF traditionnels garantissent que seules les actions autorisées (selon la
politique de sécurité) peuvent être effectuées. Pour de nombreuses organisations,
les WAF constituent une première ligne de défense fiable pour les applications, en
particulier pour se protéger contre le Top 10 de l’OWASP, la liste fondamentale des
vulnérabilités applicatives les plus fréquentes
Modes de déploiement d’un WAF :
Basé en cloud + entièrement géré en tant que service - c’est une excellente option si
vous avez besoin de la manière la plus rapide et la plus simple de placer un WAF au-
devant de vos applications (surtout si vous avez des ressources internes limitées en
matière de sécurité/informatique)
Basé en cloud + géré en interne - obtenez toute la flexibilité et la portabilité des
politiques de sécurité du cloud tout en gardant le contrôle de la gestion du trafic et
des paramètres de sécurité
Basé en cloud + provisionné automatiquement - c’est la façon la plus simple de
démarrer avec un WAF en cloud, en déployant la politique de sécurité de façon
simple et rentable
WAF avancé sur site (appliance virtuelle ou matérielle) - répond aux besoins les plus
exigeants en matière de déploiement, lorsque la flexibilité, les performances et des
préoccupations de sécurité plus poussées sont essentielles à la mission
SOMMAIRE
INTRODUCTION
PROTOCOLE HTTP
AUTHENTIFICATION
D'APPLICATIONS HTTP
CONFIGURATION
DU SYSTÈME
ET DES LOGICIELS
Un site internet ne fonctionne pas de lui même, mais repose sur de
nombreux composants nécessaires à son fonctionnement.
De multiples “couches” permettent à l’application web de fonctionner, de

l’infrastructure réseau, aux librairies utilisées pour construire l’application :
Couche réseau (tous les composants qui permettent au site web
d’être accessible par le monde entier, ou pas)
Couche serveur (la machine elle-même qui héberge le site)
Couche Système d’Exploitation (Windows, Linux…)
Couche applicative (serveur microsoft IIS, Apache… le composant
logiciel qui fait tourner votre site internet)
Couche de librairies (du code prêt à être utiliser, utilisé par les
développeurs pour construire l’application web)
Le site web lui-même
Toutes ces couches ont leurs propres paramètres de sécurité, et
leurs potentielles vulnérabilités.
Par exemple, les comptes par défaut, présents dans de nombreux
composants qu’il s’agisse de bases de données, ou de serveurs web, sont
très dangereux. De nombreux comptes par défaut utilisant “administrator”
comme login, et “password” comme mot de passe sont encore aujourd’hui
fournis avec des logiciels ou serveurs et doivent absolument être
supprimés lors de l’installation de ces composants dans votre
environnement web.
Un autre exemple simple est l’affichage des contenus des dossiers
(directory listing), qui permet à n’importe qui de lister les fichiers présents
dans un dossier donnée, comme par exemple dans le dossier racine de
votre site web, rendant accessible le code source de l’application, ou
d’autre éléments.
Quelles en sont les conséquences ?
Si votre application web souffre de tels trous de sécurité, les

conséquences peuvent être assez sévères, suivant la nature de votre
site web et en fonction de la faille elle-même.
Généralement, les attaques donnent accès aux pirates à des données
que vous ne souhaitez pas divulguer, ou à des fonctionnalités non
autorisées. Cela peut également donner lieu à une compromission
totale du système, laissant l’attaquant faire ce que bon lui semble sur
vos serveurs (voler la base de données, changer des règles business,
installer des malwares, éteindre votre site ou le supprimer…)
Que faire pour éviter ces vulnérabilités ?
Un bon niveau de sécurité commence dans une architecture web

qui assure une bonne séparation des différents composants de
l’application (base de données, serveur d’applications…)
Adopter des procédés automatisés ou répétables pour mettre en place
un nouvel environnement web, ou ajouter des serveurs. Utiliser des
checklists peut aussi être une bonne pratique. L’objectif est de s’assurer
que la mise en place de nouveaux serveurs ou composants n’introduira
pas de vulnérabilité.
Dans tous les case, ces procédés, process, checklist devront être
maintenus et revus par une vraie équipe comprenant des architectes
matériels, réseaux et logiciels. Travailler seul sur un tel mécanisme n’est
clairement pas une bonne idée.
S’assurer que vous avez une politique de maintenance solide est également un
point clé pour la sécurité web. Correctement mettre en place des serveurs et des
applications ne sera pas suffisant si vous ne les mettez pas à jour régulièrement.
Systèmes d’exploitation, firmware, le langage de programmation lui-même (tel
que PHP)… tous ces éléments doivent être maintenus à jours afin d’être certain
que les nouvelles failles de sécurité (rendues publiques) ne seront pas exploitées
sur votre système.
Vous avez très probablement entendu parlé de la vulnérabilité “Heartbleed”. Les
pirates ont commencé à exploiter massivement cette faille dès que cette dernière
a été rendue publique (et certain avant qu’elle le soit). Mettre à jour la librairie
“Open SSL” est une des étapes nécessaires afin d’éviter l’exploitation de la
vulnérabilité. Si vous ne le faites pas, votre site, s’il utilise Open SSL, sera vulnérable
à une attaque sur les données que vous aurez tenté de protéger avec SSL.
Effectuer un audit de sécurité, test d’intrusion d’application web est
également critique, afin d’être certain que rien n’a été oublié et obtenir la
confirmation que la plateforme est suffisamment sécurisée !
Contactez-nous pour plus d’information à ce sujet, VAADATA fourni des

services de tests d’intrusion web.
Ces failles n’affectent pas seulement les environnements de production.
Tout autre environnement est concerné, comme les environnements de
tests qualité (QA), préproduction, staging, recette… Ces plateformes
doivent être correctement gérées afin d’éviter que des attaques soient
réalisées.
SOMMAIRE
INTRODUCTION
PROTOCOLE HTTP
AUTHENTIFICATION
D'APPLICATIONS HTTP
PRINCIPE DU
DÉVELOPPEMENT
SÉCURISÉ
Cycle de vie de développement de la sécurité
Les phases MSDL (Microsoft Security Development

Lifecycle ) :
Entrainement
Spécifications
Conception
Implémentation
Vérification
Libérer
réponse
Impliquer l’équipe de sécurité de l’organisation
Il se peut que votre organisation dispose d’un programme de

sécurité d’application officiel qui vous aide dans vos activités de
sécurité tout au long du cycle de vie de développement.
Si votre organisation dispose d’équipes chargées de la conformité
et de la sécurité, veillez à les impliquer avant de développer votre
application. Demandez-leur à chaque phase du Microsoft Security
Development Lifecycle si vous avez manqué des tâches.
Entrainement
Avant de commencer à développer votre application cloud,

prenez le temps de comprendre la sécurité et la confidentialité.
En adoptant cette démarche, vous pouvez réduire le nombre et la
gravité des vulnérabilités exploitables dans votre application.
Vous serez mieux préparé pour réagir de façon appropriée dans ce

paysage de menaces informatiques en perpétuelle évolution.
Spécifications
La phase de détermination des exigences est une étape

essentielle dans la définition de ce que votre application est, et
de ce qu’elle fera lorsqu’elle sera publiée.
La phase de configuration des exigences représente également
un moment de réflexion à mener sur les contrôles de sécurité
que vous allez créer dans votre application.
Pendant cette phase, vous initiez également les étapes que vous
allez suivre tout au long du SDL pour garantir la publication et le
déploiement d’une application sécurisée.
Examiner les questions de confidentialité
et de sécurité
Cette phase est le moment idéal pour prendre en compte les

problèmes fondamentaux de la sécurité et de la confidentialité.
La définition des niveaux acceptables de sécurité et de
confidentialité au début d’un projet aide une équipe à :
Comprendre les risques associés à des problèmes de sécurité.
Identifier et résoudre les bogues de sécurité pendant le
développement.
Appliquer des niveaux établis de sécurité et de confidentialité
tout au long de l’ensemble du projet.
Poser des questions de sécurité
Mon application contient-elle des données sensibles ?

Mon application collecte-t-elle ou stocke-t-elle des données qui exigent que je me conforme
aux normes du secteur d’activité et aux programmes de conformité ?
Mon application collecte-t-elle ou contient-elle des données clientes ou personnelles
sensibles ?
Mon application collecte-t-elle ou contient-elle des données qui peuvent être utilisées pour
accéder à des renseignements médicaux, financiers ?
Où et comment sont stockées mes données ?
Mon application sera-t-elle disponible au public (sur internet) ou en interne uniquement ?
Comprenez-vous votre modèle d’identité avant de démarrer la conception de votre
application ?
Mon application effectue-t-elle des tâches sensibles ou capitales ?
Mon application déploie-t-elle des activités logicielles à risque ?
Conception
La phase de conception est primordiale dans l’établissement de bonnes

pratiques se rapportant aux spécifications de conception et de
fonctionnement.
Pendant la phase de conception, pensez aussi à la façon dont vous pouvez
appliquer la sécurité en couches, un niveau de défense ne suffisant pas
nécessairement.
Que se passe-t-il si un attaquant franchit votre pare-feu d’applications web
(WAF) ? Vous voulez un autre contrôle de sécurité en place pour vous
défendre contre cette attaque.
Conception
C’est en gardant cette idée à l’esprit que nous abordons les concepts de la conception
sécurisée suivants, ainsi que les contrôles de sécurité dont vous devez tenir compte lorsque
vous concevez des applications sécurisées :
Utilisation d’une bibliothèque de codages sécurisés et d’un framework logiciel.

Recherche des composants vulnérables.
Utilisation de la modélisation des menaces lors de la conception d’une application.
Réduction de votre surface d’attaque.
Adoption d’une stratégie d‘identité en tant que périmètre de sécurité principal.
Obligation d’une nouvelle authentification pour les transactions importantes.
Utilisation d’une solution de gestion de clés pour sécuriser les clés, les informations
d’identification et d’autres secrets.
Protection des données sensibles.
Implémentation de mesures de prévention de défaillance.
Mise à profit de la gestion des erreurs et des exceptions.
Utilisation de la journalisation et des alertes.
Conception
En ce qui concerne le développement, utilisez une bibliothèque de

codages sécurisés et un framework logiciel doté d’une sécurité
intégrée. Les développeurs peuvent utiliser des fonctionnalités
existantes éprouvées plutôt que de développer des contrôles de
sécurité à partir de zéro.
Appliquer des mises à jour aux composants
Conception
Utiliser la modélisation des menaces lors de la conception d’une

application
La modélisation des menaces est le processus consistant à
identifier les menaces de sécurité potentielles pour votre
entreprise et votre application, puis à vérifier que les atténuations
appropriées sont en place
l’Outil SDL de modélisation des menaces
Conception
Réduction de votre surface d’attaque

Le code des fonctionnalités que vous n’avez pas encore publiées.
Le code de prise en charge du débogage.
Les interfaces et protocoles réseau qui ne sont pas utilisés ou qui ont
été dépréciés.
Les machines virtuelles et d’autres ressources que vous n’utilisez pas.
Une analyse de surface d’attaque permet d’identifier :
Les fonctions et parties du système que vous devez passer en revue et
tester à la recherche de failles de sécurité.
Les zones de code à haut risque qui nécessitent une protection de
défense en profondeur (les parties du système que vous devez
défendre).
Lorsque vous modifiez la surface d’attaque et que vous avez besoin
d’actualiser une évaluation des menaces.
Conception
Adopter une stratégie d‘identité en tant que périmètre de sécurité

principal
Voici les choses que vous pouvez faire pour développer une approche
centrée sur l’identité dans le développement d’applications web :
Mettre en application l’authentification multi facteur pour les
utilisateurs.
utilisez une authentification forte et des plateformes d’autorisation.
Appliquer le principe du privilège minimum.
Implémenter l’accès juste-à-temps.
Conception
Obligation d’une nouvelle authentification pour les transactions

importantes
Utilisation d’une solution de gestion de clés pour sécuriser les clés, les
informations d’identification et d’autres secrets
Protection des données sensibles
Utiliser le chiffrement
Éviter le codage effectué de manière irréversible
Implémentation de mesures de prévention de défaillance
Mise à profit de la gestion des erreurs et des exceptions
Utiliser la journalisation et les alertes
Implémentation
L’objectif de la phase d’implémentation est d’établir les meilleures

pratiques en matière de prévention anticipée et de détecter et
supprimer les problèmes de sécurité du code.
Implémentation
Effectuer des révisions de code

Effectuer une analyse du code statique
Valider et nettoyer chaque entrée de votre application
Vérifiez les sorties de votre application
Utiliser des requêtes paramétrables lorsque vous contactez la base
de données
Supprimer des en-têtes de serveur standard
Séparer les données de production
Implémenter une stratégie de mot de passe forte
Valider des chargements de fichiers
Ne pas mettre en cache de contenu sensible
Vérification
La phase de vérification implique un effort complet pour s’assurer que

le code respecte les principes de sécurité et confidentialité établis au
cours des phases précédentes.
Vérification
Rechercher et corriger les vulnérabilités de vos

dépendances d’application
Tester votre application en fonctionnement
Effectuer un test à données aléatoires (fuzzing)
Examiner la surface d’attaque
Effectuer des tests d’intrusion sécurisés
Exécuter des tests de vérification de sécurité
Libérer
La phase de mise en production consiste à préparer un projet pour la

version publique.
Il s’agit notamment de planifier des méthodes permettant d’effectuer
efficacement des tâches de maintenance post-lancement et de
corriger les failles de sécurité susceptibles de se produire plus tard.
Libérer
Vérifier les performances de l’application avant de procéder à son

lancement
Installer un pare-feu d’application web
Créer un plan de réponse aux incidents
Effectuer un examen de final de la sécurité
Certifier la mise en production et l’archivage
Response
La phase post-lancement de réponse se concentre sur l’équipe de

développement disponible et à même de répondre correctement à
tous les rapports des nouvelles menaces et vulnérabilités logicielles.
Response
Exécuter le plan de réponse aux incidents

Analyse des performances d’une application
Application Insights
Azure Security Center

Sécurité Des Applications Web (2702)

Transféré par

Droits d'auteur :

Formats disponibles

Sécurité Des Applications Web (2702)

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sécurité Des Applications Web (2702)

Transféré par

Droits d'auteur :

Formats disponibles

FORMATION SÉCURITÉ

DES APPLICATIONS WEB

Depuis les débuts de l'informatique, les utilisateurs s'intéressaient

Cependant, plus les programmes devenaient conséquents, plus ils

Ces bugs furent généralement l'œuvre du hasard ou de légers

Dans l'ombre naquit un groupe d'utilisateurs qui avaient comme

Au fil des années, les pirates devenaient de plus en plus actifs et

Depuis pas mal de temps, la sécurité est devenue une branche

Une vulnérabilité est une faille (ou défaut de conception ou de

En général, les vulnérabilités sont toujours là, dans chaque système,

Les 3 niveaux les plus connus :

Si vous avez défini un ensemble d’exigences approprié, à quel moment

Vous êtes doté d’une conception saine à partir de laquelle vos

Dans la plupart des entreprises, les connaissances en matière de

Interface utilisateur pour interagir avec l'application

Enregistrement sur support physique des données de l'application

Sont intégrées et coopèrent pour le fonctionnement de l'application.

En anglais, on les appelle aussi des « tiers » (étages)

Tout est sur la même machine

Client / serveur de base, avec 2 éléments

Les services métier / la partie applicative peuvent être :

Soit entièrement coté serveur

Soit découpés entre la partie serveur et la partie client

Client : présentation + applicatif

Serveur : applicatif + gestion donnée

Terminal : client intègre un minimum de la partie présentation

Applicatif : découpé entre client et serveur

Les 3 principaux tiers s'exécutent chacuns sur une machine différente

Très développée de nos jours

Rajoute des étages / couches en plus

Réutilisation de services existants

En général, les divers services s'appuient sur des technologies très

Les services étant plus découpés et distribués, pose plus de

Les tâches liées à la présentation requièrent

Pour un client lourd

Pour un client Web

Quelques standards / outils d'accès à distance à des BDD

En programmation orientée objet, les données

Peut à la place utiliser des frameworks de plus haut niveau

Pour faciliter l'intégration de ces technologies et le développement d'applications

il s'agit de la mise en place d'un serveur permettant la dissimulation d'un

En informatique, un frontal peut désigner une interface de communication

Rôle d’un serveur Web frontal

La performance : Chacun des deux serveurs remplit pleinement son rôle :

Evolutivité : Un serveur Web frontal permet l’évolutivité verticale /

Fonctionnalité : Il ajoute des fonctionnalités de chiffrement, de réécriture,

TCP est un protocole qui va servir a la transmission de données entre

HTTP est un protocole qui permet la transmission de fichier hyper média

Chaque requête individuelle est envoyée au serveur, ce dernier la traite

L’agent utilisateur correspond à n’importe quel outil qui agit pour

Le « HTTP Persistent Connexion » consiste a créer une seule connexion

Il possède aussi de nombreuses qualités. La latence dans les requêtes

Le handshaking, c’est le fait de devoir à chaque fois recommencer une

Le pipeline est une technique qui envoie plusieurs requête HHTP en

Certains navigateurs prennent le pipelining en charge mais le

Le PDU est l’unité de mesure des informations dans un réseau

GET et POST sont 2 méthodes utilisées dans les formulaires en PHP.

La mauvaise implémentation des méthodes HTTP par certains

La méthode PUT est une méthode utilisée pour le remplacement ou