Partie 10

Secrets, sessions et confiance : toutes les valeurs ne doivent pas entrer dans un script

L’automatisation devient dangereuse lorsque toute valeur utile est traitée comme du texte inoffensif. Mots de passe, clés privées, cookies et état d’authentification doivent vivre autrement que des chemins, tailles d’image ou noms de table.

Classer la valeur avant de l’automatiser

Un chemin, nom d’archive ou largeur d’image est une configuration ordinaire. Un mot de passe, une clé privée, un token de session ou un identifiant de base de données peut donner accès. Mélanger les deux dans un script réutilisable transforme le script lui-même en secret.

Avant d’enregistrer une valeur, posez deux questions : peut-elle autoriser quelque chose ? Serais-je à l’aise pour copier ce fichier vers un autre projet ou le partager en relecture ? Sinon, le secret n’a pas sa place dans la recette.

Inspecter l’environnement est utile, mais l’environnement n’est pas un coffre-fort

env masque volontairement les valeurs dont le nom paraît sensible. C’est une sécurité de présentation, pas la preuve que chaque variable d’environnement est sûre ni qu’aucun secret n’existe sous un nom inattendu.

Inspectez uniquement le namespace ou la valeur nécessaire. Évitez captures d’écran et exportationations de dumps complets, et ne transformez jamais une vue masquée du terminal en autorisation de publier la configuration réelle du serveur.

env

env server

env request

Sessions et cookies sont de l’état applicatif, pas du texte de brouillon

ses montre les données hiérarchiques de session PHP et coo les cookies visibles sur une surface distincte. L’état protégé d’authentification/cookie de session est bloqué pour les chemins ordinaires d’exportation et d’écrasement.

Cette frontière compte parce que la session peut porter identité, autorisation et état temporaire. Inspectez étroitement, ne modifiez que vos propres namespaces et n’utilisez pas la session comme cachette pratique pour des secrets de longue durée.

ses -l

coo

coo -a

Un hash peut prouver l’identité des octets ; il ne cache pas l’original

hash calcule des empreintes et des HMAC. Une empreinte répond très bien à la question « ces octets ont-ils changé ? » et permet d’identifier un fichier d’archive ou un artefact de version publiée.

Le calcul d’une empreinte n’est pas du chiffrement. Si la valeur d’origine appartient à un petit ensemble facile à deviner, un hash ne la rend pas confidentielle. Utilisez HMAC lorsque l’authenticité dépend d’une clé secrète, et le chiffrement lorsque le contenu lui-même doit rester illisible.

hash -s "hello terminal"

hash

Le chiffrement ne protège le contenu que si la clé est protégée elle aussi

enc utilise des chiffrements authentifiés, une saisie de mot de passe masquée et des modes à clé exacte. Commencez par enc pour voir ce que le serveur accepte ; la saisie masquée garde le mot de passe hors de l’historique visible.

Un fichier chiffré posé à côté de sa clé exposée n’est presque pas protégé. Séparez clé et données chiffrées entre frontières de confiance si possible, comprenez le mécanisme de récupération et testez le déchiffrement avant de supprimer le texte en clair.

enc

Les permissions réduisent l’accès ; elles ne remplacent pas la cryptographie

Un mode comme 0600 signifie que le propriétaire courant devrait être le seul lecteur/écrivain ordinaire. C’est utile pour des fichiers de clé locaux et exportationations privés lorsque l’hébergement respecte les modes UNIX.

Les permissions ne protègent pas contre le propriétaire du compte d’hébergement, les sauvegardes ou un processus PHP compromis. Après mod, utilisez stat pour vérifier ce qui a réellement changé et combinez permissions avec le bon modèle de stockage et de chiffrement.

cd lil-playground

md trust

echo "example private note" > trust/note.txt -r

mod trust/note.txt -0600

stat trust/note.txt

hash trust/note.txt

Distinguer nettoyage, désinstallation et destruction

clear efface seulement le historique visible. uninstall <module> retire un module d’extension. kill -include retire la couche d’interface optionnelle, kill -install la couche d’extensions, et kill seul marque la frontière de suppression complète du terminal.

Ces actions ne doivent jamais se confondre dans les automatismes. Avant une opération destructrice, nommez la couche que vous voulez retirer et les fichiers qui doivent rester. Un utilisateur prudent peut expliquer le rollback avant d’appuyer sur Entrée.

Nettoyage visuelclearSeulement l’historique visible ; fichiers et modules restent

Retirer un moduleuninstall <module>Un module d’extension ; dépendances respectées

Réinitialiser l’interfacekill -includeCouche CSS/JavaScript persistante ou de session

Réinitialiser les extensionskill -installCouche d’extensions installées ; Core reste

Suppression totalekillL’installation lil-terminal elle-même

Conservez ceci comme script

Enregistrez ceci sous trust-checkpoint.lil. Il ne crée que des données d’exemple, applique un mode de fichier restrictif, consigne les métadonnées et stocke un empreinte. Remarquez ce qu’il n’automatise pas volontairement : la saisie du mot de passe et les clés de déchiffrement restent hors du script.

#lil
@install md echo mod stat hash
cd lil-playground
md trust
echo "example private note" > trust/note.txt -r
mod trust/note.txt -0600
stat trust/note.txt
hash trust/note.txt > trust/note.sha256 -r
stat trust/note.sha256