/note/tech

スクレイピング・自動化対策について

要約:

■ 1. 自動化悪用の実例と背景

  • 代表的な悪用形態: スクレイピングによる無断データ収集、予約システムを狙ったBot、不正ログイン試行の自動化ツールなど、時代とともに多様化している
  • X(旧Twitter)の詐欺Bot: 詐欺DMを送るBotが今でも多く存在し、毎日被害が発生している
  • 大阪万博の予約問題: サーバーに過度の負荷をかける形で自動化が悪用され、予約システムが混乱した
  • AI利用の巧妙化: 最近はAIを利用した巧妙な自動化も増加している
  • Zennの荒らし事例: 一時期いいね9677、コメント10723になるまで荒らされていた(現在は対処済み)

■ 2. 大阪万博予約における自動化の手法

  • Auto Clicker(Click Assistant): 画面に決められた操作を入力し、プログラムがエミュレート・再現する。ゲームの周回に利用されることが多いが、万博予約でも多用された
  • マクロの利用: PC等で行えるマクロ(pyautoguiなど)も同様の仕組みで、単純な手順で再現できる
  • API直叩き: エンジニア・プログラマーがAPIを解析してPythonやNode.jsなどで自動化を実装
  • サーバーから見た本質: Auto ClickerもAPI利用も、サーバーから見れば同じ自動化である

■ 3. レートリミットの基礎

  • 基本的な効果: 「同じ作業を何度もする」という自動化のニーズに対して、リクエストが通常より早く多くなる特性を利用して検知できる
  • 万博での検知: 万博ウェブサイトも回数/期間で自動化を検知していると考えられ、自動化していないユーザーもBAN報告をしている
  • 一般ユーザーへの影響: 手動で何度も試行を行うユーザーも特定期間内に閾値を超えてBAN状態になる問題がある
  • 限界: 最低限自動化を防ぐことはできるが、実装は簡単である一方で効果が限定的になることも多い

■ 4. レートリミットのアルゴリズム

  • トークンバケット:
    • ユーザーごとにトークンを一定間隔で補充し、残っている間だけリクエストを許可する
    • リクエストごとにトークンを消費し、無くなったら制限を行う
    • Twitchが採用しており、一時的にリクエスト量が増える状態でも対応できる
  • リーキーバケット:
    • 空きが空いたらリクエストを流せるようにする方式で、水の入ったバケツがちょっとずつ漏れていくイメージ
    • リクエストは一定の速度でしか流せない
    • Shopifyが採用しており、処理を一定に保ちたいときに便利
  • 固定ウィンドウカウンタ:
    • 1秒間にN回までと決める方法
    • 実装は簡単だが、期間の切り替わる瞬間にリクエストが集中すると2倍通ってしまう問題がある
  • スライディングウィンドウ:
    • 最新のリクエストを基準に過去一定範囲が閾値を超えないか判定する
    • スライディングウィンドウログ(厳密だがメモリ効率が悪い)とスライディングウィンドウカウンタ(直前の結果から間隔を推定)の2種類がある

■ 5. CAPTCHA

  • 基本機能: 画像認証、パズル、音声認証などで人間とロボットを判別・区別する
  • 代表的サービス: reCAPTCHA、hCaptcha、Cloudflare turnstile(JS Challenge)
  • 効果と問題点: かなり高い精度でBotを弾けるが、ユーザー体験を大きく損なうこともある
  • 突破可能性: Driverや外部サービスを使った突破方法もあるが、攻撃者目線でコストがかかる
  • 推奨: hCaptchaは突破にかかる労力やコストが高い。Cloudflare turnstileはユーザー体験的に良いが突破が比較的簡単
  • 名称の由来: 「Completely Automated Public Turing test to tell Computers and Humans Apart」の略

■ 6. デバイスフィンガープリント

  • 概要: ブラウザや端末の環境情報(User-Agent、フォント、解像度、OSバージョン、Canvasの動作など)を組み合わせて同一環境からのアクセスかを推定する
  • 使用方法: これらを保存して比較することができる(例: bcadc52670c11a5b8789853a6ef178ef)
  • 制限と問題点:
    • Firefoxブラウザーや、AdBlockerなどの拡張機能には防ぐ機能が存在することがある
    • プライバシー的にグレーと言われているため、採用には注意が必要
    • ユニークではないので被ることはある
  • 実装: FingerPrintJSなどのライブラリが利用可能

■ 7. コードのローテーション

  • 基本戦略: コードの難読化を毎日変更したり、共通鍵をローテーションする
  • 効果: イタチごっこにはなるが、攻撃者のコストをかなり上げることができる有効な手段
  • 実例: X(旧Twitter)もこの方法を採用している(x client transaction idで検索可能)

■ 8. ネットワークベースの制御

  • 基本前提: 攻撃者は海外IPを利用していることが多い(VPNやProxyの都合上)
  • 地域制限:
    • 特定の国や地域からのアクセスを制限する
    • 例: 中国のアクセスを遮断、もしくはCAPTCHAを表示するように変更
    • 日本以外からのアクセスを制限することも可能
  • VPN・データセンター判定:
    • VPNは既知の物が多く、串はデータセンターを利用している場合が多い
    • この二つが判定できれば弾くことができる(例: ipinfo.io)
  • Tor制御:
    • Torの串は無料で簡単に使えるので利用している攻撃者も多い
    • Torからのアクセスを遮断あるいはCAPTCHAを行うことで効果が出る
  • 注意点: 正規ユーザーがVPNを使っている場合もあるので誤検知のリスクは残る
  • Cloudflare Enterprise: 機械学習を利用した検知を提供しており、Header "cf-bot-score"にBotの疑いがある数値(2-99)が入る

■ 9. アカウントレベルの制限

  • 新規登録制限: 新規登録直後は利用制限をかける
  • 信頼スコア: 信頼スコアが低いアカウントは厳しいチェックをする(通報などでスコアを下げていく)
  • 認証ハードル: 電話番号や二段階認証でハードルを上げる
  • SMS認証のコスト: 大体1通10円が定価であり、レートリミットは厳重にする必要がある(破産した人も存在する)
  • 行動パターン分析: 「投稿時間が毎日一定である」などサービスの特色に応じた様々な方法が考えられる

■ 10. 番外編の対策手法

  • ハニーポット的手法:
    • 本物の入力フォームとは別に「偽フォーム」を置き、Botだけが入力してしまうようにする
    • 無差別に攻撃を行っているBotにのみ効果があるので注意
    • HTMLのhiddenフィールドに「埋めるべきでない値」を仕込み、入力されたらBot判定する
  • スキャナー対策: Shodanのようなscannerを避けたいなら、/wp-admin/*などのスキャンをトリガーにしてアクセス禁止にする
  • 複合的アプローチの重要性: これらの方法は複数組み合わせてやっと効果が出る。例えば、レートリミットだけでは怪しいIP(海外のProxyなど)を弾けなければ突破される

■ 11. 総合的な防御戦略

  • 多層防御の必要性: 単一の対策では効果が限定的であり、複数の手法を組み合わせることが重要
  • 攻撃者のコスト増加: 各対策の目的は攻撃者をうんざりさせ、攻撃のコストを上げることにある
  • 実装の容易さと効果のバランス: レートリミットは実装が簡単で多くのライブラリが存在するが、CAPTCHAやデバイスフィンガープリントなど、より高度な対策も検討する必要がある
  • プライバシーとセキュリティのバランス: デバイスフィンガープリントなど一部の手法はプライバシー的にグレーゾーンであり、採用には慎重な判断が必要