Node.jsでのWebスクレイピングとボット保護

これは、Node.jsを使用したWebスクレイピングスクリプトの作成と使用に関するシリーズの3番目の記事です。

1. Node.jsを使用したWebスクレイピング
2. Node.jsおよび問題のあるサイトでのWebスクレイピング
3. Node.jsでのWebスクレイピングとボット保護
4. Node.jsを使用した更新データのWebスクレイピング

最初の記事では、ページの取得と解析、再帰的なリンクのクリック、クエリのキューイングなど、Webスクレイピングの基本的な側面を取り上げました。 2番目の記事では、Ajaxを介して動作しているサイトの分析、リクエストキューの微調整、およびサーバーエラーの処理について検討しました。

2番目の記事でもセッションの初期化のトピックに触れましたが、1つの追加リクエストを処理してCookieを保存するのに十分な場合は非常に単純なケースでした。

この記事では、ログインとパスワードの認証によるセッションの初期化と、ボットに対するかなり高度な保護の克服という、より複雑なケースを扱います。 いつものように、実際の（そしてスクレーパーの間で非常に人気のある）タスクの例を使用します。

過去の記事の目標は、タスクの設定から最終結果の取得まで、スクリプトを作成および使用するプロセス全体を示すことでした。 この記事では、Webスクレイピングのほとんどの側面をバイパスし、代わりに1つのかなり狭いタスクを解決するためのさまざまなアプローチを示します。 さまざまな方法とツール、それらの長所と短所、主観的評価、コード例、それだけです。

問題の声明

今回は、顧客は同僚の助けを必要とする別のWebスクレイパーです。 彼は、有名なAmazonサイトから（顧客のために）データを取得したいと考えています。 彼が必要とするデータの一部は、許可されたユーザーにのみ提供されます。 もちろん、顧客はAmazonにアカウントを持っていますが、問題はこのサイトが自動認証から保護されていることです。 お客様は、この保護に合格するNode.js上のモジュールを必要とします。 当然、これはあなた自身のリスクであなたのアカウントを自動的に承認するためのツールであり、他人のアカウントをハッキングすることではありません。

顧客は、タスクの自分の部分の分析をすでに実行しています。 彼は、1つのヘッダーと2つのCookieがhttp要求で設定されている場合（または、これら2つを許可セッションから分離するのが面倒な場合はすべて）、必要なデータが利用可能であることを確認しました。 ヘッダーは常に同じであり、Cookieは許可されたAmazonユーザーのページからブラウザーで簡単に取得できます（DevToolsまたは同様のツールを使用）。 Cookieはすぐに陳腐化することはないため、一度多くの承認済みリクエストを実行できるようになったら、Cookieを受け取ります。

たとえば、次のコードは、承認されたAmazonユーザーのみがアクセスできるメールアドレスを印刷する必要があります。

