OZSSI NORD 4 JUIN LILLE. Conférence thématique: Sécurité des applications

Transcription

1 OZSSI NORD 4 JUIN LILLE Conférence thématique: Sécurité des applications Document confidentiel - Advens 2015

2 Présentation de la société Advens 2

3 La sécurité est source de valeur Pas de développement économique sans développement du numérique. Pas de développement du numérique sans sécurité! Document confidentiel - Advens 2015

4 Le défi? Tous les moyens existent pour protéger votre organisation, la clé réside dans votre capacité à les organiser. Document confidentiel - Advens 2015

5 Qui sommes-nous? 1er acteur français spécialiste du management de la sécurité de l information, Advens vous accompagne pour prendre de l'avance et faire de la sécurité un actif différentiateur M ans d existence collaborateurs à Paris, Lille et Lyon clients actifs en France et à l international d euros de chiffre d affaires Document confidentiel - Advens 2015

6 Pourquoi Advens? Nous réunissons toutes les compétences depuis la gouvernance jusqu à la gestion opérationnelle de la sécurité Nous savons intégrer les spécificités sectorielles de votre organisation et les enjeux métier de chacun de ses acteurs Nous savons innover et travailler avec agilité pour mieux répondre aux attentes du marché 4 La force d Advens, c est d orchestrer l ensemble pour créer de la valeur à partir de la sécurité Nous construisons une démarche durable et collaborative avec nos équipes, nos partenaires et nos clients Document confidentiel - Advens 2015

7 Notre Offre Conseil Audit Technologies mysoc Security Management Programs Distribution Finance Public & Collectivités Santé Industrie & Services Application Security Infrastructure Security Digital Innovation Communication & Training Document confidentiel - Advens 2015

8 Advens, acteur de référence dans la région Advens a intégré le Pôle Régional Numérique et chapeaute ses initiatives en matière de sécurité. Advens est l un des membres fondateurs du cluster régional. Alexandre Fayeulle est président du comité stratégique. Advens est partenaire historique de cette association, regroupant une quarantaine de RSSI de la région. 8

9 Document confidentiel - Advens 2015

10 10

11 Actualités 11

12 Actualités 12

13 Actualités 13

14 Les mêmes causes produisent les mêmes effets Les utilisateurs cherchent agilité et autonomie Se tournent vers le Cloud sans évaluer la sécurité Bypassent la DSI, le RSSI Cherchent à optimiser les coûts et des délais rapides Les développeurs insuffisamment formés Manquent de sensibilisation et de formation Utilisent des méthodologies dans lesquelles la sécurité n est pas intégrée Répondent à des cahiers des charges qui n intègrent pas d exigences Les éditeurs ne maîtrisent pas la sécurité dans leurs produits Pression du marché / Time to market Absence de clauses sécurité dans les achats et dans les appels d offres 14

15 Les attaques sur les applications Web OWASP Top : les 10 risques sur la sécurité des applications La partie immergée de l iceberg SANS Top vulnérabilités, parmi 1 millier. Le risque d Injection Encore le premier des problèmes Solution simple pour le contrer Chaque audit/test d intrusion en comporte une Le risque de Cross Site Scripting (XSS) Prise de contrôle du poste client Toujours mal considéré 15

16 Risques principaux sur les applications Web Injection Violation de Gestion d Authentification et de Session Cross-Site Scripting (XSS) Références directes non sécurisées à un objet Mauvaise configuration sécurité Exposition des données sensibles Manque de contrôle d accès au niveau fonctionnel Falsification des requêtes inter-sites (CSRF) Utilisation de composants avec des vulnérabilités connues Redirections et renvois non validés 16

17 Risques principaux sur les applications mobiles Stockage de données non sécurisé Contrôles serveur défaillants Transport de données non sécurisé Injection Client Mauvaise gestion des habilitations et de l authentification Mauvaise gestion de la session applicative Gestion de la sécurité via des données d entrée non sécurisées Fuite de données par canaux cachés Mauvaise utilisation du chiffrement Fuite d information sensibles 17

18 Zoom sur le Cross Site Scripting (XSS) Un risque toujours sous-estimé 18

19 Cross-Site Scripting: principe 19

20 Cross-Site Scripting: Sans danger pour l application? 20

21 Cross-Site Scripting: Sans danger pour l application? Vol de cookie Requêtes AJAX Cross-Domaine: Exfiltration de données Déni de service: Blocage du mobile Redirections, phishing Scan de ports sur le réseau interne Injection d objets flash via XSS: Activation du micro, de la webcam Captures d écran Sur un mobile vulnérable: Géolocalisation Appel téléphonique / Envoi de SMS Exécution de code (ex: Faille dans les WebView sous Androïd) 21

22 22

