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

/!\ 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

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

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

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

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

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

# 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

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

#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

===========================

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

===========================

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

# 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

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

# 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

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

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

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

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