Transcript Securite-T3UNI11_final

TYPO3 et la Sécurité de l’information
29.06.2011
Julien BOURDIN <[email protected]>
Julien Bourdin
Architecte PHP / Développeur TYPO3
KLEE GROUP
Profil : Architecte, chef de projet
Certifié TYPO3 Integrator
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Introduction
Objectif de la présentation
Cette présentation a pour but de présenter un large ensemble de problèmes à prendre en compte
dans un projet TYPO3.
La présentation précisera en premier ce qui rentre dans le périmètre du terme « sécurité » et les
premières conséquences.
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
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Sommaire
Le concept de sécurité
Les failles humaines et les piratages sociaux
Les failles évidentes
La stratégie pour limiter la portée des intrusions
Les Deny Of Services (DOS)
Le spam côté serveur
L’injection SQL
L’injection de script (XSS)
Le Cross Site Request Forgery (CSRF)
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Le concept de sécurité
La sécurité est une gestion des risques.
Les différents risques
Intégrité des données
Confidentialité des données
Disponibilité des services
Responsabilité des personnes
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Les différents risques
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
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
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
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Le coût du risque
Probabilité du risque que multiplie le coût de l’évènement : Pe x C/e
A 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 sur-qualité, il existe des abus de sécurité
Il n’est pas possible de réduire à 0 l’ensemble des risques !
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
La sécurité est une chaîne
Chaque composant et chaque acteur apporte 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 »
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
La sécurité est un investissement
Pour les responsables de l’application
Pour les utilisateurs
Pour les développeurs
Les bonnes pratiques, une fois acquises, permettent un
niveau de sécurité correcte à moindre coût.
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Les failles humaines et les piratages sociaux
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 aime pas les contraintes pesantes !
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
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
Il faut donc responsabiliser
Les utilisateurs
Les décideurs
Les concepteurs
Les développeurs
Les exploitants
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
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 !
Les droits doivent appartenir à des groupes
Les droits données sont ceux nécessaires et suffisant 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
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Les failles évidentes
Essayez donc /typo3/install avec joh316 !
Les évidences qu’on oublie quand même
Changer les mots de passe par défaut (admin/password et joh316)
Mettez à jour TYPO3, ses extensions, ainsi que les logiciels support (LAMP)
Supprimer les dossiers et fichiers inutiles (MISC, .bak, .sql)
Désactivez l'opions "indexes" d'APACHE
Limitez l'accès au BE aux personnes pertinentes par une technique forte (LAN ou VPN)
Choisissez vos extensions (en évitant les "alpha/expérimental" de 2006)
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Limiter la portée des intrusions
Une brèche ne doit pas emporter tout le système !
Pour limiter la portée d’une intrusion dans TYPO3
Limitez les comptes admin le plus possible (1 pour vous, 1 pour le client)
Activez l'envoi de mail avertissant de la connexion d’un compte admin
Les droits d’écriture sur les fichiers ne sont pas donnés à APACHE en dehors de typo3temp et
quelques répertoires bien choisis (idéalement les livraisons sont faites avec un compte distinct)
Ne laissez pas en production d'extension donnant accès à la base de données ou au système de
fichiers (quixplorer, phpmyadmin, terminal virtuel, etc...)
Interdisez la livraison d’extension en production depuis le BE (option dans l'install tool + droit sur le
repertoire typo3conf/ext)
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Surveillez les indicateurs de votre site
Vérifiez dans les logs si des URL inconnues existent (avec Awstats par exemple)
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 ne changent pas façon inattendue
Réagissez en cas de doute !
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Les déni de services
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
disparaitre le serveur pour usurper ensuite son identité (spoofing)
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Se protéger contre le déni de service : attaque frontale
Dimensionnez votre plateforme pour un traffique de pointe pertinent
Activez les caches de TYPO3 et interdisez l’utilisation de « no_cache » dans l’URL (typo3/install)
Mettez un reverse proxy avec du cache
Limitez les pools de connexions MySQL et les processus Apache et mettez un timeout sur le reverse-
proxy (Il faut pouvoir délester en retournant un message d’erreur)
Supervisez et alertez en cas de montée en charge non anticipée
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
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 non régulés ni d’écriture en
base
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 !
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Se protéger contre le déni de service : le cHash
Le cache de TYPO3 est en base de données ! Une URL n’est mise en cache que si elle répond à un
certain nombre de critère dont la validité des paramètres soumis.
Sont acceptées par défaut les variables « id » et « type »
Sont acceptées sans signature les variables déclarées dans config.linkVars (TSsetup) A limiter par une
plage de valeur config.linkVars=L(0-4)
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
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Se protéger contre le déni de service : le cHash
Ex : http://monsite.com/index.php?id=2&L=3&tx_ttnews[tt_news]=23&cHash=a7024cb7
Générez vos URL à l’aide des méthodes de l’API TYPO3 :
TYPOLINK ou tslib_pibase->pi_linkTP_keepPIvars
Générez une clef unique après l’installation de TYPO3 (install TOOLS)
Forcez vos plugin à prendre en compte la validité des hachage :
var $pi_checkCHash = TRUE; dans class tx_monplugin_pi1 extends tslib_pibase
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Le spam côté serveur
Votre serveur peut devenir une source de spam !
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 boite à lettre (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 mail 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
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
L’injection SQL
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.
Elle est le plus couramment utilisée sur les champs d’un formulaire front-office mais peut également
se faire par l’URL.
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
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 est la bonne façon de gérer l’authentification !
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Se prémunir de l’injection SQL
Ne donner à l’utilisateur SQL que le minimum de droit nécessaire (pas de DROP, TRUNCATE,…)
Ne pas stocker en base de mot de passe lisibles (fe_users !)
Avoir des sauvegardes régulières de nos bases
Toujours vérifier la nature des données insérées dans les requêtes
Si possible, préférer les requêtes préparées (prepared statement) qui n’attendent que de la données
pour leurs paramètres (disponibles depuis TYPO3 4.5 LTS)
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Se prémunir de l’injection SQL dans TYPO3
Utiliser l’API
$GLOBALS['TYPO3_DB']->exec_SELECTquery()
$GLOBALS['TYPO3_DB']->exec_SELECTgetRows()
$GLOBALS['TYPO3_DB']->exec_INSERTquery()
$GLOBALS['TYPO3_DB']->exec_UPDATEquery()
$GLOBALS['TYPO3_DB']->exec_DELETEquery()
Lire la documentation de chaque méthode pour vérifier l’usage de fullQuoteStr()
Optional additional WHERE clauses put in the end of the query. NOTICE: You must escape
values in this argument with $this->fullQuoteStr() yourself!
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Se prémunir de l’injection SQL dans TYPO3
foreach ($this->piVars as $key => $value) {
$value = $GLOBALS['TYPO3_DB']->fullQuoteStr($value,'fe_users');
switch ($key) {
case 'nom':
if(strlen($value) > 2)$cond_array[]="fe_users.name LIKE '$value%'";
break;
...
default:
break;
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Se prémunir de l’injection SQL dans TYPO3 : 4.5 LTS
$statement = $GLOBALS['TYPO3_DB']->prepare_SELECTquery('*', 'pages', 'pid = :pid');
for ($i = 1; $i < 10; $i++) {
$statement->execute(array(':pid' => $i));
while (($row = $statement->fetch()) !== FALSE) {
// Do something with your $row
}
$statement->free();
}
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
L’injection de script (XSS)
Le Cross Site Scripting
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
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
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>
On obtient une page dans laquelle, selon le traitement, on a éventuellement un script inclus et
interprété là où l’on croyait avoir un simple mot
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Le Cross Site Scripting : 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 chaine 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
intérprétés en HTML : htmlspecialchars
Les cas complexes : autorisations de certaines balises par une analyse spécifique
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Le Cross Site Scripting : le RTE
Si vous devez autoriser des saisies contenu du HTML, passez par le RTE de TYPO3
Le RTE se positionne sur le Front-End comme sur le Back-End
La liste des balises autorisées est paramétrable en TYPOSCRIPT
L’affichage des contenus associés est validée soit par un rendu TYPOSCRIPT parseFunc_RTE
soit par une méthode de l’API
tslib_pibase->pi_RTEcssText($variable)
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Bonne pratique général : 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;
}
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Le Cross Site Request Forgery (CSRF)
Le Cross Site Request Forgery
La plupart des outils utilisent, avec raison, des URL explicite:
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
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Le Cross Site Request Forgery
L’agression est difficile à détecter : c’est une personne ayant les droits qui fait les actions
La faiblesse est accru par les contexte 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)
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011
Le Cross Site Request Forgery : s’en prémunir
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 le cHash de TYPO3
http://www.monsite.fr/index.php?txmonextension[action]=supprimer&txmonextension[id]=35
&txmonextension[date]=timestamp&cHash=jgs37829DE
T3UNI 2011
TYPO3 et la Sécurité de l’information
29.06.2011