1. Sasha Pons, Security Architect, CASINO Group
sapons [at] groupe-casino [.] fr
Merci à Damien Cazenave pour sa présence lors de cette présentation, pour ces
illustrations qu’il a su transmettre très pédagogiquement.
Merci à mon stagiaire, Mathias Roussillon, pour tous les éléments qu’il a pu
m’apporter.
1

2. /! La sécurité applicative est un processus, pas une technologie /!
Description du cycle de développement d’une application :
# design : pour cDiscount, revue des chartes projets tous les 15 jours auxquelles
le responsable de la sécurité applicative participe. La charte projet contient un
slide sécurité obligatoire, rempli par les chefs de projet fonctionnels, listant 20
questions simples (baseline) auxquelles ils doivent répondre par oui/non. Pour les
réponses ne correspondant pas aux standards, une censure est posée et un comité
spécifique est organisé.
# develop : revue de code croisée, avec un focus plus particulièrement appuyé
sur le TOP10 OWASP. Action réalisée prioritairement sur les processus critiques
de l’application. REX : permet aussi d’optimiser le code.
# test : scan automatique quotidien des environnements de recette et pré-
production.
# deploy :
# maintain : awarness annuel des acteurs de ce processus cyclique.
Le responsable de la sécurité applicative tire chaque domaine de l’activité d’une
direction de la sécurité des systèmes d’information approche plus pragmatique
qu’une approche par silo (sécurité applicative, sécurité opérationnelle,
compliance) s’interfaçant difficilement autour des nombreux projets pilotage
3

3. par le risque.
Son objectif est de construire une application « hack resilient », en jouant sur 2 leviers :
# diminuer la surface d’attaque
# diminuer l’impact en cas d’attaque
Fiche de mission d’un responsable de la sécurité applicative qui accompagne ce cycle :
# design :
§ rédige une politique de sécurité complète, notamment avec des procédures
opérationnelles
§ s’interface entre les différentes contraintes légales / le métier / l’IT,
§ modélise le risque.
# develop :
§ sensibilise les développeurs à la sécurité applicative
§ fournit des règles de codage, orientées menaces et pas forcément pour la beauté du
geste !
§ relit manuellement le code présentant un niveau de risque élevé
# test :
§ fournit les outils au testing pour la détection des failles de sécurité (progressez en
partant des vulnérabilités à portée de main, puis en passant par l’OWASP/10 et en
finissant par CWE/25)
§ forme les testeurs à la recherche des failles
§ rejette les demandes de mise en production en cas de déficience
# deploy / maintain :
§ audit régulièrement les applications de production pour vérifier qu’il n’y a pas eu de
dégradation. Permet de tester que les acteurs savent utiliser les procédures en cas
d’intrusion ou de fuite de donnée
§ alerte en cas de découverte d’une faille 0 day par exemple
§ investigue dans un cas de compromission
§ reporte des indicateurs fiables et pédagogiques. “A basic tenet of software
engineering is that you can't control what you can't measure” T. De Marco
_____________________
2011 Top Cyber Security Risks Report de HP DVLabs :
Ainsi, 36 % de toutes les vulnérabilités toucheraient des applications web à but
commercial.
Ensuite parce que si le nombre des vulnérabilités diminue, leur exploitation augmente via
« l’émergence d’un marché privé d’échange des vulnérabilités ». Le rapport cite les kits
d’exploits vendus en ligne qui rencontrent un réel succès et afficheraient un taux de
3

4. réussite élevé. Les taux d’infection sur certaines vulnérabilités s’affichent
exceptionnellement élevés, reflet des faiblesses des systèmes en place et finalement de la
relative facilité que rencontrent les hackers pour dérober des données sensibles.
Enfin, professionnalisation des criminels et émergence d’hacktiviste désintéressés.
3

