サイトのWebスクレイピング：招待されていないゲストとその受信方法

5月末に開催された初めての完全仮想RIT ++イベントで、QratorLabsのエンジニアであるGeorgyTarasovは、人気のある言語であるWebスクレイピング（別名解析）について一般の人々に話しました。パフォーマンスの文字起こしを提供することにしました。出版物の最後のビデオ。







こんにちは！当社は長い間DDoS攻撃からの保護の問題に取り組んできましたが、この作業の過程で、ボットの作成の原則とその使用方法を研究するために、関連分野を十分に詳しく知ることができました。特に、Webスクレイピング、つまりボットを使用したWebリソースからの公開データの大量収集。



ある時点で、このトピックは、スクレーピングがうまく使用されるさまざまな適用された問題に私を魅了しました。ここで、Webスクレイピングの「ダークサイド」が私にとって最大の関心事であることに注意してください。つまり、Webスクレイピングの使用にとって有害で​​悪いシナリオであり、Webリソースとそれに関連するビジネスに悪影響を与える可能性があります。



同時に、私たちの仕事の詳細のために、ほとんどの場合、私たちが興味深い詳細を研究して、詳細に没頭しなければならないような（悪い）ケースでした。そして、これらのダイビングの結果、私の熱意は同僚に伝わりました。不要なボットを捕まえるためのソリューションを実装しましたが、十分なストーリーと観察結果が蓄積されており、興味深い資料になることを願っています。







私は以下について話します：

• なぜ人々はお互いを傷つけるのですか？
• そのような削り取りの種類と兆候は何ですか。
• ターゲットとするWebサイトにどのような影響がありますか。
• ボットの作成者がスクレイピングを行うために使用するツールと技術的機能。
• さまざまなカテゴリのボットを検出および認識する方法。
• スクレーパーがサイトにアクセスした場合の対処方法と対処方法（および何かを行う必要があるかどうか）。

無害な架空のシナリオから始めましょう-あなたが学生であり、明日の朝、タームペーパーの防御があり、資料に基づいて「馬が横になっていない」、数字、抜粋、引用がないことを想像してみましょう-そしてあなたは夜の残りの間それを理解しています時間もエネルギーも、この知識ベース全体を手動で突き抜けたいという欲求もありません。



したがって、古い仲間のアドバイスに従って、Pythonコマンドラインを見つけて、URLを入力として受け入れ、そこに移動し、ページを読み込み、コンテンツを解析し、キーワード、ブロック、または関心のある番号を見つけ、ファイルに追加する簡単なスクリプトを記述します。プレートに入れて続けます。



このスクリプトに、科学出版物、オンライン出版物、ニュースリソースの必要な数のアドレスを読み込みます。すべてをすばやく調べて、結果を合計します。あなたはただグラフと図、それらの上に表を描く必要があります-そして翌朝、勝者の出現で、あなたはあなたの当然のポイントを手に入れます。



それについて考えてみましょう-あなたはその過程で誰かをひどくしましたか？ええと、通常の式でHTMLを解析しない限り、おそらく誰にも害を及ぼさなかったでしょうし、この方法でアクセスしたサイトにも害はありませんでした。これは1回限りのアクティビティであり、控えめで目立たないと言えます。必要なデータをすばやく静かに取得したことで、誰もが傷つくことはほとんどありません。



逆に、初めてうまくいったらまたやりますか？それに直面しましょう-おそらくあなたは多くの時間とリソースを節約し、おそらくあなたが最初に考えていたよりもさらに多くのデータを受け取ったので、そうするでしょう。そして、これは科学的、学術的または一般的な教育研究に限定されません。







情報にはお金がかかり、時間通りに収集された情報にはさらに多くのお金がかかるからです。そのため、多くの人にとって、こすることは深刻な収入源です。これは人気のあるフリーランスのトピックです。データを収集するか、スクレイピングソフトウェアを作成するように求める一連の注文を確認してください。この活動のためのプラットフォームを注文または提供するためにスクレーピングを行う商業組織、いわゆるサービスとしてのスクレイピングもあります。そのような多様性と広がりは可能です。なぜなら、それ自体をこすること自体が違法であり、非難されるものであり、そうではないからです。法的な観点から、彼の過ちを見つけることは非常に困難です-特に現時点では、私たちはすぐにその理由を見つけるでしょう。