23 Architecture REST Une application est RESTful si elle respecte toutes les contraintes imposées par le style REST 23

24 Un web-service REST est une application Web Explosion des web-services REST Les applications mobiles en font un gros usage Les attaques Web «classiques» concernent également les architectures REST Attaques par Injection Compromission des sessions Cross Site Scripting Transport non sécurisé des données 24

25 Les attaques liées à JSON Explosion de JavaScript et d AJAX Applications Mobiles, API REST Objets connectés Explosion de la surface d attaque Javascript «à la demande» Le site Web fait des requêtes pour récupérer du code Javascript Le code récupéré est exécuté dynamiquement, «à la demande» Très utilisé dans les sites avec bandeaux publicitaires, contenus externes Exemple avec JSONP: <script src=" myfunc ("arguments", "générés", "dynamiquements"); Que se passe t il sur votre site si la régie publicitaire est attaquée? 25

26 Les attaques liées à JSON REST souvent utilisé avec des données au format JSON { "a": 3, "myvar" : "Bonjour" } JSON est également un objet JAVASCRIPT L interpréteur Javascript des navigateurs peut exécuter du «texte JSON» de façon dynamique Cela expose les clients à l exécution de scripts malicieux au sein des navigateurs Cela devient très dangereux dans le cas d applications qui récupèrent des données JSON en provenance de sources Internet externes: En cas de compromission de la source, du code malveillant peut s exécuter sur le poste client Exemple de mauvaise pratique: Utilisation de la fonction eval() sur un bloc JSON Préférez l utilisation de JSON.parse() / JSON.stringify() Impact sur la confidentialité 26

27 Attaques utilisant JSONP JSONP utilise les balises <script> pour exécuter du code Javascript en provenance de serveurs distants En cas de compromission de l un de ces serveurs, du code malveillant peut s exécuter au sein du navigateur En cas de compromission de la page d origine, l attaquant peut insérer des balises <script> et appeler le code de son choix La Same-Origin-Policy ne protègera pas contre cette exécution de code L entête HTTP Content-Security-Policy doit être positionnée afin d informer le navigateur de la liste des sites considérés comme étant de confiance. Impact sur la confidentialité 27

28 Attaques utilisant JSONP Cross-Site Request Forgery En cas d injection de balise <script>, le code récupéré s exécute dans le contexte de la page d origine Le code malveillant peut ainsi effectuer des requêtes à destination de sites légitimes sur lesquels l utilisateur était connecté. Cela peut conduire à des vols d information L utilisation d un token aléatoire dans chaque requête permet d éviter ces attaques Impact sur la confidentialité 28

29 Applications mobiles & Objets connectés Le meilleur reste à venir 29

30 Une multitude de possibilités pour le pirate La surface d attaque a explosée ces dernières années Le meilleur reste à venir 30

31 Objets connectés : Des passoires en sécurité Les informations collectées Dernières courses en foret Déplacement à l étranger Consommation de nicotine ou d alcool Pression artérielle Activité sexuelle Etc Failles flagrantes Localisation des objets grâce à leur puce Bluetooth Emission en permanence d une adresse physique MAC 20% des identifiants transmis en clairs pour les applications stockant des données dans le cloud Pour les 80% restants, utilisation de fonction de hachage faible comme MD5 dans de nombreux cas Gestion des sessions très aléatoires permettant d accéder aux comptes utilisateurs Informations très limitées quant à la façon dont sont stockées et protégées les données collectées 31

32 Objets connectés : Des passoires en sécurité 32

33 LIMITER LES RISQUES Bonnes pratiques et recommandations Document confidentiel - Advens 2015

34 Alors, quelles solutions? Méthode Outils Matière grise (expertise humaine) 34

35 Des solutions techniques 35

36 Sécurisation des applications mobiles Les applications mobiles sont de gros consommateurs de web-services REST Des solutions technologiques peuvent offrir des protections complémentaires à la sécurisation des applications clientes Risques à couvrir: Exposition des APIs, fuite d information technique, accès aux information d authentification locales (ex: API Keys) Des solutions techniques existes pour protéger les applications déployées sur les terminaux Contrôle de l intégrité du code Obfuscation Chiffrement Anti-debug Détection du jailbreak Protection des clés de chiffrement stockées localement 36

37 L indispensable expertise humaine Disposer de compétences formées au développement sécurisé Former les intervenants sur leur rôle en sécurité Certification des compétences en sécurité Réponse aux incidents Documentation des projets Cellule d homologation Documentation des mises a jour Un développeur ne sera jamais un expert en sécurité 37

38 Structurer la démarche Sécurité des Applications Gouvernance Conception Vérification Déploiement Un modèle de maturité pour aider les organisations à formaliser et à implémenter une stratégie de sécurisation des applications adaptée à ses risques spécifiques. 38