5. Différents types de site :
# Corporate : publie principalement des données statiques. L’objectif de
sécurité est principalement de lutter contre le défacement, la disponibilité n’est
pas primordiale.
# Réseau Social et site communautaire :
§ cVous : site communautaire destiné aux consommateurs dans le but d’avoir
un impact sur les produits et les services du quotidien dans leurs magasins. 1)
créer du lien entre les consommateurs et 2) co-crééer des produits qui seront
intégrer au panel des enseignes partenaires (Géant Casino, Casino Supermarchés,
Casino Proximité, Franprix, Leader Price).
§ la fourmiliére : forum d’échange dédié à la relation client, permet de
proposer des services proches des canaux de vente traditionnelle: conseils, SAV,
astuces. Une utilisation induite est la surveillance du phising et la communication
en réaction à une situation dangereuse.
l’enjeu de sécurité est principalement la modération du
contenu posté et la disponibilité de la plateforme
# B2C, B2B :
§ cDiscount : pure player dans les sites d’eCommerce
un des enjeu principal est la lutte contre les tentatives de
4

6. phishing et malware avec un plan de réponse à incident
§ Banque Casino : site de eBanking
§ Gold Franchise : interface de commande à destination des magasins franchisés.
Fréquemment, franchisé signifie que le SI du magasin n’est pas managé par l’IT de la
maison mère, il s’agit souvent d’un PC personnel connecté à une box. Souvent un point
faible des SI d’entreprise, car ces réseaux de franchisés sont faciles à compromettre et
permettent un accès au plus ou moins complet au SI de la maison mère.
§ TMS (Transport Management System) : site de gestion permettant le suivi
opérationnel et administratif du transport de la supply chain (interface entre les
fournisseurs et le distributeur).
Pour tous ces sites, les enjeux sont les suivants :
confidentialité des données personnelles, des données bancaires, patrimoine
informationnel de l’entreprise
haute-disponibilité
intégrité des données manipulées pour garantir le moins d’impact opérationnel
possible
Compliance ?
# PCI : est la norme la plus directive et la plus verticale. C’est une norme qui nécessite le
passage d’une certification à renouveler régulièrement.
§ exemple d’un travail effectué par cDiscount de valorisation des contraintes apportées
par la norme PCI pour la mise en œuvre d’un service SaaS de paiement.
# I&L : impose la protection des données personnelles mais sans préciser les modalités
minimales à mettre en œuvre avant d’être coupable de manquement. Due Diligence ?
4

7. Coquetterie : parler de défense en hauteur (plutôt qu’en profondeur) car, en
sécurité applicative, on remonte les couches du modèle OSI
===========================
Firewall & IPS
===========================
# Le FW permet de tracer et éventuellement détecter des comportements
précurseurs d’attaques. 2 mots clés : ACCEPT et DENY
# L’IDS permet de détecter des activités anormales ou suspectes en s’appuyant
entre autre sur un système de signature. L’éditeur publie régulièrement des
signatures avec un conseil d’action : ALLOW et BLOCK.
===========================
Reverse Proxy
===========================
# ré-écriture programmable des URLs pour masquer et contrôler l'architecture
d'un site web interne
# Encryption SSL : terminaison SSL par le biais de matériel dédié
# Load Balancer
# compression : optimiser la compression du contenu des sites
5

8. # cache : décharger les serveurs Web de la charge de pages/objets statiques (pages
HTML, images) par la gestion d'un cache local.
===========================
Cache
===========================
Utilisation d’un CDN (Content Delivery Network) :
# ensemble de nœud en « bordure » d’Internet permettant de mettre à disposition du
contenu au plus rapide et au plus proche de l’utilisateur
# basé sur une requête DNS qui redirige l’utilisateur vers son nœud de contenu le plus
proche
# Akamai ou Limlight sont les grands noms, mais des fédérations de CDN TelCo sont en
train de voir le jour, permettant de concurrencer les acteurs historiques dont les coûts sont
importants.
# possibilité de loadbalancer le contenu entre plusieurs CDN pour l’optimisation de la
facture en fin de mois ;-)
===========================
WAF
===========================
# Un web application firewall peut se décliner sous la forme d’une appliance, d’un plugin
pour un web server ou tout simplement d’un ensemble de filtre appliqués directement sur
un webserver.
# Cet ensemble de règle couvre les attaques communes comme par exemple les XSS et
les injections SQL. La personnalisation pour couvrir des attaques plus sophistiquées ou
intégrant la dimension business du site demande un travail important et doit être
entièrement intégrer au cycle de développement de l’application à protéger.
5

9. Modèle de sécurité + : consiste à n’accepter que ce qui est spécifiquement
autorisé. C’est la notion de liste blanche.
# modèle présentant le niveau de sécurité le plus fort.
# c’est aussi le moins facilement gérable, notamment pour des sites construit
autour de CMS pour lesquels des webmasters produisent du contenu plus ou
moins riche.
Modèle de sécurité - : consiste à bloquer ce qui explicitement spécifié.
# modèle le plus automatisable
# adhérence faible avec le contexte protégé
Modèle – (liste noire)
Modèle + (liste blanche)
FW #Deny @ anonymous / TOR #Allow 80 / 443
IPS #Deny signature
#Allow exceptions after false-positive detection
WAF #Deny URL pour CMS
#Allow identified values in sensitives fields
#Deny HTTP Method
6

10. #learn then blocked
#Bufferoverflow
#Deny IP from Korean/Ukraine
#SQL injection
Description du graphique : Evolution du niveau de sécurité en fonction du temps
# le cloud permet d’augmenter le niveau de sécurité plus rapidement que la configuration
de matériel hébergé sur site.
# le passage d’un modèle de sécurité négatif à positif se fait aux environs de 80%. Il
arrive donc plus tôt lorsque le service est dans le cloud.
# l’écart résiduel persistant couvre les failles zéro-days ainsi que les failles
technologiques et business non-maitrisées
# plus la courbe de correction est verticale moins cela coûte cher, plus elle est horizontale
plus le coût est important
6

11. ===========================
Réseau
===========================
Tous ces composants sont eux aussi concernés par le patch management !
Routeur / Firewall / IPS / Reverse Proxy / Load Balancing
# auditez régulièrement les routes/règles en place. Des outils d’optimisation
existent permettant de rationaliser lorsque l’on a atteint un degré de complexité
trop important.
# limitez le NAT, il n’est pas nécessaire d’avoir 3 NAT en DMZ avant d’atteindre
le serveur web, surtout cela permet de limiter le nombre de sessions TCP
# exemple : mauvaise configuration du FW où le nombre de session TCP
n’étaient pas limité. La configuration d’un FW internet n’est pas la même chose
que celle d’un FW cœur de réseau.
# faites des tests de charge poussés si vous souhaitez faire faire de l’analyse
applicative par votre FW. L’overload est important et ce n’est pas forcément le
meilleur équipement pour le faire.
# les technologies de type Virtual Routing and Forwarding (VRF) aide à la
segmentation d’une plateforme mutualisée.
# un mythe : la publication via un reverse proxy n’est pas une obligation pour
faire de la terminaison SSL. Possible de le faire avec des WAF de niveau L2.
7

12. ===========================
Hôte
===========================
Patch Management
# alerting : inscription à un CERT, permettant de déclencher les opérations.
# operating : négociation d’un créneau quotidien de redémarrage de la plateforme. La
haute disponibilité est un voeux pieux mais pas toujours réalisable (ex SharePoint).
Attention donc à la mutualisation à outrance. Le patch virtuel n’est encore qu’une notion
marketing.
# tracking : s’assurer du déploiement exhaustif et de l’inclusion dans les nouvelles
versions de master par exemple.
Services
# construction de l’hôte en sécurité positive gain d’exploitation important
# similairement, ajoutez uniquement les modules nécessaires à votre serveur web. Les
fichiers de configuration httpd.conf ou web.config ne doivent pas être ésotériques pour
vos administrateurs, ils doivent être en mesure de vous les expliquer.
Protocoles/Ports
# n’utilisez plus les protocoles que vous utilisez peut-être encore à la maison : POP3,
SMTP, FTP et surtout Telnet ne sont pas des protocoles d’entreprise. Des alternatives
sécurisées existent pour chacun.
# faites des scan de port réguliers et automatiques (Nessus) pour vous assurer que vos
machines ne sont pas compromises.
Accounts
# privilégiez la centralisation d’administration des comptes
# optez pour un typage fort. Pour rappel, 3 types de compte peuvent être utilisés : compte
d’utilisateur, compte de service, compte d’application, les deux derniers devant être
strictement habilités suivant le principe du juste droit
# auditez et positionnez des alertes sur les comptes sensibles
# prévoyez plus que moins de compte d’application ou de service
# prévoyez aussi une politique de pwd fort et de lockout des comptes. Conficker a eu un
point positif : celui de repérer les programmes s’exécutant avec des comptes built-in de
Microsoft.
# utilisez des coffres fort de mot de passe (KeePass est bien souvent suffisant)
Partage
7