私にとって特に興味深いのは、技術的には、誰もあなたがこすりと戦うことを禁じることができないという事実です-これは、バリケードの両側のプロセスの参加者がこの問題の技術的および組織的側面について議論する機会を持つ興味深い状況を作り出します。ある程度前進するために、エンジニアリングは考え、このプロセスにますます多くの人々を巻き込みます。







法的な観点から、私たちが現在検討している状況は、削り取りの許容範囲を含めて、以前は必ずしも同じではありませんでした。スクレーピングに関連するかなりよく知られている訴訟の時系列を少し見ると、eBayの最初の主張は、その夜明けの夜明けでさえ、オークションからデータを収集したスクレーパーに対するものであり、裁判所は彼がこの活動に従事することを禁じていました。次の15年間、現状は多かれ少なかれ維持されました。大企業は、その影響を発見したときにスクレーパーに対する訴訟に勝ちました。 FacebookとCraigslist、および他のいくつかの企業は、彼らに有利に終わった主張を報告しました。



しかし、1年前、すべてが突然変わりました。裁判所は、ユーザーの公開プロフィールを収集して再開した会社に対するLinkedInの主張は根拠がなく、活動の停止を要求する手紙や脅迫を無視したと認定しました。裁判所は、公開データの収集は、それがボットであるか個人であるかに関係なく、この公開データを表示する会社からの請求の根拠にはなり得ないと判断しました。この強力な法的前例により、バランスがスクレーパーに有利にシフトし、より多くの人々がこの分野への関心を示し、実証し、試すことができるようになりました。



しかし、これらすべての一般的に無害なものを見ると、スクレーピングには多くの否定的な用途があることを忘れてはなりません-データが収集されてさらに使用するだけでなく、その過程でサイトまたはその背後にあるビジネスに損害を与えるという考えが実現されますまたは、ターゲットリソースのユーザーを犠牲にして、何らかの方法で自分自身を豊かにしようとします。



いくつかの象徴的な例を見てみましょう。







1つ目は、車、不動産、身の回り品など、そのような広告へのアクセスを提供するサイトから他の人の広告をスクレイピングしてコピーすることです。例として、カリフォルニアの素晴らしいガレージを選びました。そこにボットを設置し、写真を収集し、説明を収集し、すべての連絡先情報を取得し、5分後に同じ広告が同じ焦点の別のサイトにぶら下がっていると想像してみてください。そうすれば、収益性の高い取引が行われる可能性があります。



ここで少し想像力を働かせて次の側面を考えた場合、これを行っているのが競合他社ではなく、攻撃者である場合はどうなるでしょうか。このようなサイトのコピーは、たとえば、訪問者に前払いを要求したり、単に支払いカードの詳細を入力することを提案したりする場合に非常に役立ちます。イベントのさらなる発展を自分で想像することができます。







スクレーピングのもう1つの興味深いケースは、在庫が限られているアイテムの購入です。ナイキ、プーマ、リーボックなどのアスレチックシューズメーカーは、定期的に限定版のスニーカーなどを発売しています。シグネチャーシリーズ-コレクターによって狩られ、期間限定で販売されています。買い物客に先んじて、ボットが靴屋のウェブサイトに駆け寄り、流通全体をかき集めます。その後、これらのスニーカーはまったく異なる値札で灰色の市場に登場します。かつて、これらを配布するこの激怒したベンダーと小売業者。彼らは7年間、スクレーパーやいわゆるスクレーパーと戦ってきました。技術的手法と管理手法の両方でさまざまな成功を収めているスニーカーボット。







オンラインで買い物をするときに、直接スニーカー店に来なければならなかったとき、またはボットが見ずに購入した10万ドルのスニーカー付きハニーポットについての話を聞いたことがあるでしょう。その後、所有者は頭をつかみました。これらの話はすべてこの傾向にあります。







そして別の同様のケースは、オンラインストアの在庫の枯渇です。前のものと似ていますが、実際に購入することはありません。オンラインストアがあり、入ってくるボットが倉庫で利用可能として表示されている量でバスケットに掻き集める特定の商品アイテムがあります。その結果、製品を購入しようとしている正当なユーザーは、この記事が利用できないことを示すメッセージを受け取り、欲求不満で頭の後ろを引っ掻き、別の店に向かいます。その後、ボット自身が収集したバスケットをドロップし、商品はプールに戻されます。必要な人が来て注文します。または、これがささいないたずらとフーリガニズムのシナリオである場合、来ず、注文しません。このことから、そのような活動がオンラインビジネスに直接的な経済的損害を引き起こさない場合でも、少なくともビジネス指標を深刻に混乱させる可能性があることは明らかです。どのアナリストが焦点を当てますか。コンバージョン、出席、製品需要、平均カートチェックなどのパラメーター-これらはすべて、これらのアイテムに関連するボットのアクションによってひどく汚されます。そして、これらの測定基準を機能させる前に、スクレーパーの影響から注意深くそして入念に掃除する必要があります。



このようなビジネスの焦点に加えて、スクレーパーの作業から生じる非常に顕著な技術的影響があります-ほとんどの場合、スクレーピングが積極的かつ集中的に行われる場合です。







クライアントの1つからの例の1つ。スクレーパーは、パラメーター化された検索のある場所に到達しました。これは、問題の構造のバックエンドで最も難しい操作の1つです。スクレーパーは多くの検索クエリを実行する必要があり、200 RPSのうち700近くをこの場所に送信しました。これにより、インフラストラクチャの一部に深刻な負荷がかかり、残りの正当なユーザーのサービス品質が低下し、応答時間が長くなり、502と503が低下しました。と間違い。一般的に、スクレーパーはまったく気にせず、他の全員が必死にブラウザページを更新している間、彼は座って仕事をしました。



このことから、そのような活動は適用されたDDoS攻撃として分類される可能性があり、多くの場合、分類されることは明らかです。特にオンラインストアがそれほど大きくない場合、パフォーマンスと場所の点で繰り返し予約されるインフラストラクチャはありません。このような活動は、リソースを完全に配置しないと（この場合、スクレーパーはデータを受信しないため、スクレーパーにとってあまり有益ではありません）、他のすべてのユーザーをひどく動揺させる可能性があります。







しかし、DDoSに加えて、スクレイピングにはサイバー犯罪の分野からの興味深い隣人もいます。たとえば、ブルートフォースログインとパスワードは同様の技術ベースを使用します。つまり、同じスクリプトを使用して、速度とパフォーマンスに重点を置いて実行できます。資格情報の詰め込みには、どこかから廃棄されたユーザーデータが使用され、フォームフィールドにプッシュされます。さて、コンテンツをコピーして同様のサイトに投稿するというその例は、フィッシングリンクをすり抜けて、疑いを持たない購入者を誘惑するための深刻な準備作業です。







技術的な観点から、スクレーピングのさまざまなバリエーションがリソースにどのように影響するかを理解するために、このタスクに対する個々の要因の寄与を計算してみましょう。いくつかの計算をしてみましょう。







収集する必要のあるデータが右側にたくさんあるとしましょう。値札や見積もりなど、10,000,000行の商品アイテムを取得するタスクまたは注文があります。左側には、明日または1週間で顧客がこのデータを必要としなくなるため、時間の予算があります。データは古くなり、再度収集する必要があります。したがって、特定の時間枠内に維持し、独自のリソースを使用して、最適な方法でそれを行う必要があります。多数のサーバーがあります。それらの背後にあるマシンとIPアドレスから、関心のあるリソースに移動します。私たちには、ふりをするユーザーインスタンスがいくつかあります。オンラインストアや公共の拠点に、これらは別の人であるか、別のコンピューターがデータを取得するように説得するタスクがあります。誰がログを分析するのか、疑いはありませんでした。そして、そのようなインスタンスの1つから、パフォーマンス、要求率があります。



単純なケースでは、1台のホストマシン、ラップトップを持った学生がワシントンポストを通過する場合、同じ符号とパラメータで多数の要求が行われることは明らかです。このようなリクエストが多数ある場合は、ログで非常に目立ちます。つまり、この場合はIPアドレスで簡単に見つけて禁止できます。



スクレーピングインフラストラクチャがより複雑になるにつれて、より多くのIPアドレスが表示され、ハウスプロキシを含むプロキシが使用され始めています-それらについては少し遅れています。そして、各マシンでマルチインスタンス化を開始します。ログにすべてを塗りつぶし、それほど目立たないようにするために、クエリパラメータ（私たちを特徴付ける記号）を置き換えます。



同じ方向に進むと、同じ方程式の枠組みの中で、そのような各インスタンスからのリクエストの強度を減らす機会があります-それらをよりまれにし、より効率的にローテーションして、同じユーザーからのリクエストが近くのログに記録されないようにします。疑惑を引き起こさず、エンド（正当な）ユーザーに似ていることはありません。



まあ、エッジケースがあります-スクレーパーがこれらのアドレスの背後にある完全に異なるユーザー属性を持つ多数のIPアドレスから顧客に来て、そのような各インスタンスがコンテンツに対して1つだけ要求を行ったときに、実際にそのようなケースがありました。目的の製品ページにGETを作成し、それを解析して終了しましたが、二度と表示されませんでした。このようなケースは、同じ時間に関与するためにより多くのリソース（お金がかかる）を必要とするため、非常にまれです。しかし同時に、それらを追跡し、誰かがここに来てそれらをこすったことさえ理解することははるかに困難になります。特定のユーザーの行動パターンを構築する行動分析などのトラフィック調査ツールは、非常に複雑になります。結局のところ、行動がない場合、どのように行動分析を行うことができますか？ユーザーアクションの履歴はありません、彼はこれまでに現れたことがなく、興味深いことに、それ以来二度と来たことはありません。このような状況で、最初のリクエストで何かをしようとしないと、データを受信して​​離れ、何も残されません。ここでは、スクレイピングに対抗する問題を解決していません。したがって、唯一の機会は、サイトで見たいと思っている間違った人が来たという最初の要求を推測し、エラーを与えるか、そうでなければ彼がデータを受け取らないようにすることです。私たちがサイトで見たい人、そして彼にエラーを与えるか、さもなければ彼が彼のデータを受け取らないことを確認してください。私たちがサイトで見たい人、そして彼にエラーを与えるか、さもなければ彼が彼のデータを受け取らないことを確認してください。



スクレーパーを構築する際にこの複雑さのスケールに沿って移動する方法を理解するために、ボット作成者が最も頻繁に使用する武器と、それをどのカテゴリに分類できるかを見てみましょう。







ほとんどの読者が精通している主要で最も単純なカテゴリは、スクリプトのスクレイピングです。これは、比較的複雑な問題を解決するのに十分な単純なスクリプトの使用です。







そして、このカテゴリはおそらく最も人気があり、十分に文書化されています。実際にはたくさんの資料があるので、正確に何を読むべきかを推奨することさえ難しいです。多くの本がこの方法を使用して書かれ、多くの記事や出版物があります-原則として、最初のサイトを解析するのに5/4/3/2分（資料の作成者の無礼さに応じて）を費やすだけで十分です。これは、Webスクレイピングを開始する多くの人にとって論理的な最初のステップです。このようなアクティビティの「スターターパック」は、ほとんどの場合Pythonに加えて、リクエストを柔軟に作成し、リクエストやurllib2などのパラメータを変更できるライブラリです。そして、ある種のHTMLパーサー、ほとんどの場合、BeautifulSoupです。また、scrapyなど、スクレイピング専用に作成されたライブラリを使用するオプションもあります。これには、ユーザーフレンドリーなインターフェイスを備えたこれらすべての機能が含まれています。



簡単なトリックの助けを借りて、マシン、IPアドレス、およびさまざまなハードウェアプラットフォームによってアクティビティをなんらかの方法でスケーリングできなくても、さまざまなデバイス、さまざまなユーザーのふりをすることができます。







データが収集されるサーバー側でログを検査する人の香りをノックオフするには、対象のパラメーターを変更するだけで十分です。これは難しくなく、長くはありません。 nginxのカスタムログ形式の例を見てみましょう。IPアドレス、TLS情報、関心のあるヘッダーを記録します。もちろん、ここでは、通常収集されるすべてではありませんが、例としてこの制限が必要です。サブセットを確認するには、他のすべてがさらに簡単に「スロー」されるためです。



住所によって禁止されないようにするために、海外で呼ばれる住宅用プロキシ、つまりプロバイダーのホームネットワーク内のレンタル（またはハッキング）されたマシンからのプロキシを使用します。このようなIPアドレスを禁止することで、これらの家に住む特定の数のユーザーを禁止する可能性があることは明らかです。また、サイトへの訪問者がいる可能性があるため、これを行うのに費用がかかる場合があります。



TLS情報も変更するのは難しくありません。人気のあるブラウザの暗号スイートを使用して、最も一般的なものを選択するか、定期的にローテーションして別のデバイスとして表示します。



ヘッダーについては、少し調べれば、スクレイプされたサイトが好きなものにリファラーを設定できます。ユーザーエージェントはChromeまたはFirefoxから取得されるため、他の何万人ものユーザーとまったく変わらないようになっています。



次に、これらのパラメータを操作することで、さまざまなデバイスのふりをして、丸太を歩いている裸眼に何とか気付かれることを恐れずにこすり続けることができます。武装した目にとって、このような単純なトリックは同じ、かなり単純な対策によって中和されるため、これはさらにやや困難です。







リクエストパラメータ、ヘッダー、IPアドレスを相互に、および公に知られているものと比較することで、最も傲慢なスクレーパーを捕まえることができます。簡単な例-検索ボットが私たちにやって来ましたが、何らかの理由でそのIPだけが検索エンジンのネットワークからではなく、いくつかのクラウドプロバイダーからのものです。 Googlebotについて説明しているページのGoogle自体でさえ、このボットが実際にgoogle.comまたは他の有効なGoogleリソースからのものであることを確認するために、DNSレコードの逆引きを行うことをお勧めします。



そのようなチェックはたくさんありますが、ほとんどの場合、ファジーやある種の代替を気にしないスクレーパー向けに設計されています。より複雑なケースでは、より信頼性が高く面倒な方法があります。たとえば、Javascriptをこのボットに挿入します。そのような状況では、闘争はすでに不平等であることは明らかです-あなたのPythonスクリプトはJSコードを実行して解釈することができません。しかし、スクリプトの作成者はそれを行うことができます-ボットの作成者が、Javascriptがブラウザで何をしているかを確認するのに十分な時間、欲求、リソース、スキルを持っている場合。



チェックの本質は、スクリプトをページに統合することです。スクリプトが実行されるだけでなく、ある種の結果を示すことも重要です。これは通常、クライアントが十分なスリープ状態になる前にサーバーにPOSTで返送されます。コンテンツ、およびページ自体が読み込まれます。したがって、ボットの作成者があなたの謎を解き、正しい答えをPythonスクリプトにハードコードする場合、またはたとえば、必要なパラメーターと呼び出されたメソッドを検索するためにスクリプト行を自分で解析する必要がある場所を理解し、自分で答えを計算する場合、彼はあなたを丸で囲むことができます。あなたの指の周り。これが例です。







一部のリスナーはこのjavascriptを認識していると思います。これは、要求されたページにアクセスする前に、コンパクトで非常にシンプルでありながら、学習しなくても簡単にアクセスできる、世界最大のクラウドプロバイダーの1つであるチェックです。サイトは突破しません。同時に、少しの努力を払った後、呼び出されるJSメソッドを検索するページに問い合わせて、それらからカウントし、計算する必要のある関心のある値を見つけて、計算をコードに貼り付けることができます。その後、遅れて数秒間寝ることを忘れないでください、そして出来上がり。







このページにアクセスすると、必要なものを解析できます。独自のスクレーパーを作成する以外にリソースを費やすことはありません。つまり、リソースを使用するという観点からは、このような問題を解決するために追加の機能は必要ありません。 JSチャレンジを作成し、それらを解析し、サードパーティのツールで回避するというこの流れの中での武器競争は、ボットの作成者とチェックの作成者の時間、欲求、スキルによってのみ制限されることは明らかです。このレースはかなり長く続く可能性がありますが、それに対処するためのより興味深いオプションがあるため、ある時点でほとんどのスクレーパーは面白くなくなります。ブラウザをつかんで実行できるのに、なぜPythonでJSコードを座って解析するのですか？







はい、私は主にヘッドレスブラウザについて話しています。これは、もともとテストとQ＆Aのために作成されたこのツールが、現時点ではWebスクレイピングタスクに理想的であることが判明したためです。







ヘッドレスブラウザについては詳しく説明しませんが、ほとんどのリスナーはすでにヘッドレスブラウザについて知っていると思います。ヘッドレスブラウザを自動化するオーケストレータは、過去10年間で非常に活発な進化を遂げてきました。当初、PhantomJSとSelenium2.0およびSeleniumWebDriverの最初のバージョンの時点では、オートマトンの下で実行されているヘッドレスブラウザーは、ライブユーザーと区別するのがまったく難しくありませんでした。しかし、時間の経過とともに、ヘッドレスChrome用のPuppeteerなどのツールの出現、そして今ではMicrosoftからの紳士の作成-Puppeteerと同じことを行うPlaywrightは、Chromeだけでなく、人気のあるブラウザのすべてのバージョンで、ますます増えていますヘッドレスブラウザを実際のブラウザに近づける健康な人のブラウザと同じように動作し、異なる兆候や特性を持つオーケストレーションの助けを借りて、それらをどのように作成できるか。







人々が座っている通常のブラウザの背景に対するヘッドレス認識に対処するために、原則として、同じjavascriptチェックが使用されますが、より深く、詳細に、パラメータのクラウドを収集します。この収集の結果は、保護ツールまたはスクレーパーがデータを収集したいサイトに送り返されます。このテクノロジーは、ブラウザーとそれが実行されているデバイスの実際のデジタルフィンガープリントを収集するため、フィンガープリントと呼ばれます。



フィンガープリントを確認するときにJSがチェックすることはかなりあります。それらはいくつかの条件付きブロックに分割でき、それぞれのブロックで掘り下げを続けることができます。本当にたくさんのプロパティがあり、それらのいくつかは隠すのが簡単で、いくつかはそれほど簡単ではありません。そしてここでは、前の例のように、スクレーパーがヘッドレスの突き出た「尾」を隠すタスクにどれだけ細心の注意を払ってアプローチしたかに大きく依存します。オーケストレーターがデフォルトで置き換えるオブジェクトのプロパティがブラウザーにあり、ヘッドレスに設定されているプロパティ（navigator.webdriver）がありますが、同時に通常のブラウザーには存在しません。非表示にすることができ、特定のメソッドをチェックすることで非表示の試みを検出できます。これらのチェックをチェックするものを非表示にして、メソッドを印刷する関数に偽の出力をスリップさせることもできます。そしてそれは無期限に続くことができます。



チェックの別のブロックは、原則として、ヘッドレスブラウザには定義上ないウィンドウと画面のパラメータの調査を担当します。座標のチェック、サイズのチェック、描画されていない壊れた画像のサイズはどれくらいですか。ブラウザのデバイスをよく知っている人が、それぞれについてもっともらしい（しかし実際ではない）結論を予見し、滑らせることができるニュアンスがたくさんあります。それは、指紋チェックでサーバーに飛び、それを分析します。たとえば、WebGLとCanvasを使用して2Dと3Dの一部の画像をレンダリングする場合、出力全体を完全に準備し、偽造し、メソッドで発行して、何かが実際に描かれていると誰かに信じ込ませることができます。



同時に発生しない、よりトリッキーなチェックがありますが、JSコードがページ上で特定の秒数の間スピンするか、常にハングしてブラウザからサーバーに情報を転送するとします。たとえば、カーソルの動きの位置と速度を追跡する-ボットが必要な場所だけをクリックし、光の速度でリンクをたどる場合、ボットの作成者が人間のような滑らかなものを書くことを考えていない場合、これはカーソルの動きによって追跡できます、オフセット。



そして、かなりのジャングルがあります。これらは、オブジェクトモデルのバージョン固有のパラメータとプロパティであり、ブラウザごと、バージョンごとに固有です。また、これらのチェックが正しく機能し、改ざんされないようにするには、たとえば、一部の古いブラウザを使用しているライブユーザーで、さまざまなことを考慮する必要があります。まず、新しいバージョンのリリースに遅れずについていく必要があります。チェックを変更して、フロントの状況を考慮に入れる必要があります。誰かが非定型のブラウザでそのようなチェックによって保護されたサイトにアクセスすると同時に、ボットのように捕まえられないようにするために、後方互換性を維持する必要があります。



これは骨の折れる、かなり複雑な作業です。このようなことは通常、ボット検出をサービスとして提供する企業によって行われ、独自のリソースでこれを行うことは、時間とお金のあまり有益な投資ではありません。



しかし、私たちに何ができるのでしょうか。どんなに一生懸命努力しても、そのようなヘッドレスチェックの雲にぶら下がって、パペティアでヘッドレスクロームを計算する必要があります。



小さな叙情的な逸脱-チェックの歴史と進化についてより詳細に読むことに興味がある人のために、たとえば、Chromeのヘッドレスのために、2人の著者の間に面白いエピソードの決闘があります。 1人の著者についてはよくわかりませんが、もう1人はAntoine Vastelと呼ばれ、ボットとその検出、チェックの難読化、その他多くの興味深いことについてブログを管理しているフランスの若者です。そのため、彼らとそのカウンターパートは、ヘッドレスChromeを検出できるかどうかについて2年間議論してきました。



