Composantes impliquées durant l’authentification
- Client légitime
- Client malicieux
- server Web
- Server d’authentification
- Server d’application
- Server BD
Authentification du serveur : Caractéristiques
- Canal de communication sécurisé (https)
- Challenge - Response (NTLM, kerberos)
- Réhautentification à des intervalles régulières
- Permission des usagers
- tester
Authentification du serveur : Authentifier le client
- Nom d’utilisateur + Mot de ass
- Certificat X509 sur le porte client
- Carte à use (smartcard)
Authentification du serveur : Authentifier le server
- Certificat X509
- Certificat SSL
- Image personnalisée
- Autres
De quel coté fait on la vérification des données usager (Input Validation)
Client légitime
De quel coté devrait on faire de l’input validation?
- Client légitime
- Pare-feu
- serveur web
- serveur d’aplication
- server BD
- Serveur d’authentification
Attaques sur l’input Validation
- injection SQL
- Cross Site Scripting (XSS) (non-persistent et persistent)
- Cross Site Request Forgery (XSRT)
- Remote File Inclusion
- Variable Tampering
- Interface redressing (clickjacking)
Exemple d’injection SQL dans le champ password
’ or ‘1’ = ‘1
résultat dans la page web :
*’ ‘ or ‘1’=’1 *’
Exemple XSS non persistent (qui reste pas)
<u>Super</u>
Exemle XSS persistent
document.location.href=“http://boteanu.com”
Où valider les données de l’usager?
Sur le serveur Web et/ou sur le serveur d’applications
Comment valider les données de l’uager?
- Exact Match (juste true or false)
- Whitelisting (i.e. juste (a-zA-Z)+ permis, regex)
- Blacklisting (i.e. “SELECT” “JOINT” pas permis)
- Encoding (i.e. addshashes(), htmlentities() )
autre : Limiter la taille de l’entrée
Comment valider les données de l’uager (autre)?
- Utiliser les SQL stored procedures
- Gérer les permissions sur la base de données (usagers, rôles, permissions)
- Messages d’erreur
- Pare-feu applicatif (software : ModSecurity, Microsoft ISA Server $$$); Appliance : Cisco, Fortinet, Checkpoint, etc.)
- Verifications
Comment vérifier si un site est vulnérable?
- Rien fait pour se protéger –> probablement vulnérable
- Développé sans gestion de projet –> probablement vulnérable
- Outils automatiques :
- nikto
- Acunetix ($$$$ mais gratuit pour test de XSS)
- WebScarab
Cross-Site Request Forgery: Comment se protéger
Token aléatoire :
- Envoyé au moment du login
- Stocké dans les varaibles de session du côté serveur
- Ne pas stocké dans un cookie du coté client, mais
- Présent dans les liens des toutes les autres pages
- Vérifié par le serveur poue chaque page
( vérification de la variable secureToken échouée –> Session fermée)
Hameçonnage (physhing) : description
Client maliceus envoi un message avec un faux lien (ressemblait à un lien légitime), le client légitime clique et le renvoie sur un faux server web
Hameçonnage (physhing) : Comment se protéger?
- filtrer le spam
- Authentifcation du serveur
- Eduquer les utilisateurs
Logique de l’application
- Chaque attaque est différente
- Exploite la logique de l’application
- Difficile (impossible) à détecter par des outils automatiques
- Code review
- Exemples : faire un donc de 100$, créer un million d’usagers et écrire des messages dans un forum, enlever le câble réseau au milieu d’une partie d’échec)
Conclusion
- Attaque Web très populaires
- Facile de créer une application vulnérable
- Validation des données usager
- Éducation des usagers
- Princie de sécurité de l’oignon (layered security)
