10. Sécurité - BlacF0X/owl GitHub Wiki
Sécu faite :
- pour la db supabase, mise en place du 'Row Level Security'
- Pour l'api, ajout de cors
- Fix d'une vulnérabilité critique de React et de ses frameworks (Next.js) https://github.com/vercel-labs/fix-react2shell-next
J'ai mis en place une stratégie de sécurité dite **"Shift Left"** (sécurisation dès le développement) couvrant trois niveaux critiques :
### 1. Analyse Statique du Code (SAST) - *Via CodeQL*
* **Ce que c'est :** Un scanner qui analyse ton code source (TypeScript, JavaScript) à la recherche de failles de logique.
* **Ce que ça protège :** Détecte les vulnérabilités de code comme les injections SQL (si TypeORM est mal utilisé), les failles XSS (Cross-Site Scripting) dans le Front Next.js, ou les fuites de données logiques.
* **Impact :** Vérifie la qualité de **ton** code à chaque push ou pull request.
### 2. Analyse des Dépendances (SCA) - *Via Dependabot*
* **Ce que c'est :** Un robot qui surveille en permanence ton fichier `package.json` et `package-lock.json`.
* **Ce que ça protège :** T'alerte si une bibliothèque npm que tu utilises (ex: `express`, `next`, `clerk-sdk`) contient une faille de sécurité publique connue (CVE).
* **Impact :** Évite que ton application ne soit piratée à cause d'une librairie tierce obsolète.
### 3. Protection des Secrets (Secret Scanning)
* **Ce que c'est :** Un scanner qui analyse l'historique de tes commits et les nouveaux ajouts.
* **Ce que ça protège :** Détecte les clés d'API, tokens Doppler, chaînes de connexion Supabase ou JWT secrets qui auraient été commités par erreur.
* **Impact :** Empêche les fuites d'identifiants qui permettraient à un attaquant de prendre le contrôle de ton infra ou de voler les données utilisateurs.
### 4. Correction Assistée par IA (Copilot Autofix)
* **Ce que c'est :** Une fonctionnalité liée à CodeQL.
* **Ce que ça protège :** Réduit le temps d'exposition aux failles.
* **Impact :** Si CodeQL trouve une faille, l'IA te proposera directement une suggestion de code pour la corriger, t'évitant de chercher comment résoudre le problème de sécurité complexe.
---
### Résumé de ta couverture actuelle
| Niveau de protection | Outil activé | Cible |
| :--- | :--- | :--- |
| **Code Propriétaire** | CodeQL | Ton code TypeScript (`src/`, `app/`) |
| **Supply Chain** | Dependabot | Tes paquets npm (`node_modules`) |
| **Fuites de Données** | Secret Scanning | Tes fichiers de config (`.env`, config, etc.) |
| **Remédiation** | Copilot Autofix | Aide à la correction rapide |
C'est une configuration très robuste pour un projet en production ! 🛡️🦉
Sécu à faire :
- forcer la connexion ssl à la db voir https://supabase.com/dashboard/project/eundgqdqbernaikoeoxj/database/settings
Un document expliquant la mise en place de la sécurité doit être fourni et joint au wiki, repenant : Analyse de sécurité, quels sont les risques, les contre-mesures, quels éléments à sécuriser, code, serveur, logicielle, DB, autres…
Résultats et interprétation des analyses de sécurité avec des outils adéquats.
un diagramme de flux de données est attendu
Wiki Sécurité - Project OwL
1. Introduction
Contexte
Project OwL est un système intelligent de surveillance environnementale conçu pour monitorer en temps réel l'état des fenêtres (ouvertes/fermées), la température, l'humidité ainsi la concentration en CO₂ dans des espaces intérieurs. Le système est destiné à des environnements variés : résidentiels (villas/appartements), professionnels (bureaux) et étudiants (kots).
Objectif de l'analyse de sécurité
Cette analyse vise à :
- Identifier les risques et vulnérabilités présents dans l'architecture Project OwL
- Évaluer la sécurité des données collectées
- Proposer des contre-mesures pour renforcer la protection du système
Périmètre de l'analyse
L'analyse couvre les composants suivants :
- Capteurs : capteurs de fenêtre, capteur CO₂/température/humidité
- Boîtier central : dispositif de collecte et d'agrégation des données
- Infrastructure réseau : communications entre capteurs et serveur
- API / Serveur backend : logique métier et traitement des données
- Base de données : stockage et gestion des données
- Application web : interface utilisateur (Next.js/React-App)
- Infrastructure cloud : serveurs et services hébergés
2. Diagramme de flux de données (DFD)
Vue d'ensemble
Zones de confiance identifiées
| Zone | Éléments | Niveau de confiance |
|---|---|---|
| Zone Physique (Capteurs) | Capteur Fenêtre, Capteur CO₂/Temp/Humidité, Boîtier Central | Faible (risques physiques, compromission) |
| Zone Réseau (Backend) | API, Base de Données, Serveur Backend | Moyen (accès distant, connexions réseau) |
| Zone Utilisateur (Frontend) | Site Web, Utilisateur (authentifié par Clerk) | Moyen (authentification requise) |
Flux de données principaux
- Capteurs → Boîtier Central : État des fenêtres (ouvert/fermé), mesures environnementales
- Boîtier Central → API : Données agrégées via HTTPS/TLS
- API ↔ Base de Données : Requêtes SQL, stockage et lecture des données
- API → Site Web : Données au format JSON via API REST
- Site Web → Utilisateur : Interface affichant les données (authentification Clerk)
- Utilisateur → Site Web : Interactions, paramètres, commandes
3. Actifs à protéger
Inventaire des actifs critiques
| Type | Actif | Description | Niveau de criticité |
|---|---|---|---|
| Données | Mesures environnementales | CO₂, température, humidité | Élevé |
| Données | État des fenêtres | Historique ouvertures/fermetures | Élevé |
| Données | Données utilisateurs | Identifiants, adresses email, préférences | Critique |
| Données | Historique des alertes | Notifications, logs d'événements | Moyen |
| Code | Code source application web | Frontend Next.js | Élevé |
| Code | Code source API | Backend, logique métier | Critique |
| Code | Firmware capteurs | Logiciel embarqué des capteurs | Critique |
| Infrastructure | Serveur backend | Hébergement API | Critique |
| Infrastructure | Base de données | Stockage des données | Critique |
| Infrastructure | Boîtier central | Unité de collecte centralisée | Élevé |
| Réseau | Communications capteurs-boîtier | Wireless/Bluetooth/Zigbee | Élevé |
| Réseau | Communications boîtier-API | HTTPS/TLS | Élevé |
| Authentification | Credentials Clerk | Gestion des identités | Critique |
| Secrets | Clés API, tokens | Gestion via Doppler | Critique |
4. Analyse STRIDE
Introduction à STRIDE
STRIDE est une méthodologie de modélisation des menaces développée par Microsoft. Elle identifie 6 catégories de menaces :
- Spoofing (Usurpation d'identité)
- Tampering (Altération de données)
- Repudiation (Répudiation d'action)
- Information Disclosure (Divulgation de données)
- Denial of Service (Déni de service)
- Elevation of Privilege (Escalade de privilèges)
4. Analyse des risques (STRIDE)
| Type de risque | Pour le Project OwL |
|---|---|
| Usurpation d’identité (Spoofing) | Un faux capteur envoie de fausses mesures au boîtier |
| Altération de données (Tampering) | Un attaquant modifie les données envoyées à l’API |
| Fuite d’informations (Information Disclosure) | Accès non autorisé aux données utilisateurs |
| Déni de service (DoS) | Saturation de l’API ou du boîtier pour les rendre indisponibles |
| Élévation de privilèges | Un utilisateur normal prend des droits admin |
5. Vulnérabilités IoT (OWASP IoT Top 10)
Contexte OWASP IoT Top 10
Vulnérabilités identifiées
| Rang | Vulnérabilité OWASP | Applicabilité à Project OwL | Risque actuel | Priorité de correction |
|---|---|---|---|---|
| 1 | Mots de passe faibles / codés en dur | Credentials par défaut sur boîtier, capteurs | faible | faible |
| 2 | Services réseau non sécurisés | Communication capteurs sans chiffrement | Élevé | Critique |
| 3 | Interfaces écosystème non sécurisées | API mal protégée, sans rate limiting | Moyen | Haute |
| 4 | Absence de mécanisme de mise à jour sécurisé | Firmware capteurs non mettable à jour | Moyen | Haute |
| 5 | Composants obsolètes / vulnérables | Dépendances npm outdated | Moyen | Haute |
| 6 | Protection insuffisante de la vie privée | Données utilisateurs mal encryptées | Élevé | Critique |
| 7 | Transfert / stockage de données non sécurisé | Données en clair en base de données | Élevé | Critique |
| 8 | Absence de gestion des appareils | Pas d'inventaire des capteurs/boîtiers | Moyen | Moyenne |
| 9 | Paramètres par défaut non sécurisés | Configuration usine trop permissive | Moyen | Haute |
| 10 | Manque de durcissement physique | Boîtier sans protection contre l'accès physique | Moyen | Moyenne |
Nous avons surtout retenu ces points de vigilance issus de l’OWASP IoT Top 10 :
- Éviter les mots de passe par défaut ou codés en dur sur les capteurs/boîtiers.
- Chiffrer les communications entre capteurs, boîtier et serveur.
- Mettre à jour régulièrement le firmware et les dépendances logicielles.
- Protéger physiquement le boîtier central (accès limité, boîtier fermé).