39 Maturité 1 : je débute Ø Vous ne savez pas où se trouvent vos applications Ø Vous savez que vous avez besoin d évaluer votre niveau de sécurité et sensibiliser les équipes Ø Vous êtes dans un cadre réglementaire qui parle de Sécurité des applications Gouvernance Conception Vérification Déploiement Formation des intervenants sur leur rôle en sécurité Compétences en développement sécurisé Architecture de sécurité Tests d intrusion Applicatifs Vérification des environnements Environnements sécurisés Environnements maintenus à jour 39

40 Maturité 2 : je veux protéger mes applications en production Ø Vous savez où se trouvent vos applications Ø Vous souhaitez obtenir une protection de ces applications Ø Vous avez un besoin de conformité Gouvernance Conception Vérification Déploiement Formation des intervenants Compétences en développement sécurisé Prérequis contractuels dans les contrats d achats Référentiel de sécurité Architecture de sécurité Sécurité insérée explicitement lors de la phase d exigences fonctionnelles Tests d intrusion Applicatifs Vérification des environnements Environnements sécurisés Environnements maintenus à jour Bouclier virtuel (WAF) 40

41 Maturité 3 : je veux intégrer la sécurité dans mes projets Ø Vous savez où se trouvent vos applications et évaluez régulièrement leur sécurité Ø Vous disposez déjà d une protection de ces applications Ø Vous souhaitez intégrer la sécurité à vos projets de manière plus systématique Gouvernance Conception Vérification Déploiement Formation des intervenants Compétences en développement sécurisé Prérequis contractuels dans les contrats d achats Référentiel de sécurité Méthodologie de développement sécurisé Architecture de sécurité Sécurité insérée explicitement lors de la phase d exigences fonctionnelles Mesure des risques pesant sur les données et applications et adaptation de la réponse Tests d intrusion Applicatifs Vérification des environnements Revue de code Cellule d homologation applicative Environnements sécurisés Environnements maintenus à jour Bouclier virtuel (WAF) Gestion des vulnérabilités 41

42 Maturité 4 : je progresse et améliore ma sécurité applicative Ø Vous savez où se trouvent vos applications et évaluez régulièrement leur sécurité Ø Vous disposez déjà d une protection de ces applications Ø Vous intégrez la sécurité en partie dans vos projets et souhaitez obtenir un ROI Gouvernance Conception Vérification Déploiement Formation des intervenants Compétences en développement sécurisé Prérequis contractuels dans les contrats d achats Référentiel de sécurité Méthodologie de développement sécurisé Mise en place de métrique de contrôle Amélioration des processus Architecture de sécurité Sécurité insérée explicitement lors de la phase d exigences fonctionnelles Mesure des risques pesant sur les données et applications et adaptation de la réponse Mise en place des frameworks de sécurité Tests d intrusion Applicatifs Vérification des environnements Revue de code Cellule d homologation applicative Revue de la conception Environnements sécurisés Environnements maintenus à jour Bouclier virtuel (WAF) Gestion des vulnérabilités Documentation des projets, des mises a jour, Intégrité des logiciels déployés 42

43 Sécuriser le développement d applications mobiles Quelques pistes 43

44 Sécuriser le développement Web mobile Les mêmes préconisations sécurité s appliquent pour les architectures REST et les architectures Web classiques On vérifiera donc que les fondamentaux sont bien respectés dans tout développement REST: Validation des données d entrée Normalisation des données Utilisation correcte des parseurs XML, si applicable Typage fort, si applicable Validation par une approche liste blanche Rejet ou acceptation explicite de la donnée Validation des types de réponse Ne pas s appuyer sur l entête client «Accept» pour fixer le content-type de la réponse 44

45 Sécuriser le développement Web mobile S appuyer au maximum sur les fonctions offertes par les Framework Ne pas réinventer la roue! Système d authentification Validation des entrées Encodage des sorties Chiffrement / déchiffrement des données, cookies, Protection CSRF Protection XSS (X-Content-Type-Options: nosniff) Protection clickjacking (X-Frame-Options: deny ) 45

46 Gestion de l authentification et des sessions REST est sans état, donc chaque requête doit contenir les éléments permettant au serveur de la légitimer L authentification basic sur TLS est recommandée pour des scénarios simples Ce système garanti par ailleurs que les informations d authentification ne seront jamais journalisés (utilisation de l entête HTTP Authorization: Basic) Il est souvent nécessaire d utiliser un système de session ou d API Key L identifiant / la clé doivent être transmis en POST pour ne pas être capturés dans les logs

