Skip to content

Cybersécurité ​

Section à compléter par Jean-Baptiste Viossi

Cette section accueille l'audit de sécurité de TimeManager. Le plan ci-dessous est une suggestion. Chaque partie peut devenir sa propre page dans timemanager-docs/cybersecurite/, à ajouter dans la barre latérale (timemanager-docs/.vitepress/config.mts).

En bref ​

SujetDétail
ResponsableJean-Baptiste Viossi
PérimètreSite web, API, application mobile, infrastructure
Ce qui existe déjàSécurité de l'infrastructure, Limites et améliorations, Authentification mobile

Plan suggéré ​

1. Périmètre ​

Ce qui est audité, et ce qui ne l'est pas.

CibleAdresse ou dossier
Site webtime.jostud.com · timemanager-web/
APIapi.time.jostud.com/api · timemanager-api/
Application mobiletimemanager-mobile/
Jenkinsci.time.jostud.com · timemanager-devops/jenkins/
Serveurstm-prod et tm-tooling · timemanager-devops/ansible/

Préciser aussi : les dates de l'audit, l'environnement testé (production ou copie), et ce qui est hors périmètre.

2. Méthode ​

Les référentiels et les outils utilisés. Par exemple :

DomaineRéférentielOutils possibles
Web et APIOWASP Top 10, OWASP ASVSOWASP ZAP, Burp Suite
APIOWASP API Security Top 10Requêtes manuelles, Postman
MobileOWASP MASVSMobSF
InfrastructureDurcissement Linux et Dockernmap, testssl.sh, Trivy, Docker Bench
DépendancesFailles connues (CVE)npm audit, mix deps.audit, Trivy

3. Modèle de menaces ​

  • Ce qu'on protège : les heures pointées, les comptes, les mots de passe, les données personnelles (RGPD), l'accès aux serveurs.
  • Qui pourrait attaquer : un visiteur anonyme, un employé qui veut modifier ses heures, un manager qui veut voir une équipe qui n'est pas la sienne, quelqu'un qui a volé un téléphone.
  • Par où : les formulaires, les routes de l'API, les liens envoyés par email, les ports ouverts, la chaîne de déploiement.

4. Ce qui est déjà en place ​

Un rappel des protections existantes, à vérifier pendant l'audit :

ProtectionOù c'est documenté
Session en cookies HttpOnly, jeton CSRF, renouvellementAuthentification mobile, Architecture
Droits vérifiés par l'API à chaque requêteLe projet
Liens à usage unique, dont seule l'empreinte est stockéeBase de données
HTTPS partout, pare-feu, réseau privé, base isoléeSécurité de l'infrastructure
Secrets chiffrés, scan des imagesSecrets, Pipelines
Faiblesses déjà connuesLimites et améliorations

5. Résultats ​

Un tableau de synthèse, du plus grave au moins grave :

IDTitreGravitéComposantStatut
SEC-01Exemple : une route renvoie les données d'un autre utilisateurCritiqueAPIOuvert
SEC-02Élevée
SEC-03Moyenne

Échelle de gravité suggérée, alignée sur CVSS :

GravitéScore CVSSSens
Critique9,0 à 10Exploitable facilement, impact majeur : à corriger immédiatement
Élevée7,0 à 8,9À corriger avant la prochaine mise en production
Moyenne4,0 à 6,9À planifier
Faible0,1 à 3,9Amélioration
Info0Remarque sans risque direct

6. Détail d'une vulnérabilité ​

Un modèle à reprendre pour chaque résultat :

md
### SEC-01 · Titre court

| Gravité | Composant | Statut |
|---|---|---|
| Élevée (CVSS 7.5) | API · GET /users/:id/data | Ouvert |

**Description.** Ce qui ne va pas, en une ou deux phrases.

**Reproduction.**
1. Se connecter avec un compte employé.
2. Appeler `GET /api/users/12/data` avec l'id d'un autre utilisateur.
3. Constater que la réponse contient ses données.

**Impact.** Ce qu'un attaquant peut obtenir ou faire.

**Correction proposée.** Ce qu'il faut changer, et où.

**Responsable.** La personne qui corrige (voir L'équipe).

7. Plan de correction et suivi ​

Qui corrige quoi, avant quand, et la vérification après correction. Les corrections touchent le code de chaque partie : elles passent par son responsable (voir L'équipe).

8. Conclusion ​

Le niveau de sécurité global, les risques qui restent acceptés, et les recommandations pour la suite.

Mis à jour le: