SECURITE WEB ET OWASP

1. SECURITE WEB
Le World Wide Web
Les sites Web sont des agrégations de pages accessibles au public contenant du texte, des images, des
vidéos et du contenu associé. Un site Web unique est identifié par un nom de domaine, est présent et
accessible via au moins un serveur Web et, collectivement, tous les sites Web constituent le «World Wide
Web». Des sites Web existent pour les grandes organisations, les propriétaires de petites entreprises, les
particuliers ... les animaux de compagnie ... plus d'animaux de compagnie ... il existe littéralement des
milliards de sites Web dans le monde: ~ 1,7 milliard en fait. Et même si ce n'est que relativementun petit
nombre d'entre eux sont actifs (environ 200 millions), c'est encore un nombre énorme selon les
estimations de quiconque. Bien sûr, lorsque nous mettons nos chapeaux de sécurité, au lieu d'admirer
le grand nombre de sites, nous sommes plus susceptibles de percevoir le début d'une migraine, car plus
de nombres égalent une plus grande surface d'attaque ... une surface qui ne manque pas de adversaires.
Au fur et à mesure de leur évolution, les sites Web sont devenus de plus en plus complexes, avec de
simples formulaires statiques codés en Hypertext Markup Language (HTML) et en Cascading Style Sheets
(CSS), laissant la place à des versions plus complexes et dynamiques comprenant un large éventail de
technologies et de cadres d'applications Web. (pour des langages comme PHP, Python, Ruby, etc.) pour
amplifier la vitesse et la multiplicité. De plus, les plug-ins de navigateur Web ont ajouté des couches
multimédia aux sites Web, par exemple, des fonctionnalités audio, vidéo, de traitement de
texte. Cependant, à mesure que la technologie HTML a continué à se développer, elle a naturellement
intégré les fonctionnalités susmentionnées, supprimant les options de boulonnage souvent non
sécurisées et augmentant les performances et la sécurité dans le processus.

Et la sécurité?
Alors, qu'est-ce que tout cela signifie en termes de sécurité, et pourquoi est-ce préoccupant? Eh bien, il
n'est pas nécessaire de regarder plus loin que le dernier reportage concernant une violation massive
pour comprendre que la sécurité des sites Web est l'un des défis les plus importants auxquels sont
confrontés les fournisseurs et les utilisateurs mondiaux d'Internet. Les sites Web destinés au public sont
fréquemment attaqués. Les budgets pour remplacer les technologies fatiguées font souvent
défaut. Même lorsque les contraintes financières sont contournées par l'utilisation de services gratuits
ou rentables, le savoir-faire pour une mise en œuvre efficace et sécurisée est souvent encore laissé à
désirer.
La sécurité des sites Web est un sujet aussi vaste que possible, et en conséquence, les menaces et les
impacts associés le sont aussi. Les attaques contre les sites Web peuvent être purement cosmétiques,
par exemple, la dégradation du site Web, à l'extrême, par exemple, la compromission totale et totale de
données sensibles, la perte totale de contrôle du site Web et même la prise de contrôle complète de la
fonctionnalité du site Web servant de passerelle vers des compromis supplémentaires. ciblant les actifs,
les partenaires ou les clients d'autres organisations.

La prévention
Que vous soyez en charge de la présence numérique pour un Fortune 500 ou que vous administriez un
site de commerce électronique pour des sculptures artisanales en bois taillé de chats, la sensibilisation
et le respect des étapes fondamentales énumérées ci-dessous peuvent réduire considérablement vos
chances de devenir un journal. gros titre.
Tout d'abord, la responsabilité d'une grande partie de la sécurité des sites Web incombe au fournisseur
d'hébergement du site Web ou à la société informatique engagée pour gérer les affaires numériques de
l'organisation. Il est essentiel de clarifier les responsabilités contractuelles, où les rôles commencent et
se terminent, et les accords de niveau de service (SLA) au début.
En outre, il est fortement conseillé de revoir, mettre à niveau, surveiller et mettre en œuvre des contrôles
de sécurité autour des sujets suivants.
Systèmes de noms de domaine (DNS)
Le système de noms de domaine est le mécanisme qui convertit les noms conviviaux et faciles à retenir
(comme www.google.com) en adresses IP (Internet Protocol) (comme 173.194.39.78).
Les administrateurs système, qui sont ultimement responsables de cette infrastructure au sein de
l'entreprise, sont également chargés d'examiner et de renforcer la configuration DNS de votre
organisation.
Comptes utilisateur
Les systèmes d'authentification de votre organisation doivent garantir que les mots de passe ne sont
pas laissés par défaut et que l'authentification multifacteur (MFA) est utilisée dans la mesure du possible.
Les administrateurs d'utilisateurs sont responsables de l'attribution et de la gestion des configurations
de niveau d'accès des comptes d'utilisateurs dans toute l'organisation, en fonction de la fonction
professionnelle des employés, des projets, de la portée et de nombreuses autres variables.
Le principe du moindre privilège, qui consiste à fournir à un utilisateur les niveaux minimum d'accès et
d'autorisations nécessaires pour exécuter ses fonctions professionnelles, est une exigence
fondamentale de sécurité des informations qui doit être appliquée dans tous les systèmes et processus
de l'organisation.
Restez au courant des dernières vulnérabilités
Gardez à l'esprit que les bogues de sécurité sont identifiés chaque minute de chaque jour, dont
beaucoup présentent des niveaux élevés de gravité et d'omniprésence.
Dans chaque organisation, le personnel en charge de la sécurité doit soutenir ses équipes de
développement en mettant en œuvre des processus qui appliquent l'analyse de sécurité automatique
et accélèrent la correction des vulnérabilités critiques et de haut niveau en conséquence.
Données sécurisées
Le chiffrement est le processus de conversion des informations d'un état d'origine (texte clair) en un état
codé (texte chiffré) qui est indéchiffrable pour tous sauf ceux qui possèdent une clé de chiffrement
spéciale.
Le chiffrement est devenu bon marché et déployé partout, et bien que beaucoup d'entre nous ne le
réalisent même pas, nous l'utilisons continuellement dans notre vie quotidienne, par exemple lorsque
nous visitons un service de commerce électronique ou tout autre site Web qui gère des informations
sensibles et se soucie de lui. leurs clients.
Toute organisation soucieuse de la sécurité doit s'assurer que les données en transit - données envoyées
ou reçues sur le réseau - respectent les meilleures pratiques de chiffrement. Les administrateurs doivent
appliquer des protocoles sécurisés dans la mesure du possible, tels que la diffusion de sites Web via
HTTPS sur HTTP ou la fourniture de SSH à leurs développeurs pour accéder à leurs serveurs. En outre, la
désactivation et la mise à niveau des chiffrements faibles / obsolètes sont cruciales.
Et pour les données au repos ... trois mots s'appliquent ici: BACK IT UP! Les administrateurs doivent
s'assurer que les sauvegardes sont automatiques et continues, qu'elles contiennent toutes les données
et configurations critiques et qu'elles sont stockées dans un environnement sûr, idéalement
physiquement distant.
Sécurisez vos applications web
Les développeurs, les administrateurs système et les ingénieurs en sécurité sont chargés de repousser
les hordes barbares des portes des applications Web. Ainsi, leur besoin de se tenir au courant des
dernières technologies et techniques défensives est crucial.
À savoir, la Fondation OWASP par excellence est la référence absolue des applications Web pour le
partage d'informations, publiant périodiquement les 10 principaux risques de sécurité des applications
Web les plus critiques qui devraient toujours constituer la pointe de votre évaluation des risques.
En tant que recommandation générique, nettoyez toujours les entrées des utilisateurs, car c'est la cause
première de nombreuses vulnérabilités des applications Web.
Connaissez (et sécurisez) vos actifs
Un inventaire des actifs, des mises à jour automatisées et des correctifs sont la base de tout
environnement informatique sain et sécurisé.
Pour cette raison, les administrateurs système doivent renforcer les serveurs en adhérant aux meilleures
pratiques de sécurité pour chaque service, comme les serveurs Web ou les bases de données. Cela
implique l'installation de mises à jour et de correctifs de sécurité, la limitation de l'accès selon le principe
du moindre privilège, la surveillance et la réalisation d'audits périodiques. Dans la mesure du possible,
les équipements existants doivent être remplacés par des systèmes pris en charge.
Les administrateurs de réseau doivent concevoir les réseaux des organisations pour appliquer la
ségrégation. De plus, des zones démilitarisées (DMZ) qui protègent le réseau interne de l'entreprise
contre le trafic digéré par le serveur Web devraient également être mises en œuvre.
Il existe de nombreux trucs et astuces supplémentaires que l'on peut utiliser pour améliorer la sécurité
d'un site Web, qui se trouvent tous sur la plate-forme SecureFlag.
Les références
Wikipédia - Site Web
US-CERT CISA
OWASP - Adhésion

2. QU’EST CE QUE L’OWASP

Le projet de sécurité des applications Web ouvertes
Au cours de votre vie, vous aurez été le bienfaiteur involontaire d'un nombre incommensurable d'heures de
travail acharné mené par la communauté visant à rendre votre vie meilleure, plus riche et plus sûre. Des
initiatives comme celles-ci restent largement méconnues de ceux qui ne font pas partie d'une telle discipline,
car le désir et la capacité de tracer les tentacules de la chaîne d'approvisionnement mondiale sont rares. En
effet, il serait quasiment impossible pour quiconque de connaître chaque entreprise ayant un impact direct
ou indirect sur un individu.
Heureusement, des efforts tels que ceux mentionnés ci-dessus existent. Dans le contexte de la sécurité
logicielle, peu d'initiatives communautaires ont eu plus d'impact sur l'assurance de la population mondiale
en ligne que l'Open Web Application Security Project®, ou OWASP en abrégé.
OWASP est une fondation à but non lucratif formée pour servir une communauté principalement composée
d'organisations et de développeurs qui impliquent activement ou aspirent le développement de la sécurité
des applications (AppSec) dans leur vie. Plus de dix mille membres contribuent et bénéficient d'outils, de
projets open source, de ressources pédagogiques et de réseaux, avec de fréquents ateliers et événements de
réseautage organisés dans les centaines de chapitres à travers le monde.
Surtout, OWASP incarne l'esprit d'inclusivité et de transparence - la pierre angulaire du mouvement open-
source - et est profondément respecté en tant que tel. En effet, l'OWASP existe depuis vingt ans - depuis les
premiers jours du développement d'applications - et même si le monde en ligne a connu une croissance
exponentielle pendant cette période, l'industrie et les organismes gouvernementaux publiant des directives
et des normes officielles pour lutter contre la négligence et les abus en ligne, l'OWASP reste en tant que
couche solide des meilleures pratiques technologiques, avec ses publications et ressources fréquemment
citées et utilisées par des organisations importantes, telles que la Defense Information Systems
Agency (DISA-STIG), la Federal Trade Commission (FTC) des États-Unis et le National Institute of Normes
et technologie (NIST), pour n'en nommer que quelques-uns.

Projets OWASP
La longévité et la culture très réussie de l'OWASP sur une période de vingt ans ont facilité la création de
nombreuses publications et ressources. Les guides de révision de code, les guides de test, les modèles de
risque pour l'assurance logicielle, les outils de test d'intrusion, etc. ne représentent qu'une fraction de ce qui
a été créé au fil des ans pour servir la communauté AppSec. Cependant, de tous les extrants que l'OWASP a
générés au fil des ans, sa liste «Top Ten» des risques de sécurité des applications Web est sans aucun doute
la plus reconnue, avec une multitude de normes, de matériel pédagogique, d'outils, d'organismes industriels
et d'entités gouvernementales citant le Top 10 projet comme une évidence.

Top 10 de l'OWASP
Injection
Les attaques par injection sont en tête de liste année après année, après près de vingt ans d'utilisation abusive
généralisée. L'injection se produit lorsque l'application accepte des données non fiables dans le cadre d'une
commande ou d'une requête, permettant à un attaquant d'exécuter du code arbitraire dans le contexte de
l'application vulnérable.
Authentification cassée
Cette faille, due à la mise en œuvre inadéquate des applications d'authentification et de gestion de session,
permet aux acteurs malveillants de compromettre les clés, les mots de passe et les jetons de session, ce qui
peut conduire à une exploitation plus poussée de l'identité des utilisateurs et, dans le pire des cas, à un
contrôle complet du système.
Exposition des données sensibles
Il s'agit d'une vaste catégorie de vulnérabilité couvrant les retombées résultant d'une application ne
protégeant pas suffisamment les informations sensibles, telles que les détails de carte de crédit ou les
informations personnellement identifiables, des mains d'un acteur non autorisé.
Entités externes XML (XXE)
Les attaques d'extension d'entité externe XML (également appelées XXE) sont utilisées contre les
applications Web qui traitent les entrées XML en exploitant la prise en charge d'entités externes XML. En
fournissant une entrée XML hostile contenant une spécification d'une entité externe à un analyseur XML
faiblement configuré, les attaquants peuvent être en mesure d'afficher des fichiers sur le système de fichiers
du serveur d'applications et d'interagir avec tout système externe ou backend auquel l'application a accès.
Autorisation cassée
Les vulnérabilités relatives aux autorisations rompues (également appelées contrôle d'accès interrompu ou
escalade de privilèges) englobent une série de faiblesses dans la mise en œuvre des contrôles d'autorisation
effectués par les applications lorsqu'un utilisateur tente d'accéder à une ressource ou d'effectuer une action.
Mauvaise configuration de la sécurité
Comme on peut le déduire du titre générique, cette large classe de risque est à la fois l'entrée la plus courante
et peut-être la plus évitable de la liste. Les configurations sur les périphériques de sécurité et de journalisation
peuvent être incomplètes ou totalement absentes, les configurations par défaut peuvent ne pas être sécurisées,
les en-têtes HTTP peuvent manquer de configuration de sécurité appropriée, les compartiments S3 peuvent
être laissés exposés ... une attention particulière aux détails est primordiale lors de la configuration de tout
système complexe.
Scripts intersites (XSS)
Le Cross-Site Scripting est une vulnérabilité d'application Web courante qui, lors de son exploitation,
entraîne l'exécution de scripts malveillants sur le navigateur de la victime. Les attaquants exploitent cette
faiblesse pour contourner la politique de même origine du navigateur et manipuler les interactions d'un
utilisateur légitime avec l'application Web vulnérable.
Désérialisation non sécurisée
Lorsque des structures de données ou des objets sont traités pour le stockage, ils sont sérialisés. La
désérialisation décrit le contraire, c'est-à-dire le processus d'extraction de données à partir d'une série
d'octets. Si ce processus d'extraction est effectué à l'aide de données non approuvées, la logique de
l'application peut être utilisée de manière abusive, conduisant potentiellement à l'exécution de code arbitraire
ou à d'autres risques graves.
Utilisation de composants avec des vulnérabilités connues
L'intégration de bibliothèques et de frameworks d'entités tierces présente un risque élevé si ces composants
sont connus pour posséder des vulnérabilités non corrigées. Si un composant est exploité en amont, cela peut
entraîner la compromission complète d'une application utilisant le composant en aval.
Journalisation et surveillance insuffisantes.
Une journalisation et une surveillance insuffisantes sont une catégorie assez large englobant l'installation et
la configuration non conformes ou inexistantes d'outils de sécurité et de systèmes défensifs, ce qui entraîne
des lacunes inhérentes à la capacité d'identifier les anomalies et / ou les intrusions dans un environnement. Si
les événements sur un réseau ne sont pas surveillés et enregistrés, tout attaquant qui parvient à franchir le
périmètre aura beaucoup plus de facilité à ne pas être détecté, une plus grande chance de maintenir la
persistance et une probabilité plus élevée de succès de l'exfiltration.

OWASP témoigne de la force de la communauté lorsqu'elle ose scruter ses défauts et apprendre de ses
erreurs.Par conséquent, les développeurs qui adoptent cette culture et appliquent l'éthique tout en
développant des applications seront mieux préparés face à des défis technologiques de plus en plus
dommageables.
Adhérez aux directives OWASP d'atténuation des risques, faites un effort pour être actif au sein de la
communauté et n'arrêtez jamais d'apprendre!

Les références
OWASP
Wikipédia - OWASP
OWASP - TOP 10
3. INJECTION SQL

La description
Une injection SQL n'est pas un type d'attaque nouveau ou trop compliqué, mais elle continue de figurer
au sommet des dix principaux risques de sécurité des applications de l'OWASP après plus de 20 ans
d'utilisation publique. Cela est principalement dû à sa facilité d'utilisation inhérente et relative, associée
à la gravité de son impact lorsqu'il est dirigé vers le nombre incroyablement élevé de sites Web avec un
code vulnérable mal écrit.
SQL est un langage de requête conçu pour accéder, modifier et supprimer des données stockées dans
des bases de données relationnelles. De nombreuses applications Web et sites Web utilisent des bases
de données SQL comme méthode de stockage de données. Les applications avec une prévalence plus
élevée d'interfaces fonctionnelles plus anciennes telles que PHP et ASP sont relativement plus sensibles
aux failles d'injection SQL que les applications basées sur des technologies plus récentes.
Les applications sont vulnérables aux attaques lorsque les données fournies par l'utilisateur ne sont pas
validées, filtrées pour les caractères d'échappement ou nettoyées par l'application.
Un attaquant peut utiliser SQL Injection pour manipuler une requête SQL via les données d'entrée du
client vers l'application, obligeant ainsi le serveur SQL à exécuter une opération involontaire construite
à l'aide d'une entrée non approuvée.

Impacter
Une attaque par injection SQL réussie peut amener un utilisateur malveillant à obtenir un accès complet
à toutes les données d'un serveur de base de données avec la possibilité d'exécuter des requêtes SQL
non autorisées et de compromettre la confidentialité, l'intégrité et la disponibilité de l'application. En
fonction du SGBD backend utilisé et des autorisations accordées à l'utilisateur sur la base de données,
 une injection SQL peut entraîner une lecture / écriture arbitraire de fichiers et même l'exécution de code
à distance.
La gravité des attaques qui ont exploité l'injection SQL ne doit pas être sous-estimée. Des violations
notoires, y compris les hacks dévastateurs et de renommée internationale de Sony Pictures et LinkedIn
par exemple, auraient été exécutées à l'aide de l'injection SQL.

Scénarios
Subvertir la logique d'application via SQL peut conduire à des résultats imprévisibles en fonction du
contexte de l'instruction SQL et de la stratégie de l'attaquant.
Il existe une technique d'exploitation bien connue que les attaquants exploitent en fonction de la
vulnérabilité dans la mise en œuvre du code:
 Manipuler une logique de requête SQL pour contourner les contrôles d'accès.
 Récupérer des données cachées pour renvoyer des résultats supplémentaires, y compris des données
provenant d'autres tables dans les bases de données, par exemple en exploitant le UNIONmot - clé.
 Exécution de code SQL arbitraire dans le contexte de la base de données si les requêtes empilées sont
autorisées.
 Accès aux fichiers et exécution de commandes dans le système d'exploitation, en fonction du code vulnérable
et du système de gestion de la base de données.
Elle est appelée injection SQL aveugle lorsque l'injection réussit, mais le code ne renvoie pas le résultat
de la requête manipulée à l'attaquant. Les injections aveugles sont toujours exploitables pour récupérer
le contenu à l'aide de l'analyse temporelle, de l'analyse de contenu ou d'autres techniques hors limites.
Voici un exemple classique de subversion de la logique d'application pour contourner les contrôles
d'accès.
Les noms d'utilisateur et les mots de passe sont omniprésents en tant que méthode de connexion aux
applications. Dans ce scénario bénin, un utilisateur soumet le nom d'utilisateur useret le mot de
passe secret. L'application exécute ensuite une requête SQL pour vérifier les informations
d'identification:
SELECT * FROM users WHERE username = 'user' AND password = 'secret'
La connexion réussit si la requête renvoie les détails de l'utilisateur. Si la requête ne renvoie pas les
détails de l'utilisateur, elle est rejetée.
En exploitant les guillemets simples et les commentaires SQL ( --), il est possible de se connecter en tant
qu'utilisateur sans mot de passe, car la vérification du mot de passe de la clause WHERE est supprimée
de la requête.
L'exemple suivant illustre cela en action. En entrant administrator'--dans le champ du nom
d'utilisateur et en laissant le champ du mot de passe vide, l'instruction SQL se traduirait comme suit:
SELECT * FROM users WHERE username = 'administrator'--' AND password = '
La base de données évalue cette instruction sans la partie commentée, en exécutant uniquement la
première partie:
 SELECT * FROM users WHERE username = 'administrator'
Étant donné que la requête manipulée renvoie toujours les détails de l' administratorutilisateur,
l'attaquant peut se connecter avec succès sans connaître le mot de passe correct.

La prévention
Pour éviter les vulnérabilités d'injection SQL, les développeurs doivent utiliser des requêtes
paramétrées, en spécifiant des espaces réservés pour les paramètres afin qu'ils ne soient pas considérés
comme faisant partie de la commande SQL; plutôt, comme uniquement des données provenant de la
base de données.
Lorsqu'ils travaillent avec des systèmes hérités, les développeurs doivent échapper les entrées avant de
les ajouter à la requête. Les mappeurs relationnels d'objets (ORM) facilitent cette tâche pour le
développeur; cependant, ils ne sont pas une panacée, avec les atténuations sous-jacentes toujours tout
à fait pertinentes: les données non fiables doivent être validées, la concaténation de requêtes doit être
évitée sauf en cas d'absolue nécessité, et la minimisation des privilèges de compte SQL inutiles est
cruciale .

Essai
Vérifiez qu'en l'absence de mécanismes paramétrés ou plus sûrs, le codage de sortie spécifique au
contexte est utilisé pour se protéger contre les attaques par injection, comme l'utilisation de
l'échappement SQL pour se protéger contre l'injection SQL.
 OWASP ASVS : 5.3.5
 Guide de test OWASP : test d'injection SQL
4. AUTHENTIFICATION CASSEE

La description
L'authentification brisée est un risque de sécurité des applications qui peut permettre à des acteurs
malveillants de compromettre les clés, les mots de passe et les jetons de session, ce qui pourrait
conduire à une exploitation supplémentaire de l'identité des utilisateurs et, dans le pire des cas, à un
contrôle complet du système.
Essentiellement, la vulnérabilité se résume au fait qu'un attaquant peut contourner le mécanisme
d'authentification de l'application vulnérable en raison d'erreurs logiques ou de bogues dans le logiciel.
Cette classe de vulnérabilité peut affecter tout type de logiciel qui implémente le contrôle d'accès à
pratiquement toutes les applications, y compris les bases de données, les applications d'infrastructure
réseau et les applications Web.
Comme pour de nombreux risques répertoriés dans le Top 10 de l' OWASP , les vulnérabilités
d'authentification ne sont pas un nouveau sujet de sécurité, et souvent un acteur malveillant n'a pas
besoin d'être très technique pour contourner les contrôles d'identité et d'accès mal implémentés ... cela
fait le travail des attaquants d'autant plus facile que ces contrôles sont souvent totalement
inexistants! En tant que tel, il ne devrait y avoir aucune surprise d'apprendre qu'il a été classé comme le
deuxième risque le plus critique affectant les applications Web dans le Top 10 de l'OWASP depuis 2013.

