pvharmo2/gha-lab-e4a85583c3Laboratoire de recherche en sécurité reproduisant la CVE-2020-36762 (GHSA-h9gr-83jq-f3xc) : injection de commande bash via github.event.comment.body dans le workflow de commentaire de ONSdigital/ras-collection-instrument
Artefact de recherche automatisé — pas le projet en amont.
Ce dépôt est un laboratoire jetable construit par un harnais automatisé pour un mémoire de maîtrise à l'Université Laval sur la reproduction de vulnérabilités publiées dans des workflows GitHub Actions. Il s'agit d'un instantané verbatim de
ONSdigital/ras-collection-instrumentau commit493dc3d7c85f39c44e879941df9d5682865da109(2020-12-03), redistribué sous la licence propre de ce projet, dont le fichier est inclus inchangé dans cet instantané.Le projet en amont n'est pas impliqué, n'est jamais ciblé, et la vulnérabilité étudiée ici est déjà publique. Chaque secret et variable dans ce dépôt est une valeur factice générée aléatoirement — aucun identifiant réel n'est présent. Les références d'actions et les images d'exécuteurs sont épinglées à ce qu'elles résolvaient au 2020-12-03 ; voir
pinning.mddans la sortie du harnais pour chaque modification apportée à l'instantané.Questions ou objections : [email protected]
Il s'agit du micro-service RAS Collection Instrument, responsable du téléversement des exercices et instruments de collecte. Il peut également être utilisé pour télécharger des instruments de collecte sous forme de fichiers .xlsx, et permet la recherche d'instruments de collecte via des filtres de recherche. Ce service a la capacité de lier et de délier des exercices de collecte avec des instruments de collecte. La relation entre les exercices et les instruments est de type un-à-plusieurs, donc un exercice de collecte peut avoir plusieurs instruments de collecte. Chaque instrument de collecte dans le schéma JSON possède une référence d'unité d'échantillon, un type et un ID de résumé, ainsi que des attributs supplémentaires. Ce service communique principalement avec le service d'exercices de collecte, ainsi qu'avec les services party, case et survey. Les informations de journalisation concernant les instruments de collecte sont envoyées à rabbitmq.
Les instruments de collecte sont stockés dans une table d'instruments avec les champs suivants :
type = le type de l'exercice de collecte (c.-à-d. SEFT, EQ, etc.) instrument_id = l'UUID de l'instrument stamp = l'horodatage indiquant quand l'instrument de collecte a été créé survey_id = l'UUID de l'enquête associée classifiers = les classificateurs de l'enquête survey = l'enquête elle-même seft_file = le fichier seft de l'instrument
Trois vues de points de terminaison différentes existent : /collectioninstrument, qui est utilisée pour la majorité des points de terminaison, ainsi que /survey_responses et /info.
Lorsqu'un instrument de collecte est téléversé pour un exercice de collecte, il écrit un message sur la file Seft.Instruments pour le service rm-collection-exercise Lorsqu'une réponse d'enquête SEFT est téléversée, elle écrit un message sur la file Seft.Responses pour le service sdx-seft-consumer
Cela nécessite que pipenv soit installé :
pip install pipenv
Pour exécuter les tests, un serveur rabbitmq et une base de données sont requis. Le script tox crée et exécute ces dépendances dans des conteneurs Docker, qui sont détruits après l'exécution des tests unitaires.
pipenv install --dev
pipenv run tox
Pour exécuter le service avec les dépendances requises :
docker-compose up -d db rabbitmq
pipenv run python run.py
Pour tester que le service est opérationnel :
curl http://localhost:8082/info
La base de données sera automatiquement créée au démarrage de l'application.
Pour exécuter le service dans un conteneur Docker, un script Compose est inclus :
docker-compose up -d
Les variables d'environnement disponibles pour la configuration sont listées ci-dessous :
| Environment Variable | Description | Default |
|---|---|---|
| MAX_UPLOAD_FILE_NAME_LENGTH | Longueur maximale des noms de fichiers | 50 |
| LOGGING_LEVEL | Niveau du journaliseur | INFO |
| JSON_SECRET_KEYS | Représentation JSON des clés | None |
| ONS_CRYPTOKEY | Une clé utilisée par le Cryptographer | None |
| SECURITY_USER_NAME | Nom d'utilisateur que le client utilise pour s'authentifier auprès d'autres API | admin |
| SECURITY_USER_PASSWORD | Mot de passe que le client utilise pour s'authentifier auprès d'autres API | secret |
| COLLECTION_EXERCISE_SCHEMA | Emplacement du schéma de l'instrument de collecte | application/schemas/collection_instrument_schema.json |
| CASE_URL | URL du service case | 'http://localhost:8171' |
| COLLECTION_EXERCISE_URL | URL du service d'exercices de collecte | 'http://localhost:8145' |
| SURVEY_SERVICE_URL | URL du service d'enquêtes | 'http://localhost:8080' |
| PARTY_URL | URL du service party | 'http://localhost:8081' |
| RABBITMQ_AMQP_COLLECTION_INSTRUMENT | URI pour rabbitmq | None |
| RABBITMQ_AMQP_SURVEY_RESPONSE | URI pour rabbitmq | None |
Ces valeurs sont définies dans config.py
Naviguez vers /developer_scripts et exécutez import.py, répondez aux invites sur la ligne de commande
collection_instrument_schema possède deux champs d'attributs apparemment identiques : formType et formtype.entname1/2/3 et runame1/2/3, entre autres. Le schéma devrait être repensé, ou disposer d'une documentation plus spécifique./collectioninstrument/count, c'est retourner le nombre d'instruments de collecte. Pourquoi le service a-t-il besoin de faire cela ? Cela ne pourrait-il pas être accompli par une requête de base de données ?