var needle = require('needle'); var testURL = 'http://www.amazon.com/gp/profile/A14ZQ17DIPJ6UB/customer_email'; var cookies = { 'session-id': '111-2222222-3333333', //   session-id 'ubid-main': '444-5555555-6666666', //   ubid-main }; work(cookies); function work(cookies){ var options = { headers: { 'X-Requested-With': 'XMLHttpRequest' }, cookies: cookies }; needle.get(testURL, options, function(err, res){ if (err) throw err; console.log(res.body.data.email); }); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、顧客はアカウントからログインとパスワードを入力として受け取り、出力時に必要なCookieを提供するモジュールが必要です。 このようなもの：

 module.exports = function(email, password, work){ // magic work(cookies); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

顧客はこのモジュールをAmazon独自のWebスクレイピングスクリプトで使用します。 独自のフレームワークにねじ込んでスクレイピングすることもできます。 これは私たちにとって重要ではありません。

メソッドの概要

このような問題を解決するためのすべての方法は、3つのカテゴリに分類できます。

1. ブラウザシミュレーション：トラフィック分析、リバースエンジニアリングスクリプトなどのハッカーメソッドが受信したデータに基づいてリクエストを実行します。
2. ブラウザの自動使用。 これには、特別なAPI（例：Selenium WDを使用）を介した実際のブラウザー（例：Chrome）によるスクリプトの管理、およびヘッドレスブラウザー（例：PhantomJS）の使用が含まれます。
3. ブラウザを手動で使用します。 これは必ずしもスクレイピングの自動化を完全に拒否することを意味するわけではありませんが、ライブオペレーターが実際のページを見て、ユーザーインターフェースを介して実際のアクションを実行することを意味します。

これら3つのポイントの選択は明らかではなく、少なくとも主観的です。 3つのカテゴリすべてに長所と短所があり、いずれを使用しても問題を解決できるため、順番に検討します。

シミュレートされたブラウザ

似たようなことが以前の2つの記事で説明されています。 スクレイピングするために、正しいhttpリクエストをサーバーに送信します。 「正しい」ものは、​​スクレイピングが完全に手動で行われた場合にブラウザが送信するものです。 個々のリクエストで送信する内容を正確に見つけるために、ブラウザでリクエストとレスポンスのヘッダーを分析し、ページのソースも調べます。 この記事のタスクは、1つの点を除いて、前の2つと基本的に違いはありません。この場合、「ページソース」の概念は接続スクリプトも意味します。 リクエストにデータを追加するコードの量、このデータの送信元などを理解する必要があります。 サイトスクリプトに適用される通常のリバースエンジニアリング。

このアプローチの主な利点は、その汎用性です。 保護が人とブラウザの標準的な組み合わせによって実行される場合、その通過のためのアルゴリズムはリバースエンジニアリングによって見つけることができます。 理論的には、この規則に例外はありません。 Webスクレイピングの世界には、リバースエンジニアリングだけで解決できるタスクがあります。

このアプローチの主な欠点は、その無限の労力です。 これは、精神的に強い人たちにとっての方法であり、時間に特に制限はありません。 実際には、1つの複雑なサイトのリバースエンジニアリングに時間がかかる場合があり、そのためにスクリプトを記述して、数千の「通常の」サイトをスクレイピングできます。 理論的には、セキュリティメーカーはそれに時間を費やすことができ、その資格を得るには、経験豊富で才能のあるハッカーがリバースエンジニアリングに従事する必要があります。 簡単に言えば、特定のレベルの複雑さでは、顧客がクールなハッカーの代わりにコピー＆ペーストの店員を雇う方がより有益になります。 または、注文を拒否し、これらのデータなしで行います。

すべてのスクレーパーが一般にハッキングスキルを持っているわけではなく、チーム内にハッカーを持っているわけでもないことに注意してください。 サイト上のスクリプトを理解する必要性に直面して、ほとんどの人は別のカテゴリのメソッドの注文や選択を拒否します。 さて、または別の専門家を雇います。

トラフィックとHTMLの分析時に保護アルゴリズムが表示されない場合は、他のアプローチから始める価値があります。 アルゴリズムがいつでも突然変更される可能性がある場合（Amazonなど）、最後に考慮するリバースエンジニアリングをお勧めします。 さらに、リバースエンジニアリングによって取得されたAmazon保護コードが、たとえばHabrにアップロードされた場合、このコードが古いことをすぐに書くことができるようです-これはすぐに真実になります。

この記事では、コード例で他の方法を説明します。

ブラウザの自動使用

このアプローチは初心者のスクレイパーの間で非常に人気があり、サイトの分析で問題が発生するたびにアクセスします。 厳しい締め切りの専門家もこのアプローチを気に入っています。

このアプローチの主な利点は、サイト内のスクリプトを理解する必要がないため、スクリプト保護を簡単に通過できることです。スクリプトは単にブラウザーで実行され、コードではなくマウスとキーボードを使用するユーザーによって起動された場合と同じように実行されます。 コードは、近くの店員コピーパスタの指示に似ています。 必要に応じて読みやすく編集しやすくなります。

このアプローチの主な欠点は、コンピューターで他の人のコードを実行することです。 このコードには、たとえば、ヘッドレスブラウザー検出器からユーザーの行動のインテリジェントな分析まで、さまざまなタイプの自動化に対する追加の保護が含まれる場合があります。 もちろん、たとえば、スクリプトを検出器に置き換えるプロキシサーバーを使用できますが、これには同じリバースエンジニアリングが必要であり、一般にブラウザーに煩わされる理由は不明です。

（注：ユーザーの行動を分析する技術の例は、 AreYouaHumanの Webサイトで見ることができ、ヘッドレスブラウザー検出器は、 優れたプレゼンテーションで見つけることができます。前年の記事のコメントにkirill3333が残したリンクです。

このアプローチのもう1つの欠点は、ブラウザが通常のスクレイパースクリプトよりも多くのリソースを消費することです。 数千（さらには数百万）のページをスクレイピングする場合、これは悪い考えです。 顧客はモジュールを望んでおり、そのコードは1回実行され、少数のリクエストのみを送信するため、リソースを心配する必要はありません。

Node.JSのスクリプトからブラウザを自動的に使用するための一般的なツールは数多くあります。 ここで、主なものについて簡単に説明します（無駄に誰かを忘れた場合-コメントで教えてください）：

Selenium WDは、ブラウザを自動で使用するための最も有名で人気のあるツールです。 追加の紹介は必要ありません。 オンラインで多数の例とヒントがあります。 専門的にスクラップを行うことを考えている人は誰でもSelenium WDを試してください。

残念ながら、Selenium WDは問題の解決には適していません。 これを使用するには、Java、Selenium WD自体（Javaアプリケーション）、ブラウザー、ブラウザードライバー、選択したプログラミング言語（この場合はNode.jsから）にSelenium WDにアクセスするためのモジュールをインストールして構成する必要があります。 これは簡単な方法ではありません。Node.jsですぐに使用できるシンプルなモジュールが必要なためです（極端な場合、 ' npm install



'などが必要です）。

PhantomJSは、 WebKitを 搭載したヘッドレスブラウザーです。 実際のブラウザでサイトを起動しますが、ユーザーページは表示されず、ユーザーインターフェイスの代わりにJavaScriptのスクリプトが使用されます。 PhantomJSのブラウザーは非常にいっぱいであるため、Selenium WDのドライバーもあり、この束は正常に機能します。

タスクの観点から見ると、PhantomJSについて知っておくべき主なことは、Node.jsと同じJavascript言語を使用していますが、Node.jsではないということです。 それのように見えますが、そうではありません。 PhantomJSを直接使用するモジュールをNode.jsで作成することはできません。 PhantomJS上で別のスクリプトを作成し、別のプロセスを開始してそのデータをstdout



経由で受け取るラッパーモジュールを作成できます。 最も単純な場合、次のようになります。

 var sys = require('sys'), exec = require('child_process').exec; module.exports = function(callback) { exec('phantomjs script.js', function(err, stdout){ callback(err === null ? stdout : false); }); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

stdout



を台無しにせず、便利なインターフェースで作業するために、PhantomJSで既製の（そして誰かが慎重にテストした）ラッパーの1つを使用するのは理にかなっています。

SlimerJS-大まかに言って、同じPhantomJSですが、WebKitではなくGeckoです。 この場合、SlimerJSがPhantomJSより少ないラッパーでサポートされることが重要です。

CasperJSは、PhantomJSおよびSlimerJSの最も有名なNode.jsラッパーです。 CasperJSがネイキッドよりも優れている理由PhantomJSは、たとえばこの記事 （英語）でよく書かれています。 しかし、 この記事 （英語でも）では、CasperJSを使用したAmazonでの承認の例を見ることができます。 これは実用的なソリューションですが、これは最良の選択肢ではありません（少なくとも、この例のコード量を評価してください）。 CasperJSの代わりに、次のリスト項目に注意することをお勧めします。

Horseman.jsは、PhantomJSの非常に優れたラッパーです。 私たちのようなモジュールを書くのに最適です。 複雑なインストールおよび構成手順は必要ありません。 モジュールでphantomjs-prebuilt



とnode-horseman



を追加するだけで十分です。 Horseman.jsのインターフェースは非常に簡潔で、柔軟性があり、読みやすいです。 Horseman.jsを使用して記述されたモジュールの作業コードは次のとおりです。

 var Horseman = require('node-horseman'); var horseman = new Horseman(); var startURL = 'https://www.amazon.com/gp/css/homepage.html/'; module.exports = function(email, password, work){ horseman .userAgent('Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36') .open(startURL) .click('#nav-tools>a') .waitForNextPage() .type('form [name=email]', email) .type('form [name=password]', password) .click('#signInSubmit') .waitForNextPage() .cookies() .then((cookies)=>{ work(cookies); }) .close(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのようなコードは、ドキュメントを見なくても読むことができます。 そしてそれは動作します。

NWは、もう1つの管理対象ブラウザー（以前のnode-webkit）です。 Node.jsのスクリプトからBlinkエンジンを制御できます。 主な目的は、Webテクノロジーを使用してデスクトップアプリケーションを作成することですが、ヘッドレスとして機能することもできます。 NWでは、本格的なスクレイピングアプリケーションを作成できます。 たとえば、 この記事の vmbのようなものです。 NWのようなツールは、顧客がコマンドラインを恐れてボタンウィンドウを必要とする場合に特に適しています。 私たちの場合、NWは最良の選択ではありません。

Electronは、Webベースのデスクトップアプリケーションを作成するためのもう1つのツールです。 実際、これはNWの若くて有望な競争相手であり、その助けを借りて、優れた指標でスクレイピングアプリケーションを作成することもできます。 さらに、Electronはヘッドレスブラウザーとして簡単に使用できますが、モジュールではなく、ラッパーを介してモジュールに接続することをお勧めします。

悪夢はElectronの最も有名なラッパーです。 名前にもかかわらず、非常に良い印象を与えます。 何人かの初心者スクレイパーが、Electronについてまったく知らずにNightmareを使用できるようにスムーズに設計されています。 インターフェースはHorseman.jsに非常に似ています（ほぼ同じです）。 これは、Nightmareを使用して記述されたモジュールの作業コードがどのように見えるかです。

 var Nightmare = require('nightmare'); var nightmare = Nightmare() var startURL = 'https://www.amazon.com/gp/css/homepage.html/'; module.exports = function(email, password, work){ nightmare .goto(startURL) .click('#nav-tools>a') .wait('#signInSubmit') .type('form [name=email]', email) .type('form [name=password]', password) .click('#signInSubmit') .wait('#nav-tools') .cookies.get() .end() .then(function (cookies) { work(cookies); }) .catch(function (error) { console.error('Authorization failed:', error); }); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

原則として、すべてはHorseman.jsの場合と同じです。 内部では、PhantomJSの代わりにElectronが使用されていますが、目には見えません。

Chimeraは、最小限の依存関係を持つNode.jsの通常のモジュールです（実際にはrequest



のみ）。 ページをロードし、そのコンテキストでスクリプトを実行し、その結果をNode.jsのコンテキストで処理できます。 フロントエンドからスクレイピングに来た人の中には、このモジュールの愛好家がいますが、私の意見では、あまりにもミニマルです。 少なくとも、顧客が休み、ブラウザエンジンが接続されていないモジュールが必要な場合、Chimeraではなく、次のオプションを使用できます。

ZombieJS-このモジュールは、多くの場合、PhantomJSの類似物として位置付けられており、Node.jsから直接実行できます。 ZombieJSはブラウザエンジンを使用せず、 request



、 jsdom



、 ws



などの使い慣れたツールをバイパスします。 Horseman.jsと比較すると、ZombieJSコードは扱いにくいように見えますが、Chimeraの後には便利さと簡潔さの例になっています。

 var Browser = require('zombie'); var browser = new Browser(); var startURL = 'https://www.amazon.com/gp/css/homepage.html/'; module.exports = function(email, password, work){ browser.visit(startURL, function(){ browser.clickLink('#nav-tools>a', function() { browser.fill('email', email); browser.fill('password', password); browser.pressButton('#signInSubmit', function(){ var cookies = browser.saveCookies().split('\n'); var newCookies = {}; for (var i = 0; i < cookies.length; i++) { var cookie = cookies[i].split(';')[0].split('='); newCookies[cookie[0]] = cookie[1]; } browser.tabs.closeAll(); work(cookies); }); }); }); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ZombieJSの明らかな短所には、不十分なドキュメントが含まれます。 以前は良かったのですが、開発者はそれをさらに悪くしました。 なぜ彼がそれをしたのかについて陰謀説を構築するつもりはありませんが、ZombieJSで理解できるリンクの例をいくつか示し ます 。 例とAPIです。

興味深いことに、PhantomJS、Electron、およびZombieJSは多くのサイトで異なって認識されているため、一方のツールが保護され、他方のツールがブロックされています。 これは、これらの3つのツールのいずれかを使用する準備ができている重大な理由です。 もちろん、そのような複雑なケースはまれです。 たとえば、3つのスクリプトはすべてAmazonサイトで機能します。 まあ...彼らが働いている間。

ブラウザーの手動使用

この点は、楽しみのためにここに記載されているように見えるかもしれませんが、そうではありません。 そのようなアプローチが正当化されるだけでなく、最適である場合もあります。 たとえば、1回自動化するのが難しいアクションを実行する必要があり、その後簡単な操作を何度も自動的に実行する場合。 たとえば、Amazonにログインしてから、それを破棄するのを待ちます。

このアプローチの主な欠点は、スクリプトを実行するたびにライブユーザーが必要になることです。 つまり、 cron



スクレイピングを開始することはできません。ページを見て誰かと何かをする必要があります。

このアプローチの主な利点は、プロセスの可視性です。 ユーザーはページで何が起こっているかを確認し、何か問題が発生した場合に気付くでしょう。 または多分彼はそれを修正することができます。 たとえば、サイトが突然captchaを要求し始めた場合（Amazonのように、自動認証を使用して長い間緊張させた場合）。

ブラウザをスクリプトに手動で追加する最も簡単な方法は、ユーザーに指示を書くことです。 たとえば、ブラウザーからCookieを取得してスクリプトテキストに配置する方法を説明するクリアテキストは、同じプログラムですが、コンピューター用ではなく個人用です。 多くのプログラマーはそのようなプログラムをうまく書くことができ、多くの顧客は時間とお金を節約するために簡単に妥協することができます。 残念ながら、お客様にはユーザーの指示を必要としないモジュールが必要です。

別の方法は、独自のブラウザーを作成することです。ブラウザーは、Amazonでの承認のためにのみ起動され、閉じられます。 たとえば、Electronに基づいています。 これはそれほど難しくありません。 Nightmareスクリプトに小さな変更を加えると、スクリプトは動作するページを表示します。 ユーザーは、スクリプトがフォームフィールドに入力して送信する方法を確認します。 追加パラメーターでNightmareを初期化する必要があります。 このように：

 var nightmare = Nightmare({ show: true })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

たとえば、サイトがキャプチャを要求し始めたことがわかりますが、これはそれほど珍しいことではありません。 さらに、ユーザーは電子ウィンドウにキャプチャを直接入力でき、すべてが機能します。 スクリプトの遅延だけを長く設定する必要があります。そうしないと、ユーザーが間に合わない場合があります。 一般に、フォームフィールドの自動入力を削除して、ユーザーに提供できます。 そうすれば、スクリプトのテキストにパスワードを保存しないことが可能になります。 さらに、異なるユーザーに代わって、異なる時点でスクレイピーを行うことが可能になります。

一方、NightmareはCaptchaリクエストを認識し、 Death by Captchaなどのサービスを使用してそれを渡すように教えることができますが、タスクにはそのような要件はありません。

おわりに

, - . , , , . , , . , , . , ( ), “” .

, , , . .