Archive pour août 2010

TYPO3 et la sécurité Volet1: Rappel sur les différents types de failles

Déjà la fin de l’été et une université d’été TYPO3 déjà loin, mais bon il faut profiter de la rentrée pour faire des petits rappels. Nous allons donc aborder un des sujets traités durant cette université, sur les bonnes pratiques en terme de développements et d’intégration de TYPO3 dans le respect des règles de sécurité de base.

Tout d’abord, il est bon de faire un rapide rappel sur les différentes failles de sécurité auquel nous sommes confrontés, la première règle d’or c’est : « Maitriser les techniques d’attaques permet de mieux appréhender les contraintes de développement.

Cross-site Scripting ou XSS :

Insérer des données arbitraires via POST et GET:

  • Faille du DOM (coté clients – le javascript)
  • Faille basé sur le non traitement des URL, données directement exploitées sans être encodées
  • Injection de code

Ces trois types de faille peuvent être évités en utilisant de bonne pratique de développement :

  • retraitement des URL
  • contrôle des paramètres POST et GET avec une réécriture des caractères spéciaux
  • suppression des balises à risque en PRE traitement

SQL Injection :

Technique de hacking qui consiste à injecter dans les paramètres POST et GET via une faille XSS des éléments SQL en vue d’obtenir des informations contenues dans la base de données.

Le fishing (ou hameçonnage ou filoutage) :

Technique qui permet de récupérer des informations personelles pour usurper l’identité.
La technique consiste à faire croire à un internaute qu’il s’adresse à un site, une adresse de confiance afin que celui-ci fournisse des renseignements tels que :

  • identifiant/mot de passe
  • numéro de compte
  • numéro de carte de crédit
  • etc.

Généralement ces attaques se font soit à partir de mail soit par des sites web (avec de pages cachées).

Le déni de service :

Cette attaque à pour but de rendre indisponible le service et d’empêcher les utilisateurs légitimes d’un service de l’utiliser.
Celle-ci peut se baser sur :

  • L’  « exploitation de limite machine », c’est à dire l’envoi massif de paquet de type ICMP dépassant la taille classique. Lorsque la taille d’un paquet est plus élevée, les piles IP traitent ces paquets de manière plus lente et font donc augmenter l’utilisation CPU
  • Le « flooding ou UDP Flooding » c’est à dire l’injection de requête massive sur un réseau afin de saturer voir d’empêcher son fonctionnement.
  • Le « SYN Flood » c’est à dire l’injection importante de demande de synchronisation TCP incomplète avec un serveur. Cela a pour objectif d’augmenter le délai d’attente de réponse avec pour issue le crash.
  • Le « Packet Fragment » c’est à dire l’utilisation des faiblesses dans l’implémentation de certaines piles TCP/IP au niveau de la fragmentation IP. Cela a pour objectif le crash des systèmes et/ou des appareils réseau intelligents
  • Le « Smurfing » c’est à dire l’envoi un paquet ICMP à une adresse de brodcast. Cela a pour objectif de créer une énorme quantité de trafic entre les équipements

En synthèse on peut dire que le déni de service à trois objectifs majeurs :

  • Le blocage d’accès à un service pour une à plusieurs personnes.
  • La saturation d’un réseau afin d’empêcher son fonctionnement
  • La perturbation des connexions entre deux machines et/ou équipement, empêchant l’accès à un service en particulier ou une branche de réseau.
  • Le blocage d’accès à un service pour une à plusieurs personnes.

Comment intégrer le SSO CAS dans Liferay 5.2

Nous allons aborder un sujet qui est très utilisé dans les solutions Liferay.

L’intégration de Liferay avec le serveur d’annuaire LDAP et le serveur d’authentification centralisée, CAS.

Cette intégration prendra en compte la version communautaire Liferay 5.2.3. Depuis la version 5.2 de Liferay, toutes les configurations se trouvent dans le fichier « portal-ext.properties » et peuvent aussi se faire via l’interface graphique. Les données présentes dans le fichier « properties » seront utilisées que lors du premier lancement de Liferay. Les données sont ensuite sauvegardées en base, et lors des modifications dans l’interface, ce sont les données de la base qui sont modifiées. Si on redémarre le serveur, ce sont les données de la base qui sont utilisées.

Intégration LDAP

Nous allons d’abord commencer par l’intégration du serveur d’annuaire en expliquant la configuration via le fichier « properties » puis via l’interface graphique.

