sécurité des applications web

© Klee Group Prez Flash Sécurité des applications Web Julien Bourdin 111

Prez Flash :: Sécurité des applications Web

Auteur : Julien Bourdin


Agenda

Introduction

Le concept de sécurité

Les protections indispensables

Les attaques typiques


Objectif de la présentation

Cette présentation a pour but de présenter un large ensemble de problèmes de sécurité à prendre en compte dans un projet web.

La présentation précisera en premier ce que le terme « sécurité » signifie au sens large, son périmètre et le discours qui doit l’accompagner.

Ensuite, la présentation passera en revu un certain nombre des attaques possibles contre une application web en expliquant comment elles procèdent et surtout comment s’en prémunir


Agenda

Introduction






La sécurité est une gestion des risques.


La gestion des risques

Lister les évènements qui peuvent survenir

Estimer la probabilité de les voir arriver

Estimer le coût lorsqu’un évènement se

produit

Estimer le coût pour réduire la chance que

l’évènement en question se produise

Méthodologie EBIOS


La gestion des risques

Le coût du risque

Probabilité du risque que multiplie le coût de l’évènement : P x C

À comparer avec le coût pour réduire le risque et au coût des autres risques.

Conséquences

Tout risque identifié n’est pas un risque à corriger, on compare le coût de chacun des risques

Tout comme il existe de la surqualité, il existe des abus de sécurité

Il n’est pas possible de réduire à 0 l’ensemble des risques !


Les différents domaines de la sécurité

Intégrité des données

Confidentialité des données

Disponibilité des services

Responsabilité des personnes


Les différents domaines de la sécurité

Intégrité des données

Transactions, Détection des incohérences, Sauvegarde

Confidentialité des données

Authentification, Droits d’accès, Détection d’intrusion

Disponibilité des services

Redondance, Récupération après incident, DOS, Supervision

Responsabilité des personnes

Usage indu, Traçabilité, Maintenance


La sécurité est une chaîne

Chaque composant et chaque acteur apportent des risques

Sur un type de menace donné, l’application à la sécurité de son maillon le plus faible

La solution la plus efficace pour réduire le risque n’est pas nécessairement une solution technique

Inutile de mettre une porte blindée si les murs sont en papier

Inutile d’avoir une serrure 5 points si on laisse les clefs sous le paillasson

Inutile d’avoir un SSO complexe si votre mot de passe est « 1234 » ou « password »


La sécurité est un investissement

Les bonnes pratiques, une fois acquises, permettent un niveau de sécurité correcte

à moindre coût.


Agenda

Introduction





la première faille de sécurité


L’être humain est la première faille de sécurité

Tout collaborateur n’est pas aussi bienveillant qu’on le souhaiterait :

la majorité des sabotages sont le fait de collaborateurs dans les entreprises

Les relations hiérarchiques sont plus fortes que les règles de sécurité :

une secrétaire donne à son patron le mot de passe par téléphone s’il lui demande.

La vigilance n’est pas une culture

On ne vérifie pas l’identité de la personne qui arrose les plantes

On prête son compte à son collègue pour ses congés

On n’aime pas les contraintes pesantes !


Il est important de former et d’informer

Ce qui est vécu comme une contrainte est souvent contourné

Ce qui semble anodin n’est pas source d’attention

Seule la formation de chaque personne permet de limiter le « piratage social »

Il faut donc responsabiliser

les utilisateurs

les décideurs

les concepteurs

les développeurs

les exploitants


Sécurité : la valeur des procédures

Toute intervention sur un système apporte le risque d’introduire de nouveaux problèmes

Cela est encore plus vrai dans le cas de systèmes complexes comme les systèmes d’informations

La disponibilité, la confidentialité et la cohérence des systèmes sont menacées lors de chaque intervention

Chaque intervention doit déclencher des contrôles précis sous une responsabilité précise

Un journal des interventions doit être tenu

L’état antérieur à l’intervention doit pouvoir être restauré

Il est indispensable de formaliser les interventions récurrentes (livraisons, maintenances préventives…)

Il est indispensable de tracer toutes les interventions sur un support consulté par les exploitants


Les failles évidentes

Essayez donc /typo3/install


Les failles évidentes

Changer les mots de passe par défaut

Supprimer les dossiers et fichiers inutiles (MISC, .bak, .sql)

Utilisez du HTTPS si votre application transmet des mots de passe en clair

Ayez des certificats valides pour votre HTTPS

Limitez l'accès au back-office / à l’application aux personnes pertinentes par une

technique forte (LAN ou VPN)

Mettez à jour les logiciels supports et les bibliothèques

Choisissez vos bibliothèques (en évitant les versions obsolètes ou expérimentales)

Désactivez l'option "indexes" d'APACHE


Gestion des comptes

Un compte utilisateur doit être attaché à une unique personne

L’accès doit être restreint par des mots de passe non triviaux

Interdiction d’utiliser le login ou un mot de passe par défaut !

Interdiction d’utiliser le prénom de sa fille ou son année de naissance !

