Sécurité web

Question 1

Composantes impliquées durant l’authentification

Answer 1

• Client légitime
• Client malicieux
• server Web
• Server d’authentification
• Server d’application
• Server BD

Question 2

Authentification du serveur : Caractéristiques

Answer 2

• Canal de communication sécurisé (https)
• Challenge - Response (NTLM, kerberos)
• Réhautentification à des intervalles régulières
• Permission des usagers
• tester

Question 3

Authentification du serveur : Authentifier le client

Answer 3

• Nom d’utilisateur + Mot de ass
• Certificat X509 sur le porte client
• Carte à use (smartcard)

Question 4

Authentification du serveur : Authentifier le server

Answer 4

• Certificat X509
• Certificat SSL
• Image personnalisée
• Autres

Question 5

De quel coté fait on la vérification des données usager (Input Validation)

Answer 5

Client légitime

Question 6

De quel coté devrait on faire de l’input validation?

Answer 6

• Client légitime
• Pare-feu
• serveur web
• serveur d’aplication
• server BD
• Serveur d’authentification

Question 7

Attaques sur l’input Validation

Answer 7

• injection SQL
• Cross Site Scripting (XSS) (non-persistent et persistent)
• Cross Site Request Forgery (XSRT)
• Remote File Inclusion
• Variable Tampering
• Interface redressing (clickjacking)

Question 8

Exemple d’injection SQL dans le champ password

Answer 8

’ or ‘1’ = ‘1
résultat dans la page web :
*’ ‘ or ‘1’=’1 *’

Question 9

Exemple XSS non persistent (qui reste pas)

Answer 9

<u>Super</u>

Question 10

Exemle XSS persistent

Answer 10

document.location.href=“http://boteanu.com”

Question 11

Où valider les données de l’usager?

Answer 11

Sur le serveur Web et/ou sur le serveur d’applications

Question 12

Comment valider les données de l’uager?

Answer 12

• 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

Question 13

Comment valider les données de l’uager (autre)?

Answer 13

• 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

Question 14

Comment vérifier si un site est vulnérable?

Answer 14

• 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

Question 15

Cross-Site Request Forgery: Comment se protéger

Answer 15

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)

Question 16

Hameçonnage (physhing) : description

Answer 16

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

Question 17

Hameçonnage (physhing) : Comment se protéger?

Answer 17

• filtrer le spam
• Authentifcation du serveur
• Eduquer les utilisateurs

Question 18

Logique de l’application

Answer 18

• 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)

Question 19

Conclusion

Answer 19

• 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)