講義22：キャプチャアンチクローラーの基本原則

Webサイトを閲覧すると、さまざまな確認コードが表示されることがよくあります。ほとんどの場合、これらの確認コードはアカウントへのログイン時に表示され、ページにアクセスするプロセスでも表示される場合があります。厳密には、これらの動作すべては、確認コードの爬虫類として数えられます。

このレッスンでは、検証コードの抗爬虫類の基本原則と一般的な検証コードとソリューションを紹介します。

検証コード

検証コードの完全な名前は、Computers and Humans Apartに伝えるためのCompletely Automated Public Turing testと呼ばれます。これは、コンピューターと人間を区別するための完全自動のTuringテストを意味します。キーワードの最初の文字を取得すると、CAPTCHAになります。ユーザーがコンピュータであるか人間であるかを区別する公的な全自動プログラム。

それは何のため？もちろん、次のような多くの用途があります。

ウェブサイトの登録時に確認コードを追加すると、悪意のある大量登録をある程度防ぐことができます。
Webサイトにログインするときに確認コードを追加すると、悪意のあるパスワードのブラストをある程度防ぐことができます。
ウェブサイトにコメントを投稿するときに確認コードを追加すると、悪意のある灌漑をある程度防ぐことができます。
投票時に確認コードがWebサイトに追加されるため、悪意のある投票のスワイプをある程度防ぐことができます。
Webサイトが頻繁にアクセスされる場合、または閲覧動作が異常な場合、一般にクローラーに遭遇する可能性があり、それによってクローラーのクロールがある程度妨げられる可能性があります。

一般的に、上記の動作は、検証コードのクローラー防止動作と呼ばれます。検証コードを使用すると、プログラムでシミュレートできるさまざまな動作を防止できます。検証コードを使用すると、完全に自動化したい場合に問題が発生しますが、問題の大きさは、検証コードの解読の難しさに依存します。

確認コードクローラー

では、なぜ確認コードが表示されるのですか？ほとんどの場合、これはWebサイトへの頻繁なアクセスや異常な動作、または特定の自動化されたアクションを直接制限するためです。次のように分類されます。

ログインや登録などの多くの場合、これらの確認コードはほとんど不可避です。その目的は、悪意のある登録や悪意のあるブラストを制限することです。これは、クライミング防止の手段でもあります。
一部のウェブサイトで過度に頻繁な動作が発生すると、ログインウィンドウが直接ポップアップ表示され、ログインを続行するようにログインが求められる場合があります。現時点では、確認コードはログインフォームに直接バインドされており、例外が検出されたものとしてカウントされます。アンチクライムに強制ログインを使用します。
より一般的なWebサイトの一部でアクセス頻度が少し高い状況が発生した場合、確認コードが自動的にポップアップし、ユーザーが識別および送信して、現在Webサイトにアクセスしている人が実在の人物であることを確認します。これは、一部のマシンの動作を制限し、アンチ爬虫類。
これらの状況は、プログラムの一部の自動化された動作をある程度制限する可能性があるため、それらすべてをアンチクローラーと呼ぶことができます。

検証コードアンチクローラーの原理

モジュール1では、セッションの基本概念について既に説明しました。これはサーバー側に存在し、現在のユーザーのセッション情報を保存するために使用されます。この情報は、確認コードのメカニズムにとって非常に重要です。

サーバーは、Sessionオブジェクトにいくつかの値を保存できます。たとえば、4桁のグラフィック検証コード1234などのグラフィック検証コードを生成したいとします。

まず、クライアントは確認コードを表示する必要があり、この確認コードに関連する情報はサーバーから取得する必要があります。たとえば、確認コードを生成するためにこのインターフェースを要求する場合、コンテンツ1234でグラフィック確認コードを生成する必要があります。このとき、サーバーは4つの数値1234をSessionオブジェクトに保存し、1234の結果をクライアントに返します。または、生成された検証コードグラフィックを直接返すこともできます。クライアントがそれを提示し、ユーザーは検証コードの内容を確認できます。

ユーザーは確認コードを確認した後、フォームに確認コードの内容を入力します。送信ボタンをクリックすると、情報がサーバーに再度送信され、サーバーは送信された情報とセッションに保存された確認コード情報に進みます逆に、同じ場合は、検証コードが正しく入力され、検証が成功した後、解放されて通常の状態に戻ります。一貫性がない場合は、検証が失敗したことを意味し、検証は続行されます。

現在、市場に出ているほとんどの検証コードはこのメカニズムに基づいて実装されており、次のように分類されています。

グラフィック検証コードの場合、サーバーはグラフィックのコンテンツをセッションに保存し、検証コードの画像を返すか、クライアント自体に表示し、セッション内の検証コードの値と、ユーザーがフォームを送信した後にユーザーが送信した値を検証します。
動作検証コードの場合、サーバーはいくつかの計算を行い、いくつかのキー、トークン、およびその他の情報をセッションに格納します。ユーザーは最初にクライアントの検証を完了する必要があります。検証が成功した場合、フォームを送信できます。クライアントの検証が完了すると、クライアントは端末は、検証後に計算されたキー、トークン、コード、およびその他の情報をサーバーに送信し、サーバーは別の検証を実行します。サーバーも検証に合格した場合、それは実際の合格と見なされます。
携帯電話の確認コードの場合、サーバーは事前に確認コード情報を生成し、確認コードの結果と送信する携帯電話番号をSMS送信サービスプロバイダーに送信し、サービスプロバイダーにユーザーとユーザーに確認コードを発行させます。このコードはサーバーに送信され、サーバーはセッションの検証コードが送信された検証コードと一致するかどうかを判断します。

原則が基本的に同じである他の多くの検証コードがあります。

一般的な確認コード

市場に出回っているいくつかの一般的な検証コードを見て、いくつかの識別のアイデアを簡単に紹介しましょう。

キャプチャ

最も基本的な検証コードは、下の図のようなグラフィック検証コードです。
ここに画像の説明を挿入
一般的に言えば、いくつかの認識のアイデアがあります：

TesserocrなどのライブラリなどのOCR認識を使用するか、BaiduやTencentなどのOCRインターフェースを直接呼び出すと、Tesserocrよりも認識効果が高くなります。
コーディングプラットフォームは、検証コードをコーディングプラットフォームに送信します。いくつかの強力な認識アルゴリズムがプラットフォームに実装されているか、プラットフォームの背後にいる誰かが認識を専門としています。これは、高速で安心です。
ディープラーニングトレーニングの場合、このタイプの検証コードは、CNNなどのディープラーニングモデルを使用して分類アルゴリズムをトレーニングすることもできますが、多くのタイプまたは異なる書き込み方法がある場合、認識精度にはある程度の影響があります。

動作確認コード

現在、非常に人気があると言える多くの種類の動作検証コードを確認できます。たとえば、Jiyan、Tencent、NetEase Shieldなどはすべて同様の検証コードサービスを備えており、スライドなどの多くの検証方法もあります。図のようにドラッグ、クリック、論理的判断など。
ここに画像の説明を挿入

推奨される識別スキームは次のとおりです。

コーディングプラットフォーム、その中の検証コードの多くは座標に関連しています。検証コードのスクリーンショットをコーディングプラットフォームに直接送信できます。コーディングプラットフォームの背後にいる誰かが対応する場所の座標を見つけるのを助けてくれます。場所の座標を取得した後に来ることができますシミュレート。現在のところ、シミュレーションには2つの方法があります。1つは動作をシミュレーションする方法で、Seleniumなどを使用して実装されます。シミュレーションが完了したら、通常はログインまたはセッションブロック状態のロックを解除して、有効なCookieを取得できます。もう1つは、JavaScriptレベルでシミュレーションすることですが、これは困難です。シミュレーション後、検証コードによって送信されたトークン値を直接取得できます。
深層学習では、いくつかの画像注釈や深層学習手法を使用して検証コードを特定することもできますが、実際には主に場所を特定することであり、場所をシミュレーションすることもできます。

SMS、スキャンコード検証コード

さらに、SMSやスキャンコードと同様の確認コードが発生する可能性があります。この操作はより面倒です。解決策は次のとおりです：

独自の携帯電話番号は必要ありません。一部のプラットフォームから取得できます。プラットフォームは、携帯電話のショートメッセージ送受信システムを維持し、電話番号を入力し、APIを介してSMS確認コードを取得します。
さらに、専門のコード受信機器を購入したり、SMSを監視するためのソフトウェアをインストールしたりすることもできます。携帯電話のSMS情報を特定のインターフェイス、テキスト、またはデータベースにエクスポートして抽出するメカニズムがあります。
スキャンコードの検証では、自分のアカウントが必要ない場合は、コードをコーディングプラットフォームに送信し、相手に自分のアカウントを使用してコードをスキャンさせることができますが、この場合はコードをカスタマイズする必要があり、プラットフォームと通信できます。その他の解決策は、関連するコンテンツのリバースとクラッキングを含みます。通常、携帯電話アプリのスキャンと解析のロジックをリバースしてからシミュレーションする必要があります。ここでは説明しません。

基本的に、確認コードは類似しており、一部は不完全ですが、基本的なカテゴリは大まかに分類できます。

上記では、検証コードの抗爬虫類の基本原則と検証コードの識別に関するいくつかのアイデアを紹介しました。次のクラスでは、コーディングプラットフォームとディープラーニングを使用して検証コードを特定する方法を紹介します。