Alternative du Bluetooth classique, le Bluetooth Low Energy est choisi de manière croissante pour l’IoT. Cette technologie, aussi connue sous l’abréviation BLE, s’impose de plus en plus pour l’Internet des objets parce qu’elle est idéale pour envoyer de petites quantités de données entre appareils et pour préserver la batterie ; ce qui correspond parfaitement aux besoins de l’IoT. Le Bluetooth classique, de son côté, reste utilisé pour envoyer de grande quantité de données entre un appareil et l’utilisateur (les casques et enceintes sans fil se servent du Bluetooth par exemple).

Les périphériques USB sont tellement pratiques. Lorsque l’on a besoin de stocker des petites quantités de données, nous utilisons une clé USB. Tout le monde en a une, et nous leur faisons confiance. Les clés USB sont l’un des moyens principaux pour faire de l’espionnage industriel, mais les attaques au hasard contre des civils et des entreprises sont également courantes.

Le rapport Honeywell 2018 sur les menaces USB pour les opérateurs industriels (en anglais) a analysé un échantillon de 50 sites. Energie, chimie, pâte et papiers, pétrole et gaz et autres secteurs industriels étaient concernés par l’étude. Parmi les sites ciblés, 44 % ont bloqué un fichier suspect venant de ports USB, et 15 % des menaces détectées et bloquées étaient des menaces de haut niveau, comme Stuxnet, Wannacry et Mirai.

La sécurité des objets connectés est un sujet d’actualité, cependant les tests d’intrusion IoT sont encore loin d’être une pratique généralisée. La plupart des constructeurs priorisent d’abord les fonctionnalités et le design du produit. Cependant, même avec une approche « security by design », le test d’intrusion reste incontournable pour connaître les risques de sécurité réels, puis pour prendre les mesures nécessaires.

Qu’est-ce qu’une attaque Cross Site Request Forgery ?

L’attaque CSRF (ou en français falsification de requête intersite) est une attaque qui oblige un utilisateur final à exécuter des actions non désirées et sans qu’il s’en rende compte sur une application web dans laquelle il est actuellement authentifié.
Les attaques CSRF visent spécifiquement les demandes de modification et non le vol de données, car l’attaquant n’a aucun moyen de voir la réponse à la demande falsifiée. Le résultat des actions est ce qui intéresse l’attaquant.

Ce type d’attaque s’appuie sur le fait que lorsqu’un utilisateur est authentifié sur une application, celle-ci lui fournit la plupart du temps un identifiant de session, stocké dans un cookie sur son navigateur.
A chaque fois que l’utilisateur envoie une requête vers le serveur, le navigateur envoie également automatiquement ce cookie de session. Vous trouverez dans l’article lié plus d’informations à propos des attaques CSRF.

Notez bien qu’il suffit que l’utilisateur soit resté connecté (sans avoir une page ou un onglet du site ouvert) pour qu’une attaque CSRF fonctionne.

Nous pensons souvent qu’un pare-feu suffisamment restrictif protège l’accès aux services non ouverts. Nous croyons aussi que seule une machine compromise peut donner accès au reste du réseau interne.

Et bien nous avons tort, et c’est ce que nous allons voir avec une vulnérabilité des applications web : le Server-Side Request Forgery (SSRF).

Qu’est-ce que les SSRF ?

A partir d’une application web vulnérable, les SSRF permettent d’interagir avec le serveur, afin d’en extraire des fichiers et de trouver ses autres services actifs. Mais cela ne s’arrête pas là. Il est également possible de scanner le réseau interne afin d’en cartographier les IP et Ports ouverts.

Durant nos audits il nous arrive encore très souvent de rencontrer des énumérations utilisateurs qui pourraient avec les bonnes méthodes être facilement évitées. Dans cet article, nous traiterons des énumérations d’utilisateurs sur les formulaires de connexion, de réinitialisation de mot de passe et de création de compte. Cependant, les énumérations utilisateur peuvent se trouver sur d’autres fonctionnalités, telles que, par exemple, des formulaires de recherches ou des envois de messages.

Cette série d’articles aborde les points les plus importants de la sécurité des applications mobiles, quelle que soit la plateforme (iOS, Android ou autre).
L’objectif est de démystifier les différents aspects de la sécurité mobile, avec des mots très simples.

Ce troisième épisode présente les failles liées aux échanges de données

Cette série d’articles aborde les points les plus importants de la sécurité des applications mobiles, quelle que soit la plateforme (iOS, Android ou autre).
L’objectif est de démystifier les différents aspects de la sécurité mobile, avec des mots très simples.

Ce second épisode présente les failles liées au stockage non sécurisé des données.

Cette série d’articles aborde les points les plus importants de la sécurité des applications mobiles, quelque soit la plateforme (iOS, Android ou autre).
L’objectif est de démystifier les différents aspects de la sécurité mobile, avec des mots très simples.

Sujet numéro 1 cette semaine : Les contrôles côté serveur

Mis à jour : 23 Déc 2020

Cet article ne remplace pas de bonnes connaissances en PHP, mais peut vous donner de réels bons conseils pour booster votre sécurité.
Il n’y aura ici rien à copier/coller directement dans vos fichiers PHP. Cependant, nous croyons que ces conseils et bonnes pratiques vous apporteront des bénéfices à long terme, en comprenant et en appliquant les différents points en fonction de vos besoins et de votre contexte.

Cet article est le troisième de notre série dédiée à la sécurité pour PHP.
Le premier article vous donne des indications pour la configuration de PHP, les mises à jour, le filtrage des données, ainsi que l’organisation du code.
Le second article traite de la protection contre les attaques les plus courantes.

Nous allons maintenant traiter des risques liés aux cookies, uploads, CRSF ainsi que de la sécurité par l’obscurité.