読者です 読者をやめる 読者になる 読者になる

bz0のにっき

quick and dirty prototype

webスクレイピング対策への対処について

サイト管理者が立てるであろうスクレイピング対策

サイト管理者の目線で、行うであろうスクレイピング対策から
スクレイピングする側で、どう対処すべきか考えてみます。

スクレイピング対策しているという事は、マジで迷惑だから辞めろやという事だと思うので
 スクレイピングするなという話ではありますが。。。)

考え方

結論

機械的なアクセスをしない。人間的なアクセスに近づける。

参考

悪質なボットによるアクセスの見分け方
http://markezine.jp/article/detail/9834


・ アクセスしてくるURLのパターンからボットを見分ける

・同じIPアドレスからのアクセスの間隔が常にほぼ同じ秒数間隔
 ・同じIPアドレスから、同じユーザーエージェントで大量にアクセスが行われているか
 ・ 人間らしくないきっちりしすぎるアクセス

・ アクセス元のIPアドレスを集計している
・ 何度もアクセスしてきているのに、セッションクッキーを絶対に送ってこない
リファラーがまったくない
・ HTMLだけにアクセスしてJavaScriptCSS、画像にまったくアクセスしていない
 ・ ブラウザも設定次第でクッキーやリファラー、画像、JavaScriptなどを切ることができるので
   決めつけるのは早計ですが、そのほかの行動パターンと組み合わせるときの証拠の1つにはなる

参考)
検索ロボットの見分け方[Apache 生ログ]
http://ecsiter.com/bot

最近のスクレイピング対策

アンチスクレイピングサービス

普及して欲しくないアンチスクレイピングサービス
http://happyou-info.hatenablog.com/entry/2014/12/04/005504

・HTML構造を頻繁に変える

やはり普及してはならないアンチスクレイピングサービス
http://happyou-info.hatenablog.com/entry/2016/12/22/002439

・BotDefender
  ・競合他社との価格競争を防ぐ為に、自社サイトの価格表示を
    スクレイピングさせない仕組み

   ・一部情報だけ、別サーバに切り出してJSからAPI経由で取得?(想像です)
   ・HTMLに重要な情報を残さない

  ・CSSでわざと非表示にすることで、スクレイピングしたデータに偽情報を仕込む
  ・ 自社のウェブサイトをヒューマンリーダブルだけどマシンリーダブルにはしない。
   一般のユーザさんには影響がない程度の毒を自社サイトに混ぜることでコピーされるのを防ぐ
   機械お断りというオープンデータとは真逆の流れが生まれてくる

ブラウザの自動化

くだらないAPIなんていらないよ – 2016年のウェブスクレイピング事情
くだらないAPIなんていらないよ – 2016年のウェブスクレイピング事情 | プログラミング | POSTD

・ブラウザの自動化(selenium等)によるスクレイピング
 一番信頼できる。。。

しかし、賢く作り込まれた今どきのサイトを相手にして、インターネットから
データを掘り当てるための信頼できる方法はといえば、ブラウザの自動化だけなのですよねえ。
最近のサイトは、スクレイピングやデータマイニングの試みを阻止するのがうまくなってきました。
AngelListはPhantomJSすら検出してしまいます(今のところ、他のサイトでそこまでの例は見ていません)。
でも、ブラウザ経由での正確なアクションを自動化できたとしたら、サイト側はそれをブロックできるでしょうか?

スクレイピング対策への対処として考えられる方法

アクセスする側の情報を偽装

アクセスする側の情報として、下記がスクレイピングするサイトに渡されます。
これを偽装することで、単純なスクレイピング対策に対処できます。

・アクセスする側の情報

 ・IP / ドメイン
 ・リクエストヘッダ
  ・ユーザエージェント
  ・リファラ
  ・クッキー
  ・ホスト
 等

ユーザエージェントを偽装する

単純ですが、ユーザエージェントを偽装する(ブラウザにする)ことで
ブラウザであると偽装します

リクエストヘッダを偽装する

ブラウザで問題なくアクセスできる場合に、ブラウザでアクセスしたときの
リクエストヘッダを利用して、偽装します。

chromeであれば、デベロッパツールの「ネットワーク」から
リクエストヘッダを取得することが可能です。

クッキー / セッションを取得して利用

・有名なサイトであれば、ブラウザでのアクセスでレスポンスが重くなったけど
 クッキー消したら早くなった等の情報が落ちているかも。

 その場合、サイト内でクッキー / セッションによる処理が走っていて
 有効なクッキー以外はbotとして判定され、処理待ちさせている可能性がある。

・クッキーを継続的にアクセスするときに持たせる

 PHPであれば、guzzleを用いてスクレイピング時のクッキーの取り回しを楽にするとよさそう
 PHP: Guzzle 6 で Cookie を扱う - Sarabande.jp
 [PHP]HTTPクライアントGuzzle6でレスポンスで返されたCookieを取得する | 遊び場

アクセスが人間的か

機械にしかできない動きをしていないか

・同じIPアドレスから、同じユーザーエージェントで大量にアクセスが行われているか
・ 人間らしくないきっちりしすぎるアクセス

・ アクセス元のIPアドレスを集計している
 ・ 何度もアクセスしてきているのに、セッションクッキーを絶対に送ってこない
 ・ リファラーがまったくない

JavascriptCSSが読み込まれない為に重くなるようにしている?

JavascriptCSSスクレイピングで取得できないので、それがbotの判定条件になっている?

ヘッドレスブラウザでのスクレイピングを試してみる。
http://tech.quartetcom.co.jp/2016/04/07/php-phantomjs/


IP制限がかかっている?

普段スクレイピングしないサーバでスクレイピングしてみる

ネットワークの遅延

サイトのスクレイピング対策への対処ではありませんが、
ネットワーク上で遅延が起きている可能性もあるかも?

-bash-4.1# traceroute search.rakuten.co.jp

tracerouteで経路上で時間がかかっているところがないかチェックする。

スクレイピングしようとしているページがそんなにデータ量がなければ
tracerouteでわかるレスポンス時間から、明らかに時間がかかってないかについて
推測できると思います。