Impacter
Une attaque réussie peut amener un attaquant malveillant à obtenir un accès complet à toutes les
données de l'application Web, en assumant les droits d'administrateur et en compromettant la
confidentialité, l'intégrité et la disponibilité de l'application.
Cette brèche affectant le revendeur allemand de billets d'avion Aerticket a été découverte en 2016 mais
aurait existé depuis 2011 (c'est-à-dire pendant cinq ans). Des millions de noms, d'adresses et de numéros
 de carte de crédit de clients ont été potentiellement exposés en raison d'un défaut de mise en œuvre
dans lequel une chaîne de chiffres, qui aurait dû être générée aléatoirement, ne l'était pas.

Scénarios
Il existe une variété d'instances d'authentification cassée différentes que les attaquants peuvent
exploiter en fonction de la vulnérabilité dans la mise en œuvre de l'identité ou du contrôle
d'accès. Certaines méthodes d'exploitation et les faiblesses potentielles comprennent:
 Les fonctionnalités nécessitant une authentification manquent de mécanismes ou implémentent des
protections insuffisantes.
 Les mécanismes de protection cassés au niveau des objets permettent aux utilisateurs non authentifiés
d'accéder aux ressources privées.
 L'utilisation d'attaques basées sur un dictionnaire ou la réutilisation des informations d'identification sur des
applications qui permettent des attaques automatisées.
 L'application permet l'utilisation de mots de passe faibles, tels que "password123" ou "123456".
 L'application ne crypte pas ou crypte faiblement les mots de passe.

La prévention
L'utilisation de contrôles de sécurité mis à jour qui garantissent l'identité des utilisateurs,
l'authentification et la gestion des sessions est cruciale si l'on veut empêcher les attaques
d'authentification avec succès. Pourtant, très souvent, une authentification interrompue est le résultat
d'erreurs logiques ou d'erreurs. Étant donné que l'authentification brisée en tant que catégorie
comprend autant de vecteurs d'attaque, il y a de nombreuses faiblesses potentielles à prendre en
compte.
Par exemple, les applications doivent être vérifiées et correctement ajustées / mises en œuvre de la
manière suivante:
 Les développeurs doivent correctement implémenter la rotation des ID de session après des connexions
réussies et s'assurer que les règles relatives à l'invalidation des ID de session lors de la déconnexion ou de
l'inactivité sont correctement implémentées.
 Les développeurs doivent mettre en œuvre une politique de mot de passe efficace qui interdit l'utilisation de
mots de passe faibles ou surutilisés / communs.
 Les développeurs doivent tester correctement l'exactitude de l'authentification en plus des aspects
fonctionnels de l'application.

Essai
Vérifiez que les API implémentent une force de contrôle de sécurité d'authentification cohérente, de
sorte qu'il n'y ait pas d'alternatives plus faibles pour le risque de l'application.
 OWASP ASVS : 1,2
 Guide de test OWASP : test d'authentification
5. DIVULGATION D’INFORMATION SENSIBLES

La description
La divulgation d'informations sensibles (également appelée exposition de données sensibles) se produit
lorsqu'une application ne protège pas de manière adéquate les informations sensibles qui peuvent finir
par être divulguées à des parties qui ne sont pas censées y avoir accès.
Les données sensibles peuvent inclure des informations relatives à l'application, telles que des jetons de
session, des noms de fichiers, des traces de pile ou des informations confidentielles, telles que des mots
de passe, des données de carte de crédit, des données de santé sensibles, des communications privées,
la propriété intellectuelle, des métadonnées, le code source du produit, etc. .
Quelle que soit la faille de sécurité qui entraîne la divulgation des informations, tous les aspects de tous
les types de services sont potentiellement menacés. La divulgation d'informations sensibles peut
survenir dans les bases de données, les systèmes d'exploitation et les périphériques réseau. Il est
particulièrement fréquent dans les applications Web, comme le souligne le Top 10 de l'OWASP , qui
classe la divulgation d'informations sensibles comme le troisième risque de sécurité des applications
Web le plus critique dont il faut être conscient.
La législation et les réglementations nécessaires en matière de protection de la vie privée et de la
sécurité sont créées et remaniées pour essayer de garantir que les organisations détenant des données
sensibles respectent leurs obligations de protection de ces données. Le règlement général européen sur
la protection des données (RGPD) est l'une de ces lois; la norme de sécurité des données de l'industrie
des cartes de paiement (PCI DSS) est un exemple de réglementation.

Impacter
L'ampleur de l'impact d'un événement de divulgation d'informations sensibles n'est limitée que par le
type d'informations sensibles divulguées et la capacité d'un acteur malveillant à en tirer parti.
Par exemple, les retombées pourraient être aussi mineures qu'un chemin d'accès local divulgué dans
une trace de pile, permettant à un acteur malveillant d'améliorer sa connaissance des détails de mise en
 œuvre de la cible, jusqu'à une fuite de données complète impliquant des millions de données
confidentielles de clients. .

Scénarios
Un exemple typique consiste à permettre à un utilisateur final de recevoir les pages d'erreur par défaut du
serveur d'applications. Cela peut exposer l'emplacement sur le système de fichiers du fichier à l'origine
du problème, ainsi que la version précise du serveur lui-même et les composants tiers. Les attaquants
peuvent utiliser ces connaissances de différentes manières, par exemple pour cibler des exploits bien
connus dans une version particulière d'un composant.
Un scénario plus grave implique une page Web rendant un message d'erreur à partir d'un serveur SQL
pour une requête ayant échoué. Si un paramètre contrôle l'attaquant, un acteur malveillant pourrait
exploiter cette exposition pour exfiltrer des données arbitraires de la base de données en envoyant des
requêtes spécialement conçues.
Il existe d'innombrables technologies placées sous le parapluie informatique sensibles à cette classe de
vulnérabilité complète; fondamentalement, tout ce qui n'est pas correctement attaché contenant même
des informations minimales peut devenir la proie d'un acteur malveillant déterminé.

La prévention
La divulgation d'informations sensibles est un symptôme d'une mauvaise mise en œuvre du contrôle de
sécurité dans les applications Web. Pour éviter cela, les développeurs doivent adhérer à de nombreuses
bonnes pratiques de l'industrie, conformément à la réglementation en vigueur, pour augmenter la
difficulté pour l'attaquant.
 Les développeurs doivent d'abord identifier les données sensibles en fonction de l'architecture du système et
des exigences réglementaires.
 Les développeurs doivent s'assurer que les données en transit ou en stockage sont cryptées.
 Les développeurs doivent supprimer les fonctionnalités de débogage et de test des applications et des
systèmes de production.
 Les développeurs doivent examiner les éléments répertoriés pour déterminer s'il existe un besoin commercial
justifié de posséder chaque élément présent. Tous les éléments jugés inutiles doivent être supprimés.
 Les procédures de création d'application / système définies doivent inclure des étapes pour supprimer les
fichiers et fonctionnalités qui ne sont pas nécessaires pour un déploiement de production, et les processus et
contrôles de sécurité internes doivent confirmer que cela s'est produit avant la sortie de production.

Essai
Assurez-vous que la confidentialité des données est protégée contre toute observation ou divulgation
non autorisée.
 OWASP ASVS : 8
 OWASP Testing Guide : Examen Webserver Métafichiers d'information Fuites , examen Webpage contenu
de l' information Fuites , extensions de fichiers de test Manipulation des informations sensibles , examen
d'une ancienne sauvegarde et fichiers non référencés pour les informations sensibles

Les références
OWASP - Top 10 2017 A3 - Exposition aux données sensibles
Institut Infosec - 2017 OWASP A3
CWE-200: Exposition d'informations sensibles à un acteur non autorisé
6. EXTENSION D’ENTITE XML
La description
Les attaques d'extension d'entité externe XML (également appelées XXE) sont utilisées contre les
applications qui traitent les entrées XML en exploitant la prise en charge d'entités externes XML. En
fournissant une entrée XML hostile contenant une spécification d'une entité externe à un analyseur XML
faiblement configuré, les attaquants peuvent être en mesure d'afficher des fichiers sur le système de fichiers
du serveur d'applications, de mener des attaques par déni de service et d'interagir avec tout système externe
ou backend de l'application. a accès à.
Les vulnérabilités XXE se produisent lorsque le format XML largement utilisé (un protocole normalement
utilisé pour transmettre des données entre le navigateur et le serveur) contient diverses fonctionnalités
potentiellement dangereuses. En raison de la gravité potentielle des attaques XXE et de leur prévalence
continue, ces attaques apparaissent dans le Top 10 OWASP des risques de sécurité des applications Web.
Comme pour la plupart des vulnérabilités de cette liste, la prévalence diminuerait considérablement avec une
formation des développeurs plus complète et continuellement mise à jour.

Impacter
Les attaques XXE peuvent inclure la conduite d'attaques par déni de service et la divulgation de fichiers
locaux contenant des données sensibles telles que des mots de passe ou des données d'utilisateurs
privés. Comme l'attaque se produit par rapport à l'application traitant le document XML, elle peut permettre
aux attaquants de passer latéralement vers d'autres systèmes internes pour potentiellement organiser des
attaques SSRF (Server-Side Request Forgery) contre des services internes non protégés.
Les attaques XML sont comprises depuis près de 20 ans et pourtant, même ces dernières années, des
puissances comme Google et Facebook sont connues pour avoir rencontré des problèmes avec ces types
d'attaques. Cela sert de rappel brutal que le chaos peut survenir (et prendre la forme d'amendes
potentiellement massives) simplement en raison d'une mauvaise configuration et d'un code mal implémenté.