13. # supprimez aussi les partages administratifs. Hébergez les logs dans des locations non-
accessibles par le webserver.
# les logs web exposent beaucoup d’information. Accessible depuis Internet, l’intrusion
est proche !
Registre
# Interdisez l’accès au registre à distance. Exemple d’un antivirus avec un pwd de
protection facilement contournable par un accès au registre (pourtant en v10!)
Auditing and Logging
# ils contiennent toute la matière utile à la compréhension de l’application et de l’hôte.
Entrainez les équipes à rechercher des informations à l’intérieur. Mieux vaut savoir les
exploiter que les stocker !
===========================
Application
===========================
Validation des paramètres d’entrée :
# les mots magiques sont par ordre d’importance :
§ SQL injection
§ Cross-site scripting
§ Canonicalization : /etc/shadow passé en argument GET peut ne pas être vérifié
utilisez des chemins relatifs, vérifiez les paramètres requestEncoding et
responseEncoding du fichier Web.config pour valider qu’ils sont en relation avec la
langue du site.
§ Buffer overflows
Authentification :
# utilisez le verrouillage de compte pour éviter les attaques par dictionnaire, informez les
utilisateurs lors d’un changement de mot de passe ou en cas de désactivation du compte
suite à une période d’inactivité trop importante, prévoyez un processus de recovery en cas
de perte/vol.
# évidemment le triptyque de Sainte Authentification :
§ hash du pwd
§ chiffrement du canal de communication
§ stockage du hash dans la base de d’authentification
# vol de session : exemple d’un cookie de session admin (n’expirant jamais) qui était
passé en paramètre GET. L’admin avait rendu les logs du site web visible depuis Internet,
il était très facile de pouvoir utiliser le cookie Admin pour s’authentifier sur la DB et
7

14. l’aspirer entièrement.
Autorisation :
# la principale menace est l’élévation de privilège. L’objectif de toutes les contres-
mesures à apporter à cette faille est de rendre impossible l’accès à l’hôte en administrateur
local ou root.
# la connexion au serveur de base de donnée en SA illustre plusieurs problèmes :
§ une méconnaissance de la part des développeurs des principes de sécurité, peut-être
liés en partie à l’absence de Coding Rules ?
§ une faille dans le contrôle opéré par les gestionnaires applicatifs en charge du
déploiement de l’application en production
§ une faille aussi dans le code/config review opéré par les équipes de sécurité
Gestion de la configuration :
# accès aux interfaces d’administration, de supervision, de gestion de contenu. Exemple
d’un SharePoint hébergé, proposant du webmastering aux propriétaires des données, de
l’administration des collections de site pour la création/modification/suppression des sites
publiés, de l’administration des serveurs applicatifs par des « Application Manager »
(rafraichissement des caches de données par exemple), de l’administration des serveurs
web (IIS ou tout autre middleware), de l’administration de base de donnée,…
Authentification forte pour les sections le nécessitant (ex de l’administration des taux
d’intérêt sur un site d’eBanking)
contrôle d’accès nominatif basé sur un modèle RBAC (attention aux demandes de
type comptes d’astreintes en password never expires).
logging et audit plus particulièrement des procédures, des fichiers de configuration
afin de vérifier que les informations type loging/pwd restent bien confidentielles, qu’ils
sont bien stockés en dehors de l’arborescence de fichier accessible à partir du webserver.
documentation et archivage des configurations.
Données confidentielles :
# données d’authentification, personnelle, ... Attention à la portée d’une donnée : un
numéro de carte de fidélité peut s’avérer tentant comme identifiant unique mais peut aussi
être utiliser comme moyen de paiement avec une autre donnée personnelle stockée dans la
DB et accessible aux administrateurs.
Cryptographie :
# La robustesse d’un mécanisme de cryptographie (symétrique ou asymétrique) repose
principalement sur la sécurité mise en œuvre autour du secret (soit la clé privée, soit le
secret partagé). Une clé de longueur trop faible, avec une durée de vie trop longue,
stockée dans le file system sans ACLs, ou dans le fichier de configuration du serveur web
sont les faiblesses fréquemment rencontrées lors des audits de plateforme web.
7

