J'oublie souvent ce fichier, mais les situations réelles reviennent régulièrement me rappeler
qu'il contient plein d'informations utiles (dont, par exemple, des valeurs par défaut
trahissant le framework ou le CMS utilisé).
Ce n'est pas un JWT, puisqu'il ne démarre pas par eyJ
J'essaie souvent d'avoir, dans la moitié droite, la partie "locale" (ou test)
et dans la moitié gauche la partie "distante" (ou "prod").
Ca permet de limiter les risques de se mélanger.
Touche "Windows" + une flèche (gauche/droite) permet de mettre la fenêtre sur la moitié
correspondante de l'écran
La deuxième commande supprime les retours à la ligne du base64, via tr -d "\n"
Il est courant, dans les systèmes réels, d'avoir ce genre de mauvaise interprétation.
Le cas classique concerne les headers HTTP: deux systèmes chaînés peuvent ne pas lire les headers
dans le même ordre, et en cas de header présent en double, le premier système ne lira que le premier
header, alors que l'autre utilisera le second header. Cela offre des possibilités de bypass
Comme on l'a vu pour
Fiché JS (Web)
,
l'absence de traffic lors de la "vérification" du mot de passe implique que celle-ci se fait côté client.
On doit donc avoir reçu, dans un fichier quelconque, le mot de passe (hashé ou chiffré éventuellement)
C'est là où je me suis dit
"inutile de casser ce hash! le cookie contient le hash! autant l'utiliser directement"