Scénarios
L'utilisation répandue de XML comme structure de données dans de nombreux domaines d'application
garantit que la vulnérabilité persiste dans de nombreuses applications dans une variété de saveurs
différentes. Dans leur forme la plus bénigne, les attaques XXE peuvent provoquer des attaques par déni de
service, par exemple lorsqu'un attaquant a intégré des entités dans des entités au sein d'entités, entraînant une
surcharge de la mémoire de l'analyseur XML. La soi-disant « attaque Billion Rires » illustrée ci-dessous tire
parti d'une définition de type de document appelée foo , et d'un élément appelé bar , remplacé dans ce cas
par le nom d'une plate-forme de formation à la sécurité fine! À tout moment &bar;, l'analyseur XML le
remplace par SecureFlag.
Demander
POST http://www.vulnerableapp.com/xml HTTP/1.1

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [
<!ELEMENT foo ANY>
<!ENTITY bar "SecureFlag ">
<!ENTITY t1 "&bar;&bar;">
<!ENTITY t2 "&t1;&t1;&t1;&t1;">
<!ENTITY t3 "&t2;&t2;&t2;&t2;&t2;">
]>
<foo>
Join &t3;
</foo>
Réponse
HTTP/1.0 200 OK

Join SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag Secu

reFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlagSecureFlag Sec
ureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag S
ecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag
SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFla
g SecureFlag
Malheureusement, cette attaque ne se limite pas uniquement à répandre la gêne. L'exemple ci-dessous met
en évidence les ramifications de ne pas avoir défini d'entités XML dans le document XML. Comme le nom
de l'extension d'entité externe XML le suggère, même les sources externes peuvent proposer des entités
XML, permettant ainsi à un attaquant de faire des requêtes à un serveur Web à l'aide d'un URI qui, s'il est
configuré pour traiter des entités externes (et elles le sont par défaut), renverra le contenu d'un fichier sur le
système.
Demander
POST http://www.vulnerableapp.com/xml HTTP/1.1

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [
<!ELEMENT foo ANY>
<!ENTITY xxe SYSTEM
"file:///etc/passwd">
]>
<foo>
&xxe;
</foo>
Réponse
HTTP/1.0 200 OK

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
(...)
Un attaquant pourrait effectuer une attaque de falsification de requête côté serveur, pointant l'URI vers une
ressource externe, telle qu'un emplacement HTTP. Ceci, à son tour, peut être utilisé pour pivoter et interagir
avec tout système externe ou backend auquel l'application a accès.
Demander
POST http://www.vulnerableapp.com/xml HTTP/1.1

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [
<!ELEMENT foo ANY>
<!ENTITY xxe SYSTEM
"http://internal.vulnerableapp.com:8443">
]>
<foo>
&xxe;
</foo>
Réponse
HTTP/1.0 200 OK