Liferay peut s’intégrer avec différents types de serveurs d’annuaire. Ici nous allons utiliser l’annuaire LDAP.

Le fichier « portal-ext.properties » permet de configurer de manière très détaillée le LDAP pour Liferay. Nous allons détailler ici que les principaux éléments à configurer.

ldap.base.provider.url=ldap://urlldap:389 URL de l’annuaire LDAP

ldap.base.dn=dc=xxxxx,dc=xx      Le base DN de l’annuaire LDAP

ldap.security.principal=cn=admin,dc=xxxxx,dc=xx login du compte admin pour le LDAP

ldap.security.credentials=motdepasse mot de passe du compte admin

ldap.auth.enabled=true Permet d’activer l’authentific                  ation LDAP si ce paramètre est à false l’authentification se fera via la base de données de liferay.

ldap.auth.required=true Ce paramètre permet de render l’authhentification LDAP obligatoire. Si l’utilisateur ne se trouve pas dans le LDAP, l’authentification échouera.

ldap.import.enabled=true Permet d’activer l’importation des utilisateurs du LDAP.

ldap.import.on.startup=true Permet d’effectuer un import lors du demurrage du serveur.

ldap.import.interval=10 Permet de déterminer la fréquence des importations

ldap.import.user.search.filter=(objectClass=inetOrgPerson) Permet de définir le filter de recherche des utilisateurs (Requête de recherche LDAP)

ldap.import.group.search.filter=(objectClass=groupOfUniqueNames) Permet de définir le filter de recherche des utilisateurs (Requête de recherche LDAP)

ldap.user.mappings=screenName=uid\nlogin2=extuid\npassword=userPassword\nemailAddress=mail\nfirstName=givenName\nlastName=cn\norganisme=o\ncentre=centre\nville=l\ngroup=groupMembership Permet de définir le mapping des utilisateurs, le mapping est fait entre les champs du LDAP et ceux de la base de données correspondant à l’utilisateur.

ldap.import.method=user|group Permet de définir la méthode d’importation des données à partir de l’annuaire. On peut prioriser l’importation des utilisateurs ou des groupes. Ceci implique des modifications de l’architecture LDAP : Si on priorise les utilisateurs, l’information de groupe devrait se trouver au niveau des utilisateurs dans un champ de type memberOf, et si on priorise les groupes, l’information d’appartenance se trouve donc au niveau du groupe dans un champ de type uniqueMember ou member.

ldap.export.enabled=false Permet d’activer l’exportation des données de Liferay vers le LDAP.

Toutes ces configurations se retrouvent au niveau du « control panel » de Liferay sous le menu « Configuration » (à gauche) puis « Authentification » (à droite) et sous l’onglet LDAP.

Une fois la configuration effectuée, on peut s’authentifier dans Liferay avec les utilisateurs issus de l’annuaire LDAP.

Intégration CAS

Comme pour le LDAP, nous allons aborder la configuration du CAS via le fichier « portal-ext.properties » et ensuite avec l’interface graphique.

Depuis la version 5.2 de Liferay, les jar permettant d’utiliser le service CAS sont intégrés, ainsi que les déclarations des filtres dans le fichier web.xml de Liferay. Ce qui évite de la faire et permet de gagner du temps.

L’utilisation du CAS va donc se résumer à la configuration du serveur au niveau de Liferay.

Les éléments du fichiers properties permettant cette configuration sont détaillés ci-dessous :

cas.auth.enabled=true Permet d’activer l’authentification via le CAS

cas.import.from.ldap=true Permet d’indiquer si le CAS doit se baser sur le LDAP pour l’authentification.

cas.login.url=https://url.cas/login Indique l’URL de login du CAS

cas.logout.url=https://url.cas/logout Indique l’URL de logout du CAS

cas.server.name=localhost:8080 Indique le nom du serveur sur lequel se trouve le CAS.

cas.service.url= Indique l’URL de service d’authentification du CAS

cas.validate.url=https://url.cas/serviceValidate Indique l’URL du service qui valide l’authentification du CAS.

Toutes ces configurations se retrouvent au niveau du « control panel » de Liferay sous le menu « Configuration » (à gauche) puis « Authentification » (à droite) et sous l’onglet CAS.

Comme on peut l’imaginer, il est possible d’utiliser ces deux technologies de manière indépendante, en ne les activant pas simultanément.

Alex V.