Interdiction d’utiliser les mots de passe type de l’entreprise !

Les droits doivent appartenir à des groupes

Les droits donnés sont ceux nécessaires et suffisants pour les tâches confiées

La délégation se fait en donnant des droits au compte du responsable par délégation

Un mot de passe ne doit jamais être transmis, encore moins pas courriel


Limiter la portée des intrusions

Une brèche ne doit pas emporter tout le système !



Limitez les comptes superadmin le plus possible

Un administrateur KLEE, un chez le client s’il a la compétence

Activez un envoi de mail avertissant de la connexion d’un compte superadmin

N’utilisez ce type de compte que pour les actions le nécessitant !

Limitez les privilèges : les comptes administrateurs



Les droits d’écriture sur les fichiers ne sont pas donnés à Apache / TomCat / … en dehors de de quelques répertoires bien choisis

les livraisons sont faites avec un compte distinct

Ne laissez pas en production d‘outils donnant accès à la base de données ou au système de fichiers (phpmyadmin, terminal virtuel, etc.)

Interdisez la livraison de contenus exécutables par l’interface Web (cas des produits à modules)

Limitez les privilèges : les droits d’écritures



Sauvegardez

vos environnements

vos données

Vérifiez le bon fonctionnement de ces sauvegardes

Validez les processus de restauration

Cryptez les données confidentielles (mot de passe) et ne laissez pas de dumps

accessibles

Assurez-vous de la conservation des données



N’accordez qu’un crédit limité à une protection donnée


Surveillez les indicateurs de votre site

Vérifiez dans les logs si des URL inconnues existent

Cherchez si des variations de bande passante/nombre de hit apparaissent

Vérifiez que l’espace disque, la mémoire occupée ou la charge CPU

Réagissez en cas de doute !


Agenda

Introduction





Le déni de service


Qu’est-ce que le déni de service ?

Une attaque en déni de service vise à rendre impossible le bon fonctionnement d’un service en saturant un composant de l’architecture rendant ces services.

Il peut donc s’agir de saturer de requête la plateforme, mais cela peut aussi prendre des tours plus particuliers

Saturation de la base de données

Appel répété sur le moteur de recherche ou sur certaines pages vulnérables

Ajout de scripts infinis dans un contenu

L’objet peut être simplement le déni de service, mais cela peut aussi avoir comme but de faire disparaître le serveur pour usurper ensuite son identité (spoofing)


Se protéger contre le déni de service : attaque frontale

Dimensionnez votre plateforme pour une pointe de trafique pertinente

Activez les caches applicatifs et empêcher les contournements de ces derniers

Mettez un reverse proxy avec un timeout : Il faut pouvoir délester en retournant un message d’erreur

Limitez les pools de connexions à la BDD et les processus Apache

Supervisez et alertez en cas de montée en charge non anticipée


Se protéger contre le déni de service : écritures

Limitez les possibilités d’écriture sur le serveur : pas de dépôt de fichiers ni d’écriture en base non régulés

N'écrivez pas en base de données depuis un accès anonyme sauf avec protection anti-robot (livre d'or, commentaire, etc.)

Supervisez l'espace sur file system et dans la BDD : alerte lors de franchissement de seuils !


Se protéger contre le déni de service : un exemple sur TYPO3

Le cache de TYPO3 est en base de données ! Une URL n’est acceptée que si elle répond à un certain nombre de critères comme la validité des paramètres soumis.

Sont acceptées par défaut les variables « id » et « type »

Les autres variables ne sont valables que si elles ont été signées par la génération d’une URL depuis TYPO3. La signature, le cHash, est le résultat d’un MD5 des données concaténées et d’une clef privée du serveur

http://monsite.com/index.php?id=2&L=3&tx_ttnews[tt_news]=23&cHash=a7024cb7


Le spam depuis votre serveur

Votre serveur peut devenir une source de spam !


Le spam depuis votre serveur

Un serveur capable d’envoyer des mails doit être maîtrisé !

Le risque est de voir un écran exploité par un robot pour diffuser largement des publicités

Un écran pouvant provoquer l’envoi d’un mail doit respecter au moins une des règles ci-dessous :

Le courriel est destiné à une unique boîte à lettres (contact)

Le formulaire ne peut être soumis qu’après un test identifiant un humain plutôt qu’un robot

Le courriel aura un contenu fixe, dépendant de paramètre non modifiable sur l’écran

Les courriels ne peuvent être envoyés que sur un domaine interne (intranet)

La quantité de courriels envoyés par l’application doit être supervisée

Vous risquez, en cas de souci, de voir votre serveur d’envoi de courriel dans les listes noires


L’injection SQL

Une injection SQL est l’utilisation d’instruction du langage SQL au sein d’un paramètre sensé ne contenir que de la donnée.


Exemple : la connexion par login et mot de passe

SELECT * FROM USERS WHERE LOGIN = '$_GET['login']' AND PASSWORD =

'$_GET['password']';