15. # la compréhension de l’implémentation est primordial. Exemple d’un calcul de MD5 via
un JavaScript local puis envoyé au serveur => aussi efficace que l’envoi du pwd en clair!
Gestion des sessions :
# ne respecte pas le modèle OSI, car fait au niveau 7
# l’attaque la plus fréquemment utilisée est le vol de cookie, soit localement sur le poste
(malware), soit en écoutant la conversation si elle est en clair. Utiliser du HTTPs pour
éviter les écoutes, les fonctions logout et des durées d’expiration de cookies réalistes. Pour
les fonctions critiques (type tunnel de paiement), re-demander systématiquement
l’authentification de l’utilisateur et re-calculer un HMAC par exemple.
Manipulation des paramètres :
# URL : tous les paramètres passés dans l’URL, facilement accessibles via un browser.
Exemple du calcul incrémentiel d’un code de retrait permettant de modifier une
commande.
# champs des formulaires : entrées postées via un formulaire. Souvent les développeurs
répondent : pas d’inquiétude, des contrôles sont fait localement sur le client avant l’envoi
au serveur. L’intention est bonne mais inutile car ces contrôles sont facilement
contournables en n’exécutant pas le JS localement.
# cookies : modification des valeurs contenues qui sont parfois trop explicites.
Chiffrement ou signature du cookie pour valider l’intégrité des informations transmises.
/? qui possède un inventaire des cookies délivrés par son application ? Cet inventaire
est-il en conformité avec la loi sur le paquet telecom passé en application en Août 2011 /?
# http headers : exemple de l’http referer utilisé de manière important dans les
mécanismes de fédération d’identité pour retourné au site web après un
paiement/authentification. Un mécanisme de protection est la vérification de la
provenance par un canal directement entre les 2 serveurs par exemple.
Gestion des exceptions :
#nécessite souvent un travail avec le métier pour imaginer un comportement le plus
acceptable par l’utilisateur.
#l’erreur redirige-t-elle vers une 404, une 404 chartée, renvoie un reset TCP ?
7

16. Classiquement, le traitement d’un risque d’attaque est réalisé par un ensemble de
composant de sécurité (réseaux & applicatifs), représentés ici par un simple
firewall. L’objectif étant bien entendu la protection du SI ainsi protégé.
L’évolution des menaces suit 2 axes distinct :
# attaques distribuées, le DDoS est un bon exemple. Elles sont perpétrées par des
réseaux de botnets, contrôlés ou loués par des cyberhacktivistes ou des groupes
de type anonymous.
# attaques ciblées, précises, complexe dont l’objectif peut-être le vol
d’information, du cyber chantage, du défacement, de l’injection de donnée
erronées.
L’évolution des architectures opère elle aussi un glissement dans le Cloud et
couvre tous les composants applicatifs :
Le traitement des attaques distribuées peut se faire dans le cloud. On parle aussi
de dWAF pour Distributed WAF. Quels sont les avantages ?
# PME/PMI :
§ service hébergé, éventuellement opéré. Modèle de sécurité négatif.
# dimension géographique dans les requêtes :
§ un centre de contrôle peut détecter des requêtes en provenance d’une certaine
partie du globe, les identifier comme malsaines, et prendre comme décision de
8