(.. result of the request to http://internal.vulnerableapp.com:8443 ...)

La prévention
La désactivation de la fonction de définition de type de document (DTD) empêchera efficacement la plupart
des attaques.
Lorsque cela est possible, il est recommandé de gérer les données à l'aide de formats plus simples tels que
JSON. Depuis près d'une décennie, JSON a été considéré comme préférable à l'utilisation de XML en raison
de sa syntaxe légère et de sa construction plus récente.
Bien sûr, des exceptions existent pour prouver les règles, et dans les cas où il n'est absolument pas possible
de désactiver les DTD dans les paramètres métier ou d'utiliser un autre format, les mesures suivantes doivent
être appliquées par les développeurs.
Lorsque le document XML entier est transmis à partir d'un client non approuvé, il n'est généralement pas
possible de valider ou d'échapper de manière sélective les données corrompues dans l'identifiant système de
 la DTD. Par conséquent, le processeur XML doit être configuré pour utiliser une DTD statique locale et
interdire toute DTD déclarée incluse dans le document XML.

Essai
Vérifiez que l'application limite correctement les analyseurs XML à n'utiliser que la configuration la plus
restrictive possible et que les fonctionnalités non sécurisées telles que la résolution d'entités externes sont
désactivées pour empêcher les attaques d'entité XML eXternal (XXE).
 OWASP ASVS : 5.5.2, 5.5.3
 Guide de test OWASP : Test de l'injection XML
7. AUTORISATION CASSEE

La description
L'autorisation brisée (également connue sous le nom de contrôle d'accès brisé ou d'escalade de privilèges)
est l'hypernyme d'une gamme de failles qui surviennent en raison de la mise en œuvre inefficace des contrôles
d'autorisation utilisés pour désigner les privilèges d'accès des utilisateurs.
Différents utilisateurs sont autorisés ou refusés à accéder à divers contenus et fonctions dans des cadres
d'autorisation correctement conçus et mis en œuvre en fonction du rôle désigné de l'utilisateur et des
privilèges correspondants. Par exemple, dans une application Web, l'autorisation est soumise à
l'authentification et à la gestion de session. Cependant, la conception de l'autorisation sur des systèmes
dynamiques est complexe et peut entraîner l'écriture de mécanismes incohérents au fur et à mesure que les
applications évoluent: les bibliothèques d'authentification et les protocoles changent, les rôles des utilisateurs
le font également, plus d'utilisateurs viennent, les utilisateurs partent, certains utilisateurs sont (non)
supprimés lorsque disparu ... les décisions de conception de contrôle d'accès ne sont pas prises par la
technologie, mais par les humains, de sorte que le potentiel d'erreur est élevé et toujours présent.
Des vulnérabilités de cette nature peuvent affecter tout logiciel moderne présent dans les applications Web,
les bases de données, les systèmes d'exploitation et autres infrastructures technologiques dépendant des
contrôles d'autorisation.

Impacter
Lors d'une attaque réussie, un acteur malveillant peut être en mesure d'accéder à un contenu non autorisé, de
modifier ou de supprimer du contenu, d'exécuter des fonctions et même d'assumer le contrôle total de
l'administration du site. Une fois ce niveau de compromis atteint, les dommages de l'attaque ne sont limités
que par les privilèges accordés à la victime usurpée.
En effet, la brèche d'une entreprise de fabrication de jouets appelée CloudPets illustre l'erreur humaine
susmentionnée. Dans ce cas, le résultat de contrôles d'autorisation inexistants a conduit à la fuite et à la
 rançon subséquente des messages vocaux des enfants, qui avaient été enregistrés via et stockés (mal) dans
le cloud.

Scénarios
Du point de vue de l'utilisateur, il existe deux grandes catégories de contrôles d'autorisation à prendre en
compte:
 Contrôles d'autorisation horizontaux
 Contrôles d'autorisation verticale
Contournement de contrôle d'autorisation horizontale
Contournement des contrôles d'autorisation horizontaux décrit le fait qu'un utilisateur non privilégié accède
aux comptes d'autres utilisateurs possédant des privilèges égaux.
Par exemple, imaginez une application acceptant des données non vérifiées dans un appel de méthode en
aval pour récupérer les informations de compte. Un attaquant pourrait facilement modifier
le accountIdparamètre dans la requête HTTP pour récupérer les données d'un ou même de plusieurs
comptes d'utilisateurs.
L'application utilise des données non vérifiées dans un appel de méthode en aval pour récupérer les
informations de compte:
http://vulnerableapp.com/user/account?accountId=7800001

http://vulnerableapp.com/user/account?accountId=7800002

etc.
Les références directes d'objets non sécurisées, ou IDOR, sont un scénario associé impliquant une entrée
fournie par l'utilisateur utilisée pour accéder directement aux objets.
Contournement de contrôle d'autorisation verticale
Les contournements de contrôle d'autorisation verticale décrivent l' utilisation ascendante de
l'accès. Autrement dit, lorsqu'un utilisateur avec un certain niveau de privilège peut indiquer qu'il possède
un niveau d'accès plus élevé, comme un accès de niveau administratif, à l'application.
Dans cet exemple, un attaquant a accédé à une URL administrative, où des droits
d'administrateur devraient être requis pour accéder à la page d'administration.
http://vulnerableapp.com/user/account

http://vulnerableapp.com/admin/panel
Si l'application ne vérifie pas si le rôle de l'utilisateur de session correspond au rôle requis pour accéder à la
ressource, un utilisateur sans privilèges d'administrateur pourra accéder à la page en connaissant / devinant
simplement l'URL cible et en y naviguant.
 La prévention
Il existe de nombreuses étapes de base que les développeurs peuvent suivre pour empêcher les attaques de
contrôle d'autorisation interrompu, à commencer par une évaluation des exigences de contrôle d'accès d'une
application, puis par la formation d'une politique de sécurité appropriée conforme aux résultats. Cela devrait
inclure une matrice de contrôle d'accès, une politique claire indiquant quels types d'utilisateurs peuvent
accéder au système et ce que ces utilisateurs peuvent et ne peuvent pas faire avec leur accès. Utilisez le
contrôle d'accès basé sur les rôles (RBAC) pour appliquer les rôles aux limites appropriées.
Pour les applications Web, assurez-vous que le mécanisme de contrôle d'accès est correctement appliqué
côté serveur sur chaque page et point de terminaison d'API. Les utilisateurs ne doivent pas pouvoir accéder
à des fonctionnalités ou informations non autorisées en demandant simplement un accès direct à la page ou
à l'objet.

Essai
Vérifiez que le principe du moindre privilège existe - les utilisateurs ne devraient pouvoir accéder qu'aux
fonctions, fichiers de données, URL, contrôleurs, services et autres ressources, pour lesquels ils possèdent
une autorisation spécifique.
 OWASP ASVS : 4.1, 4.2
 Guide de test OWASP : Test d'autorisation
7. FONCTIONNALITE NON SECURISE EXPOSEE

La description
Les fonctionnalités non sécurisées exposées sont des vulnérabilités qui apparaissent généralement dans
les infrastructures ou les applications en raison de contrôles de sécurité mal mis en œuvre (ou
inexistants) qui, à leur tour, exposent des fonctions potentiellement critiques ou sensibles à l'Internet
ouvert. Les fonctionnalités non sécurisées exposées sont une classe d'origine pour l'exposition
d'informations reposant sur la classification plus large des 10 principales fausses configurations de
sécurité de l'OWASP.
Souvent, pendant la phase de développement d'un serveur ou d'une application Web, le code est ajouté
par le développeur pour faciliter l'accès lors des tests et du débogage. Comme c'est souvent le cas
cependant, ce qui était à l'origine une aide bénigne pour une efficacité et une qualité accrues peut à la
fois servir de point d'entrée pour les acteurs malveillants simplement parce que le risque de sécurité n'a
pas été pris en compte au départ. Ainsi, ce code de porte dérobée non sécurisé peut faire son chemin dans
la production, ce qui suggère que les procédures et processus de sécurité internes ne sont pas en place
ou appliqués pour garantir une application adéquate et un renforcement du système avant le
déploiement.
Les fonctionnalités non sécurisées exposées sont particulièrement utiles pour les attaquants qui
effectuent des activités de reconnaissance, car elles divulguent souvent les détails de configuration et
de déploiement des applications et du système aux utilisateurs distants.

Impacter
Il existe d'innombrables exemples concrets de fonctionnalités non sécurisées exposées introduisant des
vulnérabilités de sécurité dans des environnements auparavant sécurisés, avec un niveau d'impact
allant de la publication d'informations sensibles au contrôle complet de l'application Web et du serveur,
en passant par une étape pierre dans des systèmes d'accès supplémentaires.
Par exemple, des violations infâmes telles que la fuite de 154 millions de registres d'électeurs (y compris
les adresses, les numéros de téléphone, l'état matrimonial, les revenus estimés et les partis politiques)
ont frappé plus d'un pays en raison de bases de données exposées et mal configurées.

Scénarios
L'exemple suivant suppose une application Web qui expose un mécanisme d'authentification
vulnérable. L'application interprète un paramètre facultatif supplémentaire nommé debug-
vraisemblablement un reste de la phase de développement - comme une demande de basculement en
mode débogage, et que le nom d'utilisateur et le mot de passe ne sont pas cochés lorsque ce paramètre
est émis.
Si le debugparamètre est un problème connu, il est simple de contourner le processus
d'authentification. Si ce n'est pas le cas, il peut être découvert par des attaquants motivés en exécutant
des scanners automatisés conçus pour trouver des paramètres cachés suspects.
Cela signifie qu'une demande de connexion en tant qu'administrateur, comme dans l'exemple suivant,
serait rejetée en raison d'un mot de passe incorrect:
POST /auth

user=admin&pass=wrong
Alors qu'un acteur malveillant pourrait ajouter l' debugindicateur à la demande pour obtenir un accès
non autorisé à l'application.
POST /auth

user=admin&pass=wrong&debug=1

La prévention
Les développeurs doivent supprimer toutes les fonctionnalités de débogage et de test des applications
et des systèmes de production si un besoin commercial justifié n'existe pas. Les procédures de création
d'application doivent inclure des étapes pour supprimer tous les fichiers et fonctionnalités qui ne sont
pas nécessaires pour un déploiement de production, et ces étapes doivent être respectées par le projet
et l'équipe de développement.
Les processus et contrôles de sécurité internes documentés doivent confirmer que cela s'est produit
avant la sortie de la production; les fonctionnalités de débogage ne doivent jamais être livrées dans les
environnements de production.
Les développeurs doivent adhérer à ce processus de renforcement avant et après le passage d'une
application dans un environnement de production. Les répertoires d'applications doivent faire l'objet
d'examens périodiques réguliers pour garantir que les composants inutiles ou hérités ne réapparaissent
pas.
 Essai
Vérifiez que les modes de débogage du serveur Web ou d'application et du cadre d'application sont
désactivés en production pour éliminer les fonctionnalités de débogage, les consoles de développement
et les divulgations de sécurité involontaires.
 OWASP ASVS : 14.3.2
 Guide de test OWASP : configuration de la plate-forme d'application de test
8. SCRIPT INTERSITE

La description
Le Cross-Site Scripting (également connu sous le nom de XSS) est une vulnérabilité qui permet à un
acteur malveillant de manipuler les interactions d'un utilisateur légitime avec une application Web
vulnérable. Les attaquants exploitent cela pour contourner la même politique d'origine, ce qui leur
permet souvent d'effectuer toutes les actions que l'utilisateur cible effectuerait normalement, y compris
l'accès à leurs données. Dans les cas où l'utilisateur victime a un accès privilégié à l'application,
l'attaquant peut utiliser XSS pour prendre le contrôle de l'application.
Les attaques XSS se produisent généralement dans les applications Web lorsque des données sont
reçues, souvent sous la forme d'une requête Web, et les données sont reflétées dans la réponse HTTP à
l'utilisateur sans validation.
Les attaques XSS peuvent généralement être divisées en trois catégories.
XSS réfléchi
Les attaques XSS reflétées surviennent lorsqu'un serveur Web reflète un script injecté, tel qu'un résultat
de recherche, un message d'erreur ou toute autre réponse qui inclut tout ou partie des entrées envoyées
au serveur dans le cadre de la requête.
L'attaque est ensuite transmise à la victime par une autre voie (par exemple, e-mail ou site Web
alternatif), incitant ainsi l'utilisateur à cliquer sur un lien malveillant. Le code injecté se déplace vers le
site Web vulnérable, qui reflète la charge utile de l'attaque vers le navigateur de l'utilisateur. Le
navigateur exécute alors le code car il provient d'un serveur «de confiance».
XSS stocké
Dans l'attaque Stored XSS, le script injecté est stocké sur l'application cible en tant que contenu légitime,
tel qu'un message dans un forum, un commentaire dans un article de blog, etc. Le code injecté est stocké
dans la base de données et envoyé aux utilisateurs lorsque il est récupéré en accédant au contenu
injecté, en exécutant la charge utile d'attaque dans le navigateur de la victime.
 XSS basé sur Dom
