Ce document décrit les principales failles de sécurité des applications web telles que l'injection, le cross-site scripting et le vol de sessions, ainsi que les moyens de s'en prémunir comme l'échappement des caractères spéciaux et l'utilisation de requêtes paramétrées.
0 évaluation0% ont trouvé ce document utile (0 vote)
36 vues19 pages
Ce document décrit les principales failles de sécurité des applications web telles que l'injection, le cross-site scripting et le vol de sessions, ainsi que les moyens de s'en prémunir comme l'échappement des caractères spéciaux et l'utilisation de requêtes paramétrées.
Ce document décrit les principales failles de sécurité des applications web telles que l'injection, le cross-site scripting et le vol de sessions, ainsi que les moyens de s'en prémunir comme l'échappement des caractères spéciaux et l'utilisation de requêtes paramétrées.
Ce document décrit les principales failles de sécurité des applications web telles que l'injection, le cross-site scripting et le vol de sessions, ainsi que les moyens de s'en prémunir comme l'échappement des caractères spéciaux et l'utilisation de requêtes paramétrées.
Téléchargez comme PDF, TXT ou lisez en ligne sur Scribd
Télécharger au format pdf ou txt
Vous êtes sur la page 1/ 19
Sécurité des applications web
Sécurité des applications web
● Principales failles/attaques des applications web – Liste non exhaustive, mais les plus courantes ● Attaques, erreurs... – Moyen de s’en prémunir Injection ● Des données non fiables sont envoyées à interpréteur en tant qu’élément d’une requête ● Ces données peuvent duper l’interpréteur et lui faire exécuter des commandes non prévues, et ainsi permettre de récupérer ou modifier vos données ● Par exemple en SQL, LDAP, Xpath… ● Impact : vos données peuvent être corrompues, dérobées, ou supprimées Injection ● Exemple SQL : – L’url suivante permet de visualiser le compte d’un utilisateur en fournissant l’id ● http://example.com/app/accountView?id=1
– La requête SQL qui permet de récupérer les informations du
compte est la suivante String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id")+ "'"; – L’attaquant va exploiter l’argument de l’url pour faire éxécuter une requête différente de celle prévue ● L’argument sera 1 or 1=1 ● http://example.com/app/accountView?id='1 or '1'='1 Injection ● La requête devient SELECT * FROM accounts WHERE custID= '1 or '1'='1' ● La condition WHERE est toujours vrai ● ⇒ L’ensemble des comptes utilisateurs est retourné. Un attaquant peut donc récupérer des informations des comptes utilisateurs Injection ● L’utilisateur fournit cette fois l’argument suivant 105'; DROP TABLE accounts ;--
● La requête devient donc SELECT * FROM accounts WHERE custId = '105'; DROP TABLE accounts ;--'
● En devinant le nom de la table, l’utilisateur peut en effacer le contenu. ● Une requête similaire avec un ALTER, un UPDATE ou un INSERT peut modifier la structure de la table, modifier son contenu Injection ● Comment s’en prémunir – Échappement des caractères spéciaux ● Remplacer les ' par \' ● En PHP mysqli_real_escape_string – La requête devient SELECT * FROM accounts WHERE custID= '1 or \'1\'=\'1' ● Le SGBD ne trouve aucun utilisateur Injection ● Comment s’en prémunir – Utilisation des requêtes paramétrées String custId = request.getParameter("custId"); String query = "SELECT * FROM accounts WHERE custId = ? ";
pstmt.setString( 1, custId); ResultSet results = pstmt.executeQuery( ); Injection ● Comment s’en prémunir – Nettoyer les entrées avec échappement des caractères spéciaux et/ou – Utilisation des requêtes préparées et/ou – Utilisation de procédures stockées et/ou – Valider les entrées par une liste blanche
xkcd.com Cross-site Scripting (XSS) ● L’attaquant envoie des scripts qui exploitent interpréteur du navigateur ● Ces failles sont introduites lorsque l’application inclut dans la page des données fournies par l’utilisateur ● Attaque très fréquente qui a touché Twitter, Facebook, Youtube... ● Impact : l’attaquant peut exécuter des scripts dans le navigateur de sa victime : – Vol de sessions – Défaçage des sites – Redirection vers un site malveillant Cross-Site Scripting (XSS) ● Soit la page suivante http://xxs.example.com/?name=Bob
Qui contient le code HTML suivant
<html><body><p>Hello Bob! Welcome!<p></body></html> ● Cette page permet de personnaliser l’accueil du visiteur avec son nom ● Si à la place du nom on entre Bob<script>alert(“Vulnerable!”)</script> ● Le code HTML devient <html><body><p>Hello Bob<script>alert("Vulnerable")</script>! Welcome! <p></body></html> ● Le navigateur interprétera le code, il ne le considère pas comme du texte Cross-Site Scripting (XSS) ● L’exemple précédent n’affiche simple qu’une fenêtre ● Le script s’il pointe vers un script que l’on a préparé, peut permettre des actions plus préjudiciables pour l’utilisateur, comme le vol de sa session, le rediriger vers un autre site... Cross-Site Scripting (XSS) ● Contrer cette attaque – Ne jamais autoriser des données non vérifiées – Nettoyer les entrées en échappant les caractères <,>,' et avec htmlspecialchars, htmlentitties qui vont transformer ces caractères spéciaux Validation des paramètres ● Les champs de formulaire peuvent avoir des restrictions vérifiées du côté client ● Un utilisateur peut tout a fait contourner ces restrictions (en désactivant Javascript par exemple) ● ⇒ Toujours vérifier la validité des paramètres coté serveur Capture de paquet ● En http, les paquets transitent en clair, et donc les données également ● Ces données peuvent être interceptées par quelqu’un à l’écoute sur le réseau (réseau wifi public par exemple) – Un attaquant pour récupérer votre session (cf Firesheep) ● ⇒ Chiffrement de la connexion avec https Vol de sessions ● Le vol de session – Avec une faille XSS – L’id de connexion est en clair dans l’url – Pas d’expiration de session – Les mots de passe sont stockés en clair dans la base de donnée – Connexion non chiffrée Déni de service (DOS) ● Un site web peut être rendu indisponible en lui imposant au serveur de plus de traitement qu’il n’est capable de supporter ● Version distribuée de cette attaque DdoS ● ⇒ Protection au niveau du réseau Mauvaise configuration du site ● Logiciel et bibliothèques du serveur à non mis à jour ● Fonctions inutiles activées ( ports, compte, pages…) – Scan des ports ouvert avec nmap ● Mot de passe par défaut inchangé ● Messages d’erreur de l’application affichés aux utilisateurs Références ● Open Web Application Security Project – https://www.owasp.org/ – https://www.owasp.org/index.php/Top_10-2017_To p_10 ● https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_Securite_Web_NoteTech.pdf