Il lui suffit donc de saisir Monlogin';# pour que la requête devienne :

SELECT * FROM USERS WHERE LOGIN = 'Monlogin';#' AND PASSWORD = '';

La bonne méthode consiste à considérer la saisie comme des caractères non

susceptibles de déclencher des commandes MySQL (voir mysql_real_escape_string)

SELECT * FROM USERS WHERE LOGIN = 'Monlogin\'; \#' AND PASSWORD = '';

Note : en aucun cas, la requête présentée n’est la bonne façon de gérer une authentification !


Se prémunir de l’injection SQL

Si possible, préférez les requêtes préparées (prepared statement) qui n’attendent que

des données et qui ne sont donc pas sensibles à l’injection

Vérifiez toujours la nature des données insérées dans les requêtes

Ne donnez à l’utilisateur SQL de l’application que le minimum de droits nécessaires

(pas de DROP, TRUNCATE…)

Ne stockez pas en base de mots de passe lisibles

Ayez des sauvegardes régulières des données

Utilisez les mécanismes du Framework / de l’API / du Langage pour générer le SQL


L’injection SQL au quotidien


L’injection de script (XSS)


L’injection de script (XSS)

Le principe de cette stratégie d’attaque est de profiter de l’affichage de données

envoyées par l’utilisateur pour inclure des éléments de HTML ou de script non prévu

Le moyen d’en faire une agression est d’inclure du script qui va soumettre à l’extérieur

la saisie de données confidentielles

Pour arriver à créer ce contexte, il faut fournir par un moyen ou un autre, une URL

portant ces données. Ce sera typiquement par l’envoi de mails malicieux ou par une

mise en ligne d’un lien sur un autre site


Le Cross Site Scripting : cas concret

Un moteur de recherche propose un champ de saisie et passe les données sous la forme : http://www.monsite.fr/index.php?wsearch=mot_recherche

Les résultats sont présentés avec un rappel « votre recherche : mot_recherche »

Si on remplace dans l’URL par wsearch=<script type="text/JavaScript">…</script> (moyennant un encodage de l’URL)

On obtient une page dans laquelle, selon le traitement, on a un script inclus et interprété là où l’on croyait avoir un simple mot


Le XSS : vérifier le type de vos sorties !

Normalement, une donnée utilisateur est d’un type simple :

Nombre

Texte

choix dans un menu déroulant…

Ce ne sont pas des typages techniques !

Une chaîne de caractère et un texte simple ne sont pas la même chose

Le cas simple : prendre la donnée à afficher et s’assurer que tous les caractères ne

sont pas interprétés en HTML : htmlspecialchars en PHP

Les cas complexes : autorisations de certaines balises par une analyse spécifique


Bonne pratique : la programmation par contrat

Chaque méthode définit le format de ses entrées et de ses sorties

Les variables sont vérifiées par des assertions qui, en cas de non-respect, stoppent l’exécution

function mafonction($a,$b){assertion(type1,$a); assertion(type2,$b);$retour = corpsdemethode();assertion(typesortie,$retour);return $retour;

}

Ce motif est à appliquer le plus souvent possible

Il est impératif chaque fois que l’on définit un service recevant des données utilisateurs, proposant des données pour affichage ou devant agir sur les contenus


Le Cross Site Request Forgery (CSRF)



La plupart des outils utilisent, avec raison, des URLs explicites:

http://www.monsite.fr/index.php?action=supprimer&id=35

Ces URL sont donc prévisibles même pour un utilisateur n’ayant pas le droit d’exécuter celle-ci

Une personne va donc tenter de faire jouer cette URL à une personne ayant les droits à son insu

En proposant le lien dans le href d’une balise image sur une page susceptible d’être consultée

En proposant un JavaScript de la même façon



L’agression est difficile à détecter : c’est une personne ayant les droits qui fait les actions

La faiblesse est accrue par les contextes de type SSO : la personne peut ne pas encore s’être authentifié à l’application et faire toutefois l’action

L’attaque est d’autant plus facile à mener que les URL d’écriture passent leur paramètre en GET (possibilité d’utiliser des liens simple)



Il faut ajouter un élément non prévisible dans les URL

Il faut que les URL ne soient pas rejouable

Exemple de solution : ajouter une date et une signature du serveur

http://www.monsite.fr/index.php

?action=supprimer&id=35&date=timestamp&cHash=jgs37829DE

Il faut évidemment également privilégier l’usage de POST au lieu de GET pour toute action de modification de données !


Questions ?


Questions ?

Retrouvez-nous sur le blog technique de KLEE

http://blog.kleegroup.com/teknics

[email protected]@teKnics_Klee

http://blog.kleegroup.com/teknics

mailto:[email protected]

https://twitter.com/#!/teknics_klee

https://twitter.com/#!/teknics_klee

sécurité des applications web

Technology

scurit intgrit

scurit correcte moindre

projet web

terme scurit signifie

scurit prendre en compte

risque et au cot

vigilance nest pas une

confidentialit et