Les vulnérabilités XSS basées sur DOM se produisent généralement lorsque le JavaScript d'une page
prend des données fournies par l'utilisateur à partir d'une source HTML, telle que le document.location,
et les transmet à une fonction JavaScript qui permet d'exécuter du code JavaScript, telle
que innerHTML(). L'attaque classique délivre la charge utile à la victime via une autre route (par
exemple, e-mail ou site Web alternatif) et incite ainsi l'utilisateur à visiter un lien
malveillant. L'exploitation se fait côté client et le code est immédiatement exécuté dans le navigateur
de l'utilisateur.

Impacter
Les attaques XSS peuvent entraîner la divulgation du cookie de session de l'utilisateur, permettant à un
attaquant de détourner la session de l'utilisateur et de prendre le contrôle du compte. Même
s'il HTTPOnlyest utilisé pour protéger les cookies, un attaquant peut toujours exécuter des actions au
nom de l'utilisateur dans le contexte du site Web affecté.
Comme pour toutes les vulnérabilités graves qui font partie du Top 10 de l' OWASP , les attaques XSS
peuvent entraîner une compromission totale du système d'un utilisateur. Comme indiqué dans la
description, si un attaquant compromet un utilisateur détenant les «clés du royaume», c'est-à-dire un
accès privilégié aux applications / droits d'administrateur, les résultats peuvent être dévastateurs.

