TYPO3 et la Sécurité de l’information

1. TYPO3 et la Sécurité de l’information 29.06.2011 Julien BOURDIN <julien.bourdin@kleegroup.com>

2. Julien Bourdin Architecte PHP / Développeur TYPO3 KLEE GROUP Profil : Architecte, chef de projet Certifié TYPO3 Integrator

3. Introduction

4. 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

5. 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 RequestForgery (CSRF)

6. Le concept de sécurité

7. La sécurité est une gestion des risques.

8. Les différents risques Intégrité des données Confidentialité des données Disponibilité des services Responsabilité des personnes

9. Les différents risques Intégrité des données Confidentialité des données Disponibilité des services Responsabilité des personnes => Transactions, Détection des incohérences, Sauvegarde => Authentification, Droits d’accès, Détection d’intrusion => Redondance, Récupération après incident, DOS, Supervision => Usage indu, Traçabilité, Maintenance

10. 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

11. 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 !

12. 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 »

13. 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.

14. Les failles humaines et les piratages sociaux

15. 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 !

16. 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

17. 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

18. Les failles évidentes

19. Essayez donc /typo3/install avec joh316 !

20. 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)

21. Limiter la portée des intrusions

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

23. 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'installtool + droit sur le repertoire typo3conf/ext)

24. 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 !

25. Les déni de services

27. 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)

28. 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

29. 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 !

30. 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

31. 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 extendstslib_pibase

32. Le spam côté serveur

33. Votre serveur peut devenir une source de spam !

34. 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

35. L’injection SQL

37. 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.

38. Exemple : la connexion par login et mot de passe SELECT * FROM USERS WHERE LOGIN = '$_GET['login']' AND PASSWORD = '$_GET['password']'; Il luisuffitdonc de saisirMonlogin';# pour que la requêtedevienne : SELECT * FROM USERS WHERE LOGIN = 'Monlogin';#' AND PASSWORD = ''; La bonne méthodeconsiste à considérer la saisiecomme des caractères non susceptibles de déclencher des commandes MySQL (voirmysql_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 !

39. 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 (preparedstatement) qui n’attendent que de la données pour leurs paramètres (disponibles depuis TYPO3 4.5 LTS)

40. 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!

41. 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;

42. 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 somethingwithyour $row } $statement->free(); }

44. L’injection de script (XSS)

45. 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

46. 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

47. 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

48. 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)

49. 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 functionmafonction($a,$b,…){ assertion(type1,$a); assertion(type2,$b); $retour = corpsdemethode(); assertion(typesortie,$retour); return $retour; }

50. Le Cross Site RequestForgery (CSRF)