47 Gestion de l authentification et des sessions Le principe de session est strictement similaire à celui utilisé par les applications Web classiques Mieux que rien, mais largement perfectible Des mesures additionnelles sont requises pour les services sensibles Protection anti-rejeu: Si un attaquant rejoue une requête capturée, il peut usurper l identité d une personne légitime sur l application Utiliser une clé de chiffrement temporaire, dérivée de l API Key, la date, l heure, l adresse IP Protéger le stockage de l API Key sur le périphérique client isadmin=false &debug=false &allowcsrpanel=false rules=af32e89b239ff0bc3dce341 8BCF90D482B8BBA0A0C0C0C0C43 47

48 API Keys Les APIs keys sont préférables à l utilisation de mot de passe Longueur très grande, aléatoire et non prédictible Générées automatiquement, lors de l enrôlement de l utilisateur ou de son périphérique (ex Smartphone) Elles peuvent également améliorer la vitesse dans les environnements à très fort trafic (absence de calcul de hash) Pas d impact en cas de changement de mot de passe Le stockage de la clé sur le périphérique client est un enjeu important Lecture seule pour le propriétaire Utilisation des fonctions de chiffrements disponibles sur le périphérique client 48

49 Protection contre le farming De nombreux web-services REST sont exposés au farming Il est possible d énumérer les ressources des bases de données en appelant le service avec des identifiants croissants Il n y a pas de technique «Officielle» pour se prémunir contre cela, mais Contrôler et authentifier les accès Ne jamais utiliser de références directes 49

50 Configurer correctement le serveur Web Les architectures REST nécessitent l utilisation de méthodes HTTP potentiellement dangereuses: PUT, DELETE notamment Il est essentiel de valider que la configuration du serveur n autorise pas ces méthodes ailleurs qu à destination des URI qui portent des services de type REST! Toujours valider, que l utilisateur a le droit d appeler la méthode sur la ressource qu il demande Exemple: Un utilisateur anonyme peut faire du GET ou du POST Exemple: Il est nécessaire d être authentifié pour appeler UPDATE Exemple: Il est nécessaire de disposer d un profil administrateur pour DELETE 50

51 Protection contre le Cross-Site-Request Forgery Toutes les requêtes, en particulier celles utilisant PUT, POST et DELETE, doivent être protégées contre le CSRF La meilleure des protections consiste à utiliser un token et, surtout, de valider qu aucune attaque de type Cross-Site-Scripting n est possible à l encontre du client 51

52 Amélioration de la sécurité HTTPS HTTPS doit être utilisé pour tout échange d information sensible Paramètres d authentification API Key Informations personnelles Certificate pinning Technique consistant à associer une clé publique ou un certificat avec un site Web et de stocker cette association côté client En cas de compromission du site distant (ex: Redirection de trafic suite à une attaque sur les serveurs DNS), le client peut s apercevoir de l attaque Idéalement, cette association doit être faire lors du développement (et non pas à l issue de la première connexion car la compromission pourrait déjà avoir eu lieu) 52

53 HTTP Strict Transport Security (HSTS) Mécanisme permettant au serveur d informer le navigateur de ne jamais accepter de connexion HTTP non sécurisées et donc de systématiquement utilisé une connexion HTTPS Permet de lutter contre les «downgrade attacks». Exemple: Un site normalement en HTTPS, accédé en HTTP L information est transmise au moyen d un entête HTTP positionné par le serveur Exemple: Strict-Transport-Security "max-age= ;preload.» La première connexion n est donc pas protégée! Sauf si le site est dans la liste des sites préchargés par le navigateur Le navigateur recevant cet entête doit: Transformer automatiquement tous les liens http pointant vers le serveur en liens https Refuser l accès et afficher un message d erreur s il ne parvient pas à authentifier le certificat du serveur 53

54 JOSE: Javascript Object Signing and Encryption JOSE est à JSON ce que WS-Security est à SOAP Signature de tout ou partie des messages JWS: JSON Web Signature Chiffrement de tout ou partie des messages JWE: JSON Web Encryption Jeton JWT: JSON Web Token Utilisé pour décrire les droits d un utilisateur, d un objet Peux contenir des claims OpenID ( Encodé en base64url 54

55 JOSE: Javascript Object Signing and Encryption JS JWS: Implémentation pure Javascript de JWT ( JSON Web Token ) Implémentation pure Javascript de JWS ( JSON Web Signature ) Démonstration de signature JWS: Générateur / validateur de signature JWT: 55

56 OAuth2 OAuth2 est un protocole permettant à une application cliente d effectuer des opérations en tant qu un utilisateur donné, avec la permission de ce dernier Les actions autorisées pour une application cliente donnée sont définies sur un serveur de ressources (un autre serveur Web / Web-service) L utilisateur approuve les actions en informant un serveur d autorisation qu il fait confiance à l application cliente Une application cliente peut également agir en son propre non (sans authentification utilisateur) si elle a autorisée sur le serveur d autorisation 56

57 OAuth2 57

58 Questions / Réponses 58