La prévention
Les attaques XSS peuvent être atténuées en effectuant une validation et une échappement côté serveur
appropriées.
La correction repose sur l'exécution de l'encodage de sortie (par exemple en utilisant une syntaxe
d'échappement) pour le type de contexte HTML dans lequel des données non approuvées sont reflétées.
Validation d'entrée
 Correspondance exacte: n'acceptez que les valeurs d'une liste finie de valeurs connues.
 Liste d'autorisation: si une liste de toutes les valeurs possibles ne peut pas être créée, n'acceptez que les
données correctes connues et rejetez toutes les entrées inattendues.
 Liste de refus: si une approche par liste d'autorisation n'est pas possible (sur les zones de texte de forme libre,
par exemple), rejetez toutes les valeurs incorrectes connues.
Encodage de sortie
Le codage de sortie est utilisé pour convertir une entrée non approuvée en une forme sûre où l'entrée
est affichée sous forme de données à l'utilisateur sans être exécutée en tant que code dans le
navigateur. Le codage de sortie est effectué lorsque les données quittent l'application vers un
composant en aval. Le tableau ci-dessous répertorie les contextes en aval possibles dans lesquels
l'entrée non approuvée pourrait être utilisée:
 Le contexte Code Codage

Corps HTML <div>USER-CONTROLLED-DATA</div> Encodage HTML

Attribut <input type="text" value="USER-CONTROLLED- Codage des attributs

HTML DATA"> HTML

Paramètre <a href="/search?value=USER-CONTROLLED-

d'URL DATA">Search</a> Encodage d'URL

<div style="width: USER-CONTROLLED-

CSS DATA;">Selection</div> Encodage CSS Hex

<script>var lang ='USER-CONTROLLED-

DATA';</script>
<script>setLanguage('USER-CONTROLLED-
JavaScript DATA');</script> Encodage JavaScript

Le tableau suivant détaille une liste des méthodes de codage de sortie critiques requises pour atténuer
les scripts intersites:

Type
d'encodage Mécanisme d'encodage

Convertir &pour &amp;

convertir <pour &lt;
convertir >pour &gt;
convertir "pour &quot;
Encodage convertir 'pour &#x27;
d'entité HTML convertir /en&#x2F;

Codage des À l'exception des caractères alphanumériques, échappez tous les caractères au
attributs HTML format Entité HTML &#xHH;, espaces compris. ( HH = valeur hexadécimale)

Pour le codage en pourcentage standard, voir ici . Le codage d'URL ne doit être
Encodage utilisé que pour coder les valeurs des paramètres, et non l'URL entière ou les
d'URL fragments de chemin d'une URL.

Encodage Sauf pour les caractères alphanumériques, échapper tous les caractères avec
JavaScript le \uXXXXformat d'échappement unicode ( XX = Integer)
 Type
d'encodage Mécanisme d'encodage

CSS échappant prend en charge \XXet \XXXXXX. L'utilisation d'un échappement à

deux caractères peut poser des problèmes si le caractère suivant continue la
séquence d'échappement. Il existe deux solutions:
- Ajouter un espace après l'échappement CSS (il sera ignoré par l'analyseur CSS)
Encodage CSS - Utiliser toute la quantité d'échappements CSS possible en ne remplissant pas la
Hex valeur.

Défense en profondeur
Politique de sécurité du contenu (CSP)
La politique de sécurité du contenu (CSP) est un mécanisme de navigateur qui permet la création de
listes d'autorisation source pour les ressources côté client des applications Web, par exemple
JavaScript, CSS, images, etc. CSP via un en-tête HTTP spécial indique au navigateur d'exécuter ou de
restituer uniquement les ressources à partir de ces sources.
Par example:
Content-Security-Policy: default-src: 'self'; script-src: 'self' static.domain.tld
Le CSP ci-dessus indiquera au navigateur Web de charger toutes les ressources uniquement à partir de
l'origine de la page, ainsi que les fichiers de code source JavaScript à partir de static.domain.tld. Pour
plus de détails sur la politique de sécurité du contenu, y compris ce qu'elle fait et comment l'utiliser,
consultez cet article.
En-tête X-XSS-Protection
Cet en-tête de réponse HTTP active le filtre Cross-Site Scripting (XSS) intégré à certains navigateurs Web
modernes. L'en-tête est généralement activé par défaut de toute façon, son rôle est donc de réactiver le
filtre pour un site Web particulier s'il a été désactivé par l'utilisateur.
Utiliser un cadre moderne avec un système de modèles à échappement automatique
Les frameworks JavaScript modernes (par exemple AngularJS, ReactJS) ou les systèmes de modèles
côté serveur (par exemple les modèles Go) ont des protections intégrées robustes contre les scripts
intersites réfléchis.

Essai
Vérifiez que l'échappement de sortie sensible au contexte, de préférence automatisé - ou au pire, manuel
- protège contre le XSS réfléchi, stocké et DOM.
 OWASP ASVS : 5.3.1, 5.3.3
 OWASP Testing Guide : Testing for Reflected Cross Site Scripting , Testing for Stored Cross Site
Scripting , Testing for DOM-based Cross Site Scripting
9. DESERIALISATION NON SECURISEE

La description
La désérialisation non sécurisée (également appelée désérialisation non sécurisée) est une vulnérabilité dans
laquelle une entrée de données malformée et non fiable est utilisée pour compromettre la logique d'une
application, entraînant un déni de service ou même l'exécution de code arbitraire une fois l'entrée
désérialisée. Bien que ce ne soit pas exactement une attaque simple à utiliser, elle figurait dans le Top 10 des
itérations les plus récentes de l' OWASP en raison de la gravité de l'impact sur le compromis.
Le processus de conversion d'un état d'objet ou d'une structure de données en un format stockable ou
transmissible est appelé sérialisation. La désérialisation est son contraire - le processus d'extraction des
données sérialisées pour reconstruire la version originale de l'objet.
Des problèmes de désérialisation non sécurisés surviennent lorsqu'un attaquant est capable de transmettre
des données malveillantes ad hoc aux données fournies par l'utilisateur à désérialiser. Cela pourrait entraîner
une injection d'objets arbitraires dans l'application qui pourrait influencer le comportement correct de la
cible.

Impacter
Une attaque de désérialisation non sécurisée réussie peut entraîner le compromis total de la confidentialité,
de l'intégrité et de la disponibilité du système cible, et la violation d'Equifax souvent citée est probablement
le meilleur exemple du pire résultat qui puisse survenir. Dans le cas d'Equifax, une attaque de désérialisation
Java non sécurisée utilisant le framework Struts 2 a abouti à l'exécution de code à distance, ce qui, à son
tour, a conduit à la plus grande violation de données de l'histoire.

La prévention
Il est important de considérer tout projet de développement d'un point de vue architectural pour déterminer
quand et où la sérialisation est nécessaire. Si cela n'est pas nécessaire, envisagez d'utiliser un format plus
simple lors de la transmission des données.
 Dans les cas où il est impossible de renoncer à la sérialisation sans perturber l'intégrité opérationnelle de
l'application, les développeurs peuvent mettre en œuvre une gamme de mesures de défense en profondeur
pour réduire les risques d'exploitation.
 Utilisez la sérialisation qui n'autorise que les types de données primitifs.
 Utilisez une bibliothèque de sérialisation qui fournit des fonctionnalités de signature et de chiffrement
cryptographiques pour garantir que les données sérialisées sont obtenues sans être contaminées.
 Authentifiez-vous avant de désérialiser.
 Utilisez des environnements à faibles privilèges pour isoler et exécuter du code qui désérialise.
Enfin, si possible, remplacez la sérialisation des objets par des formats de sérialisation de données
uniquement, tels que JSON.

Essai
Vérifiez que la sérialisation n'est pas utilisée lors de la communication avec des clients non approuvés. Si
cela n'est pas possible, assurez-vous que des contrôles d'intégrité adéquats (et éventuellement un chiffrement
si des données sensibles sont envoyées) sont appliqués pour empêcher les attaques de désérialisation, y
compris l'injection d'objets.
 OWASP ASVS : 1.5.2, 5.5.1, 5.5.3
 10. JOURNALISATION INSUFFISANTE

La description
La journalisation et la surveillance insuffisantes constituent une catégorie assez large englobant l'installation
et la configuration non conformes aux normes d'outils de sécurité et de tactiques défensives, entraînant des
lacunes inhérentes à la capacité d'identifier les anomalies et / ou les intrusions dans un environnement. Le
problème est omniprésent, à tel point qu'en 2017, cette catégorie de risque assez large a été répertoriée pour
la première fois dans le Top 10 de l'OWASP. En effet, les acteurs malveillants s'appuient effectivement sur
l'absence ou le manque de surveillance efficace pour échapper à la détection suffisamment longtemps pour
déployer les outils qui conduiront à des compromis.
Une journalisation et une surveillance insuffisantes diffèrent des autres catégories du Top 10 de l'OWASP
car il ne s'agit pas d'une vulnérabilité techniquement exploitable en soi; il s'agit plutôt d'un ensemble (ou
comme son nom l'indique, d'un manque de) implémentations de détection et de réponse et de bonnes
pratiques qui, une fois combinées, pourraient se combiner en un échec de détection d'une violation, un retard
prolongé dans l'identification de la violation, et un ajout complexité lors de la réalisation de criminalistique
numérique post-violation.
L'un des principaux problèmes rencontrés par les équipes de sécurité et d'administration est que la quantité
de journaux générés dans un environnement peut être si vaste et répartie entre différents composants
technologiques au sein de l'environnement global, qu'une surveillance efficace peut devenir ... plutôt moins
efficace qu'optimale.
Il est essentiel d'assurer une journalisation et une surveillance efficaces dans tout environnement
d'infrastructure informatique; sans ces mécanismes en place, il est très difficile pour une organisation
d'évaluer son statut de sécurité.
Une journalisation et une surveillance insuffisantes se produisent lorsque:
 Les systèmes de gestion des informations et des événements de sécurité (SIEM) ne sont pas configurés
correctement et ne sont donc pas en mesure de traiter et de signaler les événements pertinents.
 Les journaux des applications, des appareils et / ou des API ne sont pas surveillés pour détecter tout
comportement anormal.
 Les avertissements générés servent à confondre, plutôt qu'à clarifier, les menaces.
 Les journaux ne sont pas correctement protégés et peuvent être exposés à un risque de falsification /
suppression par des acteurs malveillants couvrant leurs traces.
 Les connexions, les échecs de connexion et les transactions de grande valeur ne sont pas consignés en raison
d'une mauvaise configuration ou d'une non-configuration, ce qui entraîne des difficultés dans les processus
d'audit.
 Les journaux ne sont stockés que localement sans redondance.
 Impacter
Si les systèmes de journalisation et de surveillance sont à la fois installés et correctement configurés d'une
manière adaptée à leur environnement, les événements anormaux survenant dans un réseau ou contre une
application Web ont plus de chances d'être signalés et potentiellement arrêtés.
La genèse de la plupart des attaques réussies commence par la reconnaissance et la détection de la
vulnérabilité. Si, au cours de cette phase initiale d'évaluation, les sondes passent inaperçues en raison d'une
journalisation et d'une surveillance insuffisantes, la chance d'arrêter l'attaque prématurément est ratée,
augmentant ainsi la probabilité d'une exploitation réussie.
De plus, le délai pour identifier qu'une violation s'était même produite dans un environnement en 2017 était,
en moyenne, de 191 jours . Ainsi, mettre en évidence un exemple spécifique des ramifications d'outils,
d'équipes et de processus de journalisation et de surveillance mal mis en œuvre est un point assez discutable
puisque pratiquement toutes les attaques réussies ont réussi d'une manière ou d'une autre en raison d'une
surveillance insuffisante ou d'une action inefficace de la sortie de surveillance. .

La prévention
Déterminer les systèmes à renforcer et sur lesquels faire des compromis en raison de contraintes de
ressources est un choix important auquel doivent faire face les équipes responsables de la sécurité d'une
organisation. En règle générale, plus la valeur des données est élevée, plus les contrôles de sécurité, dans ce
cas, la journalisation et la surveillance, doivent être mis en œuvre pour déclencher l'alarme. Il est important
de noter que la journalisation à des fins de journalisation n'est pas une solution; trop de journaux font partie
du problème.
Les administrateurs doivent:
 Consignez les erreurs d'application, les erreurs d'exécution, les problèmes de connectivité, les erreurs du
système de fichiers et les modifications de configuration.
 Enregistrez les échecs de validation d'entrée, de connexion et de contrôle d'accès côté serveur, avec
suffisamment de détails sur l'utilisateur.
 Enregistrez les fonctionnalités à haut risque, y compris l'accès aux données des titulaires de carte de
paiement, les modifications de clé, l'utilisation de la clé de cryptage des données, toutes les actions des
comptes d'utilisateurs administratifs, l'ajout ou la suppression de jetons, etc.
 Assurer la collaboration interministérielle et la clarté concernant les besoins juridiques et de conformité au
sein de l'organisation, ainsi que la journalisation et la surveillance nécessaires pour se conformer à tout cadre
réglementaire, tel que Sarbanes-Oxley, PCI-DSS ou HIPAA.
 Convertissez les flux de journaux en un système de journalisation vérifiable et centralisé avec une
redondance adéquate.
 Assurez-vous que les pistes d'audit et les dispositions de sécurité supplémentaires sont mises en œuvre pour
empêcher la falsification des journaux.
 Créez un plan de réponse aux incidents qui garantit que les journaux peuvent être fournis en cas d'audit post-
violation.
 Essai
Assurez-vous que les journaux de l'application sont clairs et peuvent être facilement surveillés et analysés
localement ou expédiés à un système de surveillance à distance.
 OWASP ASVS : 7,2
 Guide de test OWASP : configuration de la plate-forme d'application de test
Les références
OWASP - Journalisation et surveillance insuffisantes
MITRE - CWE-778 Journalisation insuffisante