Sécurité Des Applications Web

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
●
– Utilisation des requêtes paramétrées
String custId = request.getParameter("custId");
String query = "SELECT * FROM accounts WHERE custId = ? ";
PreparedStatement pstmt = connection.prepareStatement( query );

pstmt.setString( 1, custId);
ResultSet results = pstmt.executeQuery( );
Injection
●
– 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
●
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...
●
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

Sécurité Des Applications Web

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

Transféré par

Droits d'auteur :

Formats disponibles

Sécurité des applications web

Sécurité des applications web

– La requête SQL qui permet de récupérer les informations du

PreparedStatement pstmt = connection.prepareStatement( query );

Qui contient le code HTML suivant

Vous aimerez peut-être aussi