js cookie monitor debugger hook
v0.11
GitHub リポジトリ: https://github.com/JSREI/js-cookie-monitor-debugger-hook
簡体字中国語 |
データが貴重な時代において、クローラーとアンチクローラーの間の対立は激化しています。Cookie アンチクローラーは、Web サイトが JS コードを使用して Cookie を設定する最常见之一あり、母親ですらそうしているのです。認識されない (通常はブラウジング時) サーバーのフィンガープリント、リクエストを行う際に取得する必要がある Cookie など)、リクエストに直面した際に取得する必要があるが、どこで生成されたか不明な Cookie、あなたは、母親が認識していない何万行もの JS の紛らわしい行の中で、Cookie が生成される場所を見つけようと悪戦苦闘しています (逆の考え方が非科学的であれば、何度か窒息するかもしれません...)。何度か見つけたいと思っているのですが、自分を騙して諦めさせようとしていますか、それとも Selenium のようなブラウザ エミュレーション方法を使用してみてはいかがでしょうか? あなたが臆病なら、このスクリプトが役に立ちます。 (あなたも私も、この段落がこのシーンを裏付ける単なるナンセンスであることは知っています。残念ながら最後まで読み終えられない場合は、飛ばしても構いません...)
このスクリプトの機能は大きく 2 つの部分に分かれています。
このスクリプトは、独自の JS コードをページに挿入し、 document.cookieをフックしてさまざまな機能を実行します。そのため、このスクリプトを使用する前に、生成される Cookie が実際に JS を通じて生成されたものであることを確認する必要があります (非常に特別な方法は後ほど紹介します)。 Cookie が JS によって生成されたか、サーバーによって返されたかを判断するだけです)。
現時点では、多くのフック スクリプトのフック姿勢が正しくありません。このスクリプトは 1 回限りのフックを繰り返し使用しますが、ブラウザの組み込み Cookie 管理には影響しません。
Cookie ブレークポイント機能に加えて、よりマクロな観点からページ上の Cookie を分析できる Cookie 変更監視機能が追加されました。
(忘れてください、コーディングを諦めてください...)
色は操作の種類を区別するために使用されます。
各操作の後にはコードの場所が表示されます。クリックすると、操作を実行した JS コードの場所が表示されます。
v0.6 からは、より強力な機能とより柔軟な構成を備えたブレークポイント ルールが導入され、Cookie の変更を 3 つのイベント (追加、削除、更新) に細分化するイベント メカニズムが導入され、より詳細なブレークポイントがサポートされています。 Cookie イベントの詳細については、この記事のパート 5 を参照してください。
なぜこのように設計されているのでしょうか? 比較的一般的な状況は、ターゲット Web サイト上のクロール防止 Cookie が JS によって設定されている場合ですが、JS コードのロジックでは、最初にそれを必死に削除し、実際の値を追加する前に何度も削除します。この方法により、一般的な Cookie フックのデバッグに正確に対処できます。
F5 の Cookie 保護などの 1 つの例を次に示します。Cookie TS51c47c46075は、何度も削除されてから再度追加されます。
この場合、赤色の削除イベントの混乱を避けるために、 TS51c47c46075という名前のCookie イベントにブレークポイントを設定できます。
理論的には、このスクリプトの JS コードをページに挿入できる限り、Grease Monkey プラグインを使用して JS コードをページに挿入します。
Grease Monkey プラグインは Chrome ストアからインストールできます。
https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo
壁を回避できない場合は、Baidu で「Tampermonkey」を検索してサードパーティの Web サイトを見つけてダウンロードできます。ただし、偽の悪意のあるプラグインをインストールしないように注意してください。公式ストアからインストールすることをお勧めします。
このスクリプトの JS コードをページの上部に挿入して実行できる限り、他のツールも使用できます。
Grease Monkey スクリプトは公式ストアからインストールすることも、コードをコピーしてローカルに作成することもできます。
この方法をお勧めします。Oil Monkey ストアからインストールされた Oil Monkey スクリプトは、後続のバージョンが更新されると自動的に更新されます。
https://greasyfork.org/zh-CN/scripts/419781-js-cookie-monitor-debugger-hook
自動更新が煩わしい場合、またはその他の懸念がある場合は、このスクリプトのコードをここにコピーできます。
https://github.com/CC11001100/js-cookie-monitor-debugger-hook/blob/main/js-cookie-monitor-debugger-hook.js
検討して問題がないことを確認したら、Oil Monkeyの管理パネルに追加できます。
モニタリングとはマクロ レベルで全体を理解することであり、詳細を特定することではないことに注意してください (通常、ツールを正しく使用すると効率が向上します。もちろん、人の知識には限界があるため、より興味深い方法についてフィードバックを提供することは誰でも歓迎されます) play) 、たとえばページを開いたとき:
この図に基づいて、この Web サイトのどの Cookie が JS によって操作され、いつ、どのように操作されるかを大まかに理解できます。
もう 1 つの例は、モニターを使用して Cookie の変化パターンを観察することです。たとえば、このページでは、Cookie が 30 分ごとに変更される時間を確認できます。
(2021-1-7 18:27:49 v0.4 を更新してこの機能を追加しました): コンソールに表示される情報が多すぎる場合は、Chrome ブラウザーに付属のフィルタリングを使用してフィルタリングできます。出力されるログは統合されており、 cookieName = Cookie名字のみが必要です。例:
検索するときは、検索情報が URL デコードされていることを確認してください。そうしないと、コンソールの印刷情報が URL デコードされてから印刷されるため、一致しない可能性があります。
設定する Cookie がローカルで生成されたものであるか、要求元のサーバーset-cookieによって返されたものであるかが不明な場合は、このスクリプトを開いてターゲット Web サイトのページを更新し、コンソールで Cookie 名を検索します。この方法は上記と同じです。Cookie の名前が短くて特徴的でない場合は、次のようにcookieNameを追加します。
cookieName = v
場合によっては、ターゲット Web サイトが同じ値を使用して Cookie を繰り返し設定することがあります。この変数は、そのようなイベントを無視するために使用されます。
通常は、デフォルトのままにしてください。
@since v0.6ドキュメントのこの部分は v0.6 以降のバージョンに適用されます。ローカル バージョンが 0.6 未満の場合は、ドキュメントを読む前にバージョンをアップグレードしてください。
v0.6 から Cookie の値が変化したときのブレークポイントは非常に複雑になりましたが、複雑になったのはイベント機構の導入によるもので、簡単になったのはブレークポイントのルール設定が簡略化されたためです。そしてより柔軟に。
ブレークポイント ルールは、标准规则と简化规则に分けられます。標準ルールは、プログラムの下部で簡単に実装および処理するためのものです。通常は、簡易ルールを理解するだけで済みます。簡素化されたルール構成ができない場合 ニーズが満たされた場合に、標準ルールを構成する方法をもう一度確認してください。
すべてのルールはdebuggerRules配列で構成され、スクリプトの先頭に変数があります。
見つからない場合は、Ctrl+F を押して変数の名前で検索できます。
debuggerRulesこの変数は配列タイプで、どのような状況でブレークポイントに入るかを決定するためのいくつかのルール条件を格納します。
これは配列であり、配列内のルールは OR 関係にあることに注意してください。Cookie 変更イベントがトリガーされると、1 つのルールが正常に一致する限り、各ルールが順番に照合されます。
fooという名前の Cookie が変更されたときにブレークポイントを入力します。
const debuggerRules = [ "foo" ] ;上記の方法で文字列を指定すると、指定された文字列と等しい場合に Cookie 名と一致します。
ここに完全一致の URL エンコードされた部分がある場合は、最初に URL デコードしてからここに貼り付ける必要があることに注意してください。文字列が関係する他の場所も同じであるため、再度説明しません。
Cookie の名前に、タイムスタンプや UUID など、名前では特定できない、常に変化する部分が含まれている場合は、通常の一致が使用されます。
const debuggerRules = [ / foo.+ / ] ;ほとんどの場合、これら 2 つの構成だけで十分です。
このページを開いたらさっそく練習してみましょう。
https://www.ishumei.com/trial/captcha.html
スクリプトがいくつかの Cookie 操作を検出したことがわかります。
そのうちの 1 つであるsmidV2は疑わしいため、ブレークポイントを追加します。
debuggerRules配列を変更した後は、必ず Ctrl+S を押してスクリプトを保存してください。Oil Monkey はページのロード時に JS コードを挿入するため、ページを更新して再挿入する必要があります。ブレークポイントは自動的に入力されます。
上の図の赤いボックス A には、特別に渡された変数がいくつかあります。これらの変数の上にマウスを移動して値を表示すると、現在のブレークポイントの条件を大まかに知ることができます。
次に、赤いボックス B があります。呼び出しスタックを追跡し、Cookie が生成される場所を特定するために Cookie ブレークポイントを設定します。赤いボックスは、明確なuserscript.htmlロゴがあります。無視してください。呼び出しスタックのこの部分。
次に、呼び出しスタックをトレースすると、Cookie が設定されている場所を確認できます。
もちろん、このスタックを調べても意味はありません。実際に Cookie が生成される場所を特定するまで、徐々に先に進む必要があります。ただし、このスクリプトはブレークポイントを設定するのに役立つだけです。星と海は後はあなた次第です。
fooという名前の Cookie が添加ときにブレークポイントを入力します。
const debuggerRules = [ { "add" : "foo" } ] ; fooという名前の Cookie が删除ときにブレークポイントを入力します。
const debuggerRules = [ { "delete" : "foo" } ] ; fooという名前の Cookie がすでに存在するが、値が更新場合は、ブレークポイントを入力します。
const debuggerRules = [ { "update" : "foo" } ] ;複数の条件を同時に指定でき、添加和更新時にブレークポイントが入力されます。これは削除を除外するのと同じです。
const debuggerRules = [ { "add|update" : "foo" } ] ;Cookie 名の照合が関係する場合はどこでも、文字列または正規表現を使用できます。
const debuggerRules = [ { "add" : / foo_d+ / } ] ;上記の簡略化されたルールは標準ルールに変換されます。標準ルールをdebuggerRules配列で直接構成することもできます。
{
"events": "{add|delete|update}",
"name": {"cookie-name" | /cookie-name-regex/},
"value": {"cookie-value" | /cookie-value-regex/}
}
このルールに一致するイベント タイプを示す文字列タイプ。 addなどの単一のイベント、または add | add|updateなどの複数のイベントを区切る|もできます。 add | updateイベント タイプが設定されている場合、このオプションが設定されていない場合は、すべてのイベント タイプが一致します。
文字列または通常のパターンを指定できます。Cookie 名が指定された文字列または通常のパターンに一致する場合、この項目は無視できないため、設定する必要があります。
Cookie 値が指定された文字列または通常のパターンに一致する場合、このルールは true になります。設定しない場合、このオプションは無視されます。
ブレークポイント ルールの構成については以前に紹介しましたが、イベントの種類については各イベントに対応する名前の文字列だけがわかっていますが、各イベントが下位レベルで何を意味するのかはまだわかりません。イベントの実現メカニズム。
Cookie の変更は、Cookie の追加、Cookie の削除、および既存の Cookie 値の更新に分類されます。各イベントはイベント名に対応します。
この Cookie は以前はローカルに存在せず、追加されたのは今回が初めてです。 この Web サイトに初めてアクセスする場合もあれば、Cookie をクリアして再度アクセスする場合もあり、Web サイトにアクセスするたびに新しい Cookie が生成される場合もあれば、Web サイト自体のコードが Cookie を削除して再追加する場合もあります。これにより、Cookie の追加イベントがトリガーされます。
たとえば、次のコードを実行して、Cookie が以前に存在していないことを確認するために、Cookie の名前にタイムスタンプが追加されます。
document . cookie = "foo_" + new Date ( ) . getTime ( ) + "=bar; expires=Fri, 31 Dec 9999 23:59:59 GMT; path=/" ;コンソールでこのコード行を実行すると、Cookie Add イベントがトリガーされます。
Cookie がローカルにすでに存在し、その値を設定しようとすると、Update Cookie イベントがトリガーされます。
たとえば、次のコード:
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=/" ;Cookie を設定する最初のステートメントは Cookie New イベントをトリガーし、Cookie を設定する 2 番目のステートメントは、設定する Cookie が既に存在するため、Cookie Update イベントをトリガーします。
フロントエンド開発者が Cookie を設定するときに現在時刻よりも早い期限を設定した場合、Cookie を削除する必要があることを意味します。たとえば、Cookie を削除する一般的な方法は次のとおりです。
const expires = new Date ( new Date ( ) . getTime ( ) - 1000 * 30 ) . toGMTString ( ) ;
document . cookie = "foo=; expires=" + expires + "; path=/"このコードをコンソールで実行すると、Cookie 削除イベントがトリガーされます。
また、上記のことから、Cookie 削除イベントのトリガーは純粋に期限切れを検出するためであり、Cookie が以前に存在したかどうかを実際にチェックするわけではないこともわかります。
前述したように、Cookie ブレークポイント ルールを構成する場合、各イベント タイプは、このイベント タイプのブレークポイントがオンになっているかどうかを示すフラグ ビットに対応します。たとえば、このフラグ ビットの優先順位が最も高くなります。そうでない場合 Cookie 削除ブレークポイントがオンになっていて Cookie 削除イベントがトリガーされると、最初に Cookie 削除ブレークポイントがオンになっているかどうかがチェックされます。オフになっている場合、イベントは無視され、それ以上の試行は行われません。ブレークポイント ルールに一致するように作成されます (開発者ツールによって制御されます)。この削除イベントのログは引き続きプラットフォームに出力されます)。
さて、状況は非常に複雑になってきました。この小さな Cookie ブレークポイントのプロセスを見てみましょう。
デフォルトでは、Cookie 追加イベントと Cookie 変更イベントのブレークポイントのみが有効になっています。
通常の状況では、Cookie の追加と Cookie の更新は混同される可能性があり、両方とも Cookie に値を割り当てるため、ほとんどの場合、Cookie が削除されるイベントには注意を払わないため、ここではこのように設定されています。ニーズを満たさない場合 必要に応じて、 enableEventDebuggerの対応する値を自分で変更できます。
使用中に問題が発生した場合は、GitHub のIssuesにフィードバックを提供していただくか、Grease Monkey Script のコメント エリアにフィードバックを提供していただくか、私にメールを送っていただければ、できるだけ早く対応させていただきます。見た後なら可能です。
バージョン v0.6 以降、このスクリプトによってコンソールに出力されるログのフォント サイズを px 単位で調整するための変数が追加されました。
バージョンが繰り返されると、この場所に存在しなくなる可能性があります。すぐに見つからない場合は、コード内を検索してください。
consoleLogFontSize次に、この変数の値を変更します。
または、別の解決策として、開発者ツール コンソールで Ctrl キーを押しながらマウス ホイールを押して全体のサイズを調整することもできます。これは Chrome ブラウザーに付属している機能です。
この記事の冒頭で説明したように、フックが成功する前に、このスクリプトがページの先頭に正常に挿入され、実行される必要があります。アクセラレータの最初の層と同様に、このスクリプトは 1 つだけ返されます。内部のロジック:
< script >
document . cookie = 这里是一些奇奇怪怪的JS用于计算出Cookie ;
location . href = "跳转走了" ;
</ script >この操作では、Cookie が設定され、すぐに新しいページにリダイレクトされます。これは、Grease Monkey スクリプトの問題です。フックを使用する場合は、このスクリプトを挿入することができます。この URL ヘッダー。
このページの下には、このスクリプトを使用したリバース エンジニアリングの実践例の概要が示されています。
「私」をクリックしてナビゲーションページに入ります
このプロジェクトは、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
ネームスペース変更したらインストール数がクリアされたかも知れません 記念にスクショ撮ってみました 現時点(2022-7-29 21:40:01)でインストール数が300を超えたような気がします。このような狭いフィールドでの小さなツールとしては非常に大きいです。これはもう簡単ではありません...
フィードバックを寄せてくださった熱心なネチズンの皆様、ご支援に感謝いたします。
js-cookie-monitor-debugger-hook が 404 Star Chain プロジェクトに参加しました
QR コードをスキャンして、リバース テクノロジー交換グループに参加します。
グループ QR コードの有効期限が切れた場合は、個人 WeChat に私を追加し、[グループを反転] を送信してグループに参加させることができます。
ここをクリックするか、QR コードをスキャンして TG コミュニケーション グループに参加してください。
