js cookie monitor debugger hook
v0.11
Dépôt GitHub : https://github.com/JSREI/js-cookie-monitor-debugger-hook
Chinois simplifié | Anglais
À une époque où les données n'ont pas de prix, la confrontation entre les robots d'exploration et les anti-crawlers est devenue intense. Les anti-crawlers de cookies sont最常见之一. Les sites Web installent des cookies via un code JS si déroutant que même les mères le font. ne le reconnaît pas (généralement lors de la navigation) Empreintes digitales du serveur, cookies qui doivent être apportés lors des demandes, etc.), Cookies qui doivent être apportés face aux demandes mais ne savent pas où ils sont générés, Vous vous débattez dans des dizaines de milliers de lignes confuses de conneries JS que votre mère ne reconnaît pas, dans l'espoir de trouver l'endroit où les cookies sont générés (si la pensée inverse n'est pas scientifique, vous risquez de vous étouffer plusieurs fois...), et Voulez-vous même trouver plusieurs fois. Essayez-vous de vous inciter à abandonner, ou pourquoi ne pas simplement utiliser une méthode d'émulation de navigateur comme Selenium ? Si vous êtes un lâche, ce script est là pour vous aider ! (Vous et moi savons tous les deux que ce paragraphe n'a aucun sens pour soutenir la scène. Vous pouvez le sauter, si vous n'êtes pas assez malheureux pour finir de le lire...)
La fonction de ce script est grossièrement divisée en deux parties :
Ce script injecte son propre code JS dans la page et accroche document.cookie pour remplir diverses fonctions. Par conséquent, avant d'utiliser ce script, vous devez d'abord confirmer que le cookie à générer est bien généré via JS (une méthode très spéciale est introduite plus tard. . Déterminez simplement si le cookie est généré par JS ou renvoyé par le serveur).
À l'heure actuelle, de nombreux scripts Hook ont des postures de hooking incorrectes. Ce script utilise des Hooks ponctuels et répétés, ce qui n'a aucun impact sur la gestion des cookies intégrée au navigateur :
En plus de la fonction de point d'arrêt des cookies, une fonction de suivi des modifications des cookies a été ajoutée, qui permet d'analyser les cookies sur la page dans une perspective plus macro :
(Oubliez ça, abandonnez le codage...)
La couleur est utilisée pour distinguer les types d’opérations :
Chaque opération sera suivie d'un emplacement de code. Cliquez pour localiser l'emplacement du code JS qui a effectué l'opération.
À partir de la version 0.6, des règles de point d'arrêt avec des fonctions plus puissantes et des configurations plus flexibles ont été introduites, et un mécanisme d'événement a été introduit pour subdiviser les modifications de cookies en trois événements : ajouter, supprimer et mettre à jour, prenant en charge des points d'arrêt plus précis. Événements de cookies, veuillez vous référer à la partie 5 de cet article pour plus de détails.
Pourquoi est-il conçu de cette façon ? Une situation relativement courante est que le cookie anti-exploration sur le site Web cible est défini par JS, mais la logique du code JS est de le supprimer frénétiquement d'abord, puis de le supprimer plusieurs fois avant d'ajouter la valeur réelle du cookie. de cette façon, on peut exactement le contrecarrer.
Voici un exemple, comme la protection des cookies de F5, il existe un cookie TS51c47c46075 , qui est supprimé plusieurs fois puis ajouté à nouveau :
Dans ce cas, vous pouvez définir un point d'arrêt pour l'événement cookie nommé TS51c47c46075 afin d'éviter de confondre les événements de suppression rouge.
Théoriquement, tant que le code JS de ce script peut être injecté dans la page, le plug-in Grease Monkey est utilisé pour injecter le code JS dans la page.
Le plugin Grease Monkey peut être installé depuis le Chrome Store :
https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo
Si vous ne parvenez pas à contourner le mur, vous pouvez rechercher « Tampermonkey » sur Baidu pour trouver un site Web tiers à télécharger. Cependant, veillez à ne pas installer de faux plug-ins malveillants. Il est recommandé de l'installer à partir du site officiel. magasin.
D'autres outils sont également disponibles, à condition que le code JS de ce script puisse être injecté en haut de la page pour exécution.
Vous pouvez installer le script Grease Monkey depuis la boutique officielle, ou vous pouvez copier le code et le créer localement.
Cette méthode est recommandée. Le script Oil Monkey installé depuis le Oil Monkey Store peut être automatiquement mis à jour lors de la mise à jour des versions ultérieures. Ce script a été mis sur le Oil Monkey Store :
https://greasyfork.org/zh-CN/scripts/419781-js-cookie-monitor-debugger-hook
Si vous trouvez les mises à jour automatiques trop ennuyeuses, ou si vous avez d'autres soucis, vous pouvez copier le code de ce script ici :
https://github.com/CC11001100/js-cookie-monitor-debugger-hook/blob/main/js-cookie-monitor-debugger-hook.js
Après avoir examiné et confirmé qu'il n'y a pas de problème, vous pouvez l'ajouter dans le panneau de gestion d'Oil Monkey.
Notez que le suivi consiste à avoir une compréhension globale au niveau macro, et non à localiser des détails (généralement, l'utilisation correcte des outils peut améliorer l'efficacité. Bien sûr, les connaissances d'une personne sont limitées et chacun est invité à donner son avis sur des moyens plus intéressants de le faire). play), par exemple lors de l'ouverture d'une page :
Sur la base de cette image, nous pouvons avoir une idée générale des cookies de ce site Web exploités par JS, du moment et de la manière dont ils sont exploités.
Un autre exemple consiste à utiliser un moniteur pour observer l'évolution des cookies. Par exemple, sur cette page, vous pouvez voir en fonction de l'heure à laquelle ce cookie sera modifié toutes les demi-minutes :
(2021-1-7 18:27:49 mise à jour v0.4 pour ajouter cette fonctionnalité) : S'il y a trop d'informations imprimées par la console, vous pouvez utiliser le filtrage fourni avec le navigateur Chrome pour filtrer le format de. les journaux imprimés ont été unifiés, il suffit juste cookieName = Cookie名字, par exemple :
Veuillez noter que lors de la recherche, assurez-vous que vos informations de recherche sont décodées en URL, sinon elles risquent de ne pas correspondre, car les informations d'impression de la console sont d'abord décodées en URL puis imprimées.
Si vous ne savez pas si le cookie que vous souhaitez définir est généré localement ou renvoyé par un serveur demandeur set-cookie , vous pouvez ouvrir ce script, actualiser la page du site Web cible, puis rechercher le nom du cookie dans la console. La méthode est la même que ci-dessus. Cette section est similaire Lorsque le nom du cookie est court et non distinctif, vous pouvez ajouter cookieName pour faciliter le positionnement, par exemple :
cookieName = v
Parfois, le site Web cible peut définir un cookie à plusieurs reprises avec la même valeur. Cette variable est utilisée pour ignorer de tels événements :
En règle générale, conservez simplement la valeur par défaut.
@since v0.6 Cette partie du document s'applique à la version v0.6+ Si votre version locale est inférieure à 0.6, veuillez mettre à niveau la version avant de lire le document.
À partir de la version 0.6, les points de rupture lorsque la valeur du cookie change sont devenus très compliqués, et c'est également devenu très simple. La complexité est due à l'introduction du mécanisme d'événement, et la simplicité est due au fait que la configuration des règles de point d'arrêt est simplifiée. et plus souple.
Les règles de point d'arrêt peuvent être divisées en标准规则et简化规则. Les règles standard sont destinées à une mise en œuvre et à un traitement faciles au bas du programme. Les règles simplifiées permettent aux utilisateurs de les configurer plus facilement. Dans des circonstances normales, il vous suffit de comprendre les règles simplifiées. Lorsque la configuration des règles simplifiées ne peut pas Revenez pour voir comment configurer les règles standard lorsque vos besoins sont satisfaits.
Toutes les règles sont configurées dans le tableau debuggerRules et il y a une variable en tête du script :
Si vous ne la trouvez pas, vous pouvez appuyer sur Ctrl+F pour effectuer une recherche par nom de variable :
debuggerRulesCette variable est de type tableau, qui stocke certaines conditions de règle pour déterminer dans quelles circonstances le point d'arrêt sera saisi.
Notez qu'il s'agit d'un tableau et que les règles du tableau sont dans une relation OU. Lorsque l'événement de modification du cookie est déclenché, chaque règle sera mise en correspondance séquentiellement. Tant qu'une règle est mise en correspondance avec succès, un point d'arrêt sera saisi.
Entrez un point d'arrêt lorsque le cookie nommé foo change :
const debuggerRules = [ "foo" ] ;Spécifier une chaîne de la manière ci-dessus correspondra au nom du cookie s'il est égal à la chaîne donnée.
Notez que s'il existe ici une partie de la correspondance exacte codée en URL, elle doit d'abord être décodée en URL, puis collée ici. Les autres endroits impliquant des chaînes sont les mêmes et ne seront pas décrits à nouveau.
Si le nom du cookie contient une partie en constante évolution, telle que l'horodatage, l'UUID, etc., qui ne peut pas être localisée par son nom, alors une correspondance régulière est utilisée :
const debuggerRules = [ / foo.+ / ] ;Dans la plupart des cas, seules ces deux configurations suffisent.
Pratiquons-le maintenant. En ouvrant cette page.
https://www.ishumei.com/trial/captcha.html
Vous pouvez voir que le script a détecté certaines opérations de cookies :
L'un d'eux, smidV2 est suspect, nous lui ajoutons donc un point d'arrêt :
Après avoir modifié debuggerRules , assurez-vous d'appuyer sur Ctrl+S pour enregistrer le script. Étant donné qu'Oil Monkey injecte le code JS lorsque la page est chargée, vous devez actualiser la page et la réinjecter. le point d'arrêt sera automatiquement saisi :
Dans la case rouge A de l'image ci-dessus se trouvent quelques variables spécialement transmises. En déplaçant la souris sur ces variables pour afficher les valeurs, nous pouvons connaître approximativement certaines conditions du point d'arrêt actuel :
Ensuite, il y a la case rouge B. Nous définissons le point d'arrêt du cookie pour suivre la pile d'appels et localiser l'endroit où le cookie est généré. La case rouge est la pile d'appels de ce script. Il y a un logo userscript.html clair. cette partie de la pile d'appels.
Suivez ensuite la pile d'appels et vous pourrez voir où le cookie est défini :
Bien sûr, il est inutile que nous examinions cette pile. Ce que nous devons faire, c'est avancer progressivement jusqu'à ce que nous localisions l'endroit où le cookie est réellement généré. Cependant, ce script ne peut que vous aider à définir un point d'arrêt. des étoiles et de la mer en dépendra plus tard. Vous-même !
Entrez un point d'arrêt lorsque le cookie nommé foo est添加 :
const debuggerRules = [ { "add" : "foo" } ] ; Entrez un point d'arrêt lorsque le cookie nommé foo est删除 :
const debuggerRules = [ { "delete" : "foo" } ] ; Entrez un point d'arrêt lorsque le cookie nommé foo existe déjà mais que la valeur est更新 :
const debuggerRules = [ { "update" : "foo" } ] ; Plusieurs conditions peuvent être spécifiées en même temps, et des points d'arrêt sont saisis lors添加和更新, ce qui équivaut à exclure les suppressions :
const debuggerRules = [ { "add|update" : "foo" } ] ;Des chaînes ou des expressions régulières peuvent être utilisées partout où une correspondance de nom de cookie est impliquée :
const debuggerRules = [ { "add" : / foo_d+ / } ] ; Les règles simplifiées ci-dessus seront converties en règles standard. Vous pouvez également configurer des règles standard directement dans debuggerRules . Le format d'une règle standard est :
{
"events": "{add|delete|update}",
"name": {"cookie-name" | /cookie-name-regex/},
"value": {"cookie-value" | /cookie-value-regex/}
}
Type de chaîne, indiquant le type d'événement correspondant à cette règle. Il | s'agir d'un seul événement, tel que add , ou de plusieurs événements, tels que add|update . Si vous vous sentez encombré, vous pouvez également ajouter | Ajoutez des espaces des deux côtés, par exemple add | update Lorsque le type d'événement est configuré, il correspondra uniquement au type d'événement donné. Lorsque cette option n'est pas configurée, tous les types d'événements seront mis en correspondance par défaut.
Il peut s'agir d'une chaîne ou d'un modèle régulier. C'est vrai lorsque le nom du cookie correspond à la chaîne ou au modèle régulier donné. Cet élément ne peut pas être ignoré et doit être configuré.
Il peut s'agir d'une chaîne ou d'un modèle régulier. Cette règle est vraie lorsque la valeur du cookie correspond à la chaîne ou au modèle régulier donné. Elle n'a pas besoin d'être configurée. Si elle n'est pas configurée, cette option sera ignorée.
La configuration des règles de point d'arrêt a été introduite précédemment et les types d'événements ont été mentionnés à plusieurs reprises. Nous ne connaissons que la chaîne du nom correspondant à chaque événement, mais nous ne savons toujours pas ce que signifie chaque événement au niveau inférieur. événement. Mécanisme de réalisation d’un événement.
Les modifications des cookies sont subdivisées en ajout de cookies, suppression de cookies et mise à jour des valeurs de cookies existantes. Chaque événement correspond à un nom d'événement :
Le cookie n'existait pas localement auparavant et c'est la première fois qu'il est ajouté. Il se peut que ce soit la première fois que vous visitez ce site Web, ou que vous effaciez les cookies et visitez à nouveau, ou qu'un nouveau cookie soit généré à chaque fois que vous visitez le site Web, ou il se peut même que le propre code du site Web supprime les cookies et les rajoute. eux, ce qui déclenchera l’événement d’ajout de cookies.
Par exemple, exécutez le code suivant Afin de garantir que le cookie n'existe pas auparavant, un horodatage est ajouté au nom du cookie :
document . cookie = "foo_" + new Date ( ) . getTime ( ) + "=bar; expires=Fri, 31 Dec 9999 23:59:59 GMT; path=/" ;Lorsque nous exécutons cette ligne de code dans la console, l'événement Cookie Add sera déclenché :
Lorsqu'un cookie existe déjà localement et que vous essayez de lui définir une valeur, l'événement de mise à jour du cookie sera déclenché.
Par exemple, le code suivant :
document . cookie = "foo_10086=blabla; expires=Fri, 31 Dec 9999 23:59:59 GMT; path=/" ;
document . cookie = "foo_10086=wuawua; expires=Fri, 31 Dec 9999 23:59:59 GMT; path=/" ;La première instruction pour définir Cookie déclenchera l'événement Cookie New, et la deuxième instruction pour définir Cookie déclenchera l'événement Cookie Update car le Cookie à définir existe déjà.
Si le développeur front-end indique une expiration plus tôt que l'heure actuelle lors de la configuration du cookie, cela signifie que le cookie doit être supprimé. Par exemple, une manière courante de supprimer les cookies est la suivante :
const expires = new Date ( new Date ( ) . getTime ( ) - 1000 * 30 ) . toGMTString ( ) ;
document . cookie = "foo=; expires=" + expires + "; path=/"Lorsque nous exécutons ce code dans la console, l'événement de suppression de cookie sera déclenché :
Il ressort également de ce qui précède que le déclenchement de l'événement de suppression de cookie sert uniquement à détecter les expirations et ne vérifiera pas réellement si le cookie existait auparavant.
Comme mentionné précédemment, il existe un type d'événement lors de la configuration des règles de point d'arrêt des cookies. En fait, chaque type d'événement correspond à un bit indicateur indiquant si le point d'arrêt de ce type d'événement est activé. La priorité de ce bit indicateur est par exemple la plus élevée. , si ce n'est pas le cas. Lorsque le point d'arrêt de suppression de cookie est activé et qu'un événement de suppression de cookie est déclenché, il vérifiera d'abord si le point d'arrêt de suppression de cookie est activé. S'il est désactivé, l'événement sera ignoré et aucune autre tentative ne sera effectuée. être fait pour correspondre aux règles de point d'arrêt (contrôlé par les outils de développement) Le journal de cet événement de suppression sera toujours imprimé sur la plateforme).
Alors maintenant, la situation est devenue très compliquée. Passons en revue le processus de ce petit point d'arrêt des cookies :
Par défaut, seuls les points d'arrêt pour les événements d'ajout de Cookie et les événements de modification de Cookie sont activés :
Parce que dans des circonstances normales, l'ajout de cookies et la mise à jour des cookies peuvent être confondus. Ils attribuent tous deux une valeur au cookie. Dans la plupart des cas, nous ne prêterons pas attention à l'événement de suppression du cookie, c'est donc ainsi qu'il est défini ici. Si cela ne répond pas à vos besoins, si nécessaire, vous pouvez modifier vous-même la valeur correspondante de enableEventDebugger .
Si vous rencontrez des problèmes lors de l'utilisation, vous pouvez fournir des commentaires dans Issues sur GitHub, vous pouvez également fournir des commentaires dans la zone de commentaires de Grease Monkey Script, ou vous pouvez m'envoyer un e-mail, et je m'en occuperai dès que possible. possible après l'avoir vu.
A partir de la version v0.6, une variable a été ajoutée pour ajuster la taille de la police du log imprimé par ce script sur la console, en px :
Au fur et à mesure des itérations de la version, il se peut qu'il ne se trouve plus à cet emplacement. Si vous ne le trouvez pas immédiatement, recherchez dans le code :
consoleLogFontSizeModifiez ensuite la valeur de cette variable.
Ou comme autre solution, vous pouvez maintenir la touche Ctrl+molette de la souris enfoncée dans la console des outils de développement pour zoomer et ajuster la taille globale. Il s'agit d'une fonction fournie avec le navigateur Chrome.
Comme expliqué au début de cet article, ce script doit être injecté avec succès au début de la page et exécuté avant que le Hook puisse réussir. Pour la page entière similaire à la première couche de l'accélérateur, un seul script est renvoyé. la logique à l'intérieur :
< script >
document . cookie = 这里是一些奇奇怪怪的JS用于计算出Cookie ;
location . href = "跳转走了" ;
</ script >Le cookie est défini et redirigé vers une nouvelle page immédiatement. Pour cette opération, le Hook peut ne pas être disponible. Il s'agit d'un problème avec le script Grease Monkey. Si vous insistez sur le Hooking, vous pouvez utiliser un proxy suspendu pour injecter ce script dans. cette URL. En-tête de réponse.
Ci-dessous cette page se trouve un résumé de quelques exemples pratiques de rétro-ingénierie utilisant ce script :
Cliquez sur moi pour accéder à la page de navigation
Ce projet est séparé de : https://github.com/CC11001100/crawler-js-hook-framework-public/tree/master/001-cookie-hook#%E7%9B%91%E6%8E%A7%E5 %AE%9A%E4%BD%8Djavascript%E6%93%8D%E4%BD%9Cookie
Après avoir modifié l'espace de noms, le nombre d'installations peut être effacé. J'ai pris une capture d'écran pour le commémorer. À partir de maintenant (2022-7-29 21:40:01), le nombre d'installations a dépassé 300. On dirait que c'est le cas. très grand pour un petit outil dans un champ aussi étroit Ce n'est plus facile...
Merci aux internautes enthousiastes pour leurs commentaires, merci pour votre soutien.
js-cookie-monitor-debugger-hook a désormais rejoint le projet 404 Star Chain
Scannez le code QR pour rejoindre le groupe d'échange de technologies inversées :
Si le code QR du groupe expire, vous pouvez m'ajouter sur WeChat personnel et envoyer [Reverse Group] pour vous rejoindre dans le groupe :
Cliquez ici ou scannez le QR code pour rejoindre le groupe d'échange TG :