17. les bloquer sans impacter le flux français par exemple.
§ La commande d’un panier sur CASINO Express est-elle valide lorsqu’elle est réalisée
depuis l’inde ?
# Réputation des requêtes : basée sur la réputation des IPs, en provenance de proxy
anonyme ? d’IP du réseau TOR ou identifiées comme infectantes ?
------
# Shift d’une présentation du contenu via un site web vers des architecture d’application
mobile consommant des webservices.
cycle de développement intégrant des équipes extérieures, sur des technologies peu
matures, agrégeant des technologies composites. Les plateformes n’intègrent pas encore
tous les mécanismes de sécurité que l’on rencontre sur un poste de travail classique.
------
Les attaques spécialisées et les vulnérabilités vont se vérifier tout au long de la chaine.
C’est une corrélation d’événements applicatifs (SIEM ?) qui permettra l’identification
d’une menace précise.
# DataBase Firewall (DBF) : à l’identique du WAF mais dédié aux protocoles SQL et
autres. Les éditeurs ont tirés les enseignements du WAF en proposant 1) un module
d’apprentissage automatique identifiant et classifiant les données sensibles sur le LAN
(convergence avec DLP?), 2) d’enregistrer les accès à ces données et 3) d’en déduire des
règles de contrôle d’accès.
# File FireWall (FFW) : approche identique à DBF avec découverte, apprentissage et
construction de règles de contrôle d’accès.
Dans ces 2 cas, pouvoir bénéficier de log précis sur la provenance et la destination, la
nature applicative de l’attaque (quel utilisateur applicatif de connexion à la DB est utilisé
pour passer l’injection SQL ? ) permet du forensic en impactant le moins possible le
fonctionnement de l’application.
Service d’hygiène du flux web : service de protection contre la fraude et le vol d’identité
basé sur des technologies d’éditeurs anti-fraude (ex Trusteer).
# est-ce un robot ou un humain ? Injection d’un cookie aléatoire ou d’un JS qui n’est pas
ou mal interprété par le client. Analyse statistique de la navigation pour la comparer aux
précédentes navigations.
# Permet de s’assurer de l’état de santé du browser, sans agent. Ce afin de lutter contre les
attaques de type Man in The Browser. Peut aussi mettre à disposition un browser sécurisé,
assurant que les informations d’identité (cookie ou autre) n’ont pas été subtilisées.
# Fraude, sécurisation espace client et scoring commande pour détecter les commandes
frauduleuses
8

18. Exemple du protocole SPDY
Impulsé par Google, ce protocole à pour objectif de transporter du contenu web
plus rapidement et ce afin d’améliorer le protocole HTTP.
# SPDY s’appuiera obligatoirement sur une couche 5/6 TLS/SSL. Nativement, le
protocole embarquera la protection de la couche applicative dans un tunnel SSL,
allégeant la charge de développement.
# /? Multiplexage des sessions http dans une même session TCP
# Push d’information à l’initiative du serveur
# /? Factorisation des headers http (lequels par exemple…)
# compression systématique des requêtes envoyées
# priorisation des requêtes faite par le client (priorité au contenu, aux images,
aux publicités, …)
Pourquoi ne pas faire ces améliorations au niveau TCP, couche en charge de la
gestion des sessions ?
# parce que cela impliquerai une mise à jour massive des éléments réseaux
constitutifs de la stack TCP/IP. L’exemple de la lenteur d’adoption de IPv6 est
suffisamment parlant alors même que les équipements sont compatibles.
# stratégie quick wins, car la couche HTTP n’est pas parfaite et que c’est la plus
simple à mettre à jour. Pourquoi ? Parce que tous les internautes sont habitués à
9

19. monter la version de leurs browsers (le saint graal du patch management ;-) ) et parce que
la mise à jour d’un web server est plus simple que les changements d’équipements
réseaux, voir même le simple upgrade de firmware les rendant compatibles.
9