そして、ヘッドレスでチェックを通過できない場合の対処方法を理解します。







これは、ヘッドレスを使用せず、ウィンドウやあらゆる種類の視覚要素を描画する大型の実際のブラウザーを使用することを意味します。 PuppeteerやPlaywrightなどのツールを使用すると、ヘッドレスの代わりに、レンダリングされた画面でブラウザを起動したり、そこからユーザー入力を読み取ったり、スクリーンショットを撮ったり、ビジュアルコンポーネントのないブラウザでは利用できない多くのことを実行できます。







ヘッドレスチェックをバイパスすることに加えて、この場合、次の問題にも対処できます-狡猾なサイトビルダーがいる場合、写真のテキストから非表示にし、追加のクリックやその他のアクションや動きを行わずに非表示にします。彼らは隠されるべきであり、頭のないものに出くわすいくつかの要素を隠します：彼らはこの要素が今画面に表示されるべきではないことを知りません、そして彼らはそれに出くわします。この画像をブラウザで描画し、スクリーンショットをOCRにフィードし、出力でテキストを取得して使用するだけです。はい、それは開発の点でより難しく、より高価であり、より長くかかり、より多くのリソースを消費します。しかし、このように機能するスクレーパーがあり、速度とパフォーマンスを犠牲にして、この方法でデータを収集します。







「CAPTCHAはどうですか？」 - あなたが尋ねる。結局のところ、OCR（高度な）キャプチャは、いくつかのより複雑なものなしでは解決できません。これには簡単な答えがあります-キャプチャを自動的に解決できない場合は、人的労力を使用してみませんか？目標を達成するためにそれらの作業を組み合わせることができるのに、なぜボットと人間を分離するのですか？



画面の前に座っている人の手によって解決されるキャプチャを送信できるサービスがあります。APIを介して、キャプチャへの応答を取得し、たとえば発行されるリクエストにCookieを挿入して、このサイトからの情報を自動的に処理することができます。 ..。キャプチャがポップアップするたびに、私たちはアピシュカを引っ張って、キャプチャへの答えを得ます-次の質問でそれを滑らせて、次に進みます。



これにもかなりの費用がかかることは明らかです-captchaソリューションはまとめて購入されます。しかし、私たちのデータがこれらすべてのトリックのコストよりも高価な場合、結局のところ、なぜですか？



これらすべてのツールの複雑さへの進化を見てきたので、オンラインリソース（オンラインストア、公開ナレッジベースなど）でスクレイピングが発生した場合の対処方法について考えてみましょう。







最初に行うことは、スクレーパーを見つけることです。これをお伝えします。レポートの冒頭ですでに検討したように、一般に、集会のすべてのケースが悪影響をもたらすわけではありません。原則として、より原始的な方法、レート制限なし、リクエスト速度を制限しない同じスクリプトは、1つのリクエストで複雑で洗練された頭の良いブラウザスクレイピングよりもはるかに多くの害を及ぼす可能性があります（保護によって防止されない場合）時間内に、それは最初はまだログで何とか見つける必要があります。







したがって、最初に、私たちが削られていることを理解する必要があります-この活動によって通常影響を受ける意味を調べるために。現在、技術パラメータとビジネス指標について話し合っています。これらは、負荷とトラフィック、あらゆる種類のバーストと異常を監視しながら、Grafanaで確認できるものです。これは、セキュリティツールを使用しない場合は手動で実行できますが、トラフィックをフィルタリングし、あらゆる種類のインシデントを検出し、それらをいくつかのイベントと照合する方法を知っている人がより確実に実行できます。事後にログを分析することに加えて、個々の要求を分析することに加えて、知識ベースの保護のいくつかの蓄積された手段の使用がここで機能する可能性があるため、このリソースまたは同様のリソースでのスクレーパーのアクションをすでに見ており、どういうわけか互いに比較することができます-スピーチ相関分析について。



ビジネス指標については、直接的または間接的な経済的損害を引き起こすスクリプトの例を使用したことをすでに思い出しました。これらのパラメータのダイナミクスをすばやく追跡できる場合は、再びスクレイピングに気付くことができます。この問題を自分で解決する場合は、バックエンドのログへようこそ。







攻撃的な擦り傷に対して使用される保護手段については、ボットのさまざまなカテゴリについて説明し、すでにほとんどの方法を検討しました。トラフィック分析は、最も単純なケースから私たちを助け、行動分析は、ファジー（ID置換）やマルチインスタンススクリプトなどを追跡するのに役立ちます。より複雑なものに対して、私たちはデジタルプリントを収集します。そしてもちろん、私たちは王の最後の議論としてCAPTCHAを持っています-前の質問で狡猾なボットをどうにかして捕まえることができなかったなら、おそらく、それはCAPTCHAでつまずくでしょう？







さて、ここではもう少し複雑です。事実、チェックの複雑さと狡猾さが増すにつれて、主にクライアント側にとって、チェックはますます高価になります。トラフィック分析とその後のパラメータといくつかの履歴値との比較が、原則としてページの読み込み時間とオンラインリソースの速度に影響を与えることなく、完全に非侵襲的に実行できる場合、フィンガープリントは、それが十分に大きく、ブラウザ側で何百もの異なるチェックを行う場合、ダウンロード速度に深刻な影響を及ぼします。そして、リンクをたどる過程でチェック付きのページを見るのを好む人はほとんどいません。



CAPTCHAに関して言えば、これは最も粗雑で最も侵襲的な方法です。これは、ユーザーや購入者をリソースから本当に怖がらせることができるものです。誰もcaptchaが好きではありません、そして彼らは良い人生のためにそれに頼りません-彼らは他のすべてのオプションがうまくいかなかったときにそれに頼ります。ここにもう1つの面白いパラドックスがあります。これらのメソッドのそのようなアプリケーションには、いくつかの問題があります。事実、1つまたは別の重ね合わせでの保護手段のほとんどは、遭遇したボットアクティビティのシナリオの複雑さに応じて、これらすべての可能性を使用します。ユーザーがトラフィックアナライザーに合格した場合、ユーザーの動作と変わらない場合、指紋が有効なブラウザーのように見える場合、ユーザーはこれらすべてのチェックを克服し、最後にキャプチャを表示します-そしてそれは人であることが判明しました...それは非常に悲しいことがあります..。その結果、私たちが遮断したい邪悪なボットではなく、かなり深刻なユーザーのシェアにキャプチャが表示され始めます-これに腹を立てて次回は来ないかもしれない、リソースで何かを購入しない、そのさらなる開発に参加しない人々。







これらすべての要因を考慮して、スクレーピングが発生した場合、最終的に何をすべきかを検討し、それがビジネスおよび技術的パフォーマンスに与える影響を何らかの形で評価することができましたか？一方では、公開データ、マシン、または人の収集のように、定義上、スクレイピングと戦うことは意味がありません。このデータは、インターネットからアクセスするすべてのユーザーが利用できることに同意しました。そして、「原則外」のスクレイピングを制限する問題を解決します-つまり、高度で才能のあるボットがあなたに来るという事実のために、あなたはそれらすべてを禁止しようとします-それはあなた自身の保護に多くのリソースを費やすか、高価で非常に複雑なソリューションを使用することを意味します、「最大セキュリティモード」でセルフホストまたはクラウドベースであり、個々のボットを追跡する場合、そのようなもので有効なユーザーのシェアを怖がらせるリスクがあります。重いjavascriptチェックのように、3つおきの遷移でポップアップするcaptchaのように。これらすべてがあなたのサイトを認識を超えてあなたの訪問者の不利益に変える可能性があります。



保護ツールを使用する場合は、変更できるツールを探し、リソースの使用を遮断しようとするスクレーパーの割合（単純なものから複雑なものまで）と、実際にはWebの速度とのバランスを見つける必要があります。 -資源。なぜなら、すでに見てきたように、いくつかのチェックは簡単かつ迅速に行われる一方で、いくつかのチェックは困難で時間がかかるだけでなく、同時に訪問者自身にとって非常に目立ちます。したがって、共通のプラットフォーム内でこれらの対策を適用および変更できるソリューションを使用すると、このバランスをより迅速かつ適切に達成できます。



さて、これらすべての問題を自分自身または他の人の例で研究する際に、いわゆる「正しい考え方」を使用することも非常に重要です。公開データ自体は保護を必要としないことを覚えておく必要があります-それは遅かれ早かれそれを望むすべての人々に見られるでしょう。ユーザーエクスペリエンスを保護する必要があります。スクレーパーとは異なり、収益を生み出す顧客、顧客、ユーザーのUXです。この非常に興味深い分野に精通している場合は、それを維持して増やすことができます。



ご清聴ありがとうございました！