マジかよ!? 主要ブラウザを完全再現する禁断のcurl爆誕！
引用元：https://news.ycombinator.com/item?id=43571099
このプロジェクトのフォーク版があって、オリジナルより改善されてて、めっちゃメンテナンスもされてるよ！ ＞https://github.com/lexiforest/curl-impersonate Python使ってる人向けには、フォーク版のPythonバインディングもあるよ！ ＞https://github.com/lexiforest/curl_cffi
“curl”をブラウザっぽく見せるプログラムが、ボット検出回避サービスにスポンサーされてるってのは、なんか納得できる気がするわ…
簡単じゃん。クライアントでトークンを生成する小さなフラグメントシェーダー作ればいいんだよ。ボットはシェーダーをコンパイルするためにGPUリソースなんて使わないって。
なんでみんなそう思うんだろ？ ボットって今はほとんどヘッドフルなブラウザ使ってるじゃん。人間がキーボードでアクセスできるなら、ボットだってできるって。
セキュリティ対策って、全ての悪用を防げるわけじゃないんだよね。悪用のコストを、許容できるレベル以上に上げるってこと。掃除が汚れを全部なくせないけど、許容範囲以下に薄めるのと同じ。 ”repairing”とか”defects”とかもそう。
それってCAPTCHAと同じ理屈じゃん。ボットが文句言うわけないけど、人間としては、自分が人間だって証明しなきゃいけないせいで、めっちゃ面倒になってるんだよね。
データの取り込みを楽にすると、データ作成が大変になることが多い。広告主のために最適化するのはお金になるけど、顧客はもっと上の存在だし。
サイトがロードされた後にフラグメントシェーダーを実行するのが、そんなに難しいことなの？
マジレスすると、なんで“curl”を許可しないの？ 広告収入のため？ それともしょぼいレート制限？ サービス使いたいのに。フラグメントシェーダーを用意してくれるならいいけど、そいつは犬のエサにするわ。変なハードウェアをブラウザに繋げたくない。
普通の人間ユーザーだけにサーバーを使わせたいんだよね。JavaScriptが無効になってるなら、いなくても困らない。ごめんね。
ここでは“Curl”ボットの話をしてるんだよ。あなたの言ってることは関係なくない？
いやいや、nyanpasu64のコメントは、一般的なボット検出の話に広がってるじゃん。
swiftshaderみたいなソフトウェアレンダラーを使えばいいんじゃないの？ virtioとかでGPUを渡す必要ないじゃん。
サポートされてないWebGL拡張を呼び出せるかもね。もしくは、クアッドを何回かオーバードローするとか。ボットは処理するだろうけど、CPUをめっちゃ消費すると思うよ。
それって、PoWシステムに余計な手順を足したようなもんじゃない？
まさにPoWシステムだけど、手順が少ないバージョンだよ。ほとんどのボットはGPUの処理できないからね。できるボットもいるけど、それはそれでいいんじゃない。
俺のハードウェアを勝手に使うなよ。お前のサーバーのために、俺のデジタルな家で勝手にいじくり回すのは、自己矛盾してるってことだよ。お前は自分のハードウェアの神聖さを大切にしてるけど、俺のはどうでもいいんだな。お前はまさに問題の一部みたいなこと言ってるぞ。
1回のblit処理のためにフラグメントシェーダを動かすくらいで、機械の神聖さが損なわれるなんてことないと思うけど。Chromeの方がGPUをめっちゃ使ってるよ。気になるならJavaScriptを切ればいいじゃん。誰も困らないって。
適当なこと言うのやめてくれ。それに、間違ってるよ。最近のまともなスクレイピングは全部ブラウザ使ってるから。
ボットが本物のトークンをいくつか集めて、シェーダーを実行する代わりにそれを送ればいいんじゃない？
それをどうやって自動化するんだ？毎日新しいトークンを生成すればいいじゃん。
リプレイアタックってマジで簡単に自動化できるよね でもクライアントごとにトークン発行して解決してるんじゃないの？ Pythonのrequestsライブラリと完全連携できるモジュールもあるよ。→ https://github.com/el1s7/curl-adapter こんなに早く変わるテクノロジーについていけない… 普通のブラウザに見せかけるためだけに、サーバーの負担が増えるってどうなの？90年代に警告された悪夢の未来？ これを引き起こしてる会社は、オープンソースの貢献者として良いやつぶってるけどね。 Ladybirdに期待してる。今はcURL使ってるけど、WebSocket over h2とか課題があるかも。でも、Ladybirdが普及すれば、cURLと同じフィンガープリントになるから、フィンガープリンティング対策になるかもね。 LadybirdのcURLの利用がcURL自体の改善につながるといいね。WebSocket over h2とか。cURLに足りない機能を洗い出す良い機会にもなると思う。 フィンガープリンティング対策になるって言ってるけど、CloudFlareとか見てると逆だよ。実装依存の挙動を利用したフィンガープリンティングがめっちゃ増えてる。他のブラウザエンジンを排除しようとしてるんじゃない？「AI botのDDoS攻撃」とか言ってるけど、自作自演かもね… CloudFlareなら、普通のブラウザとbotを区別できるはずだよ。chrome/edge/safari/firefoxとbotを区別できるのと同じようにね。でも、あえてやってないんじゃない？ え、仲間はずれが…？悪質なbotが大量発生してコストが100倍になったのをwebマスターのせいにするの？ ＞ Are we really blaming… それ見たんだけど、どう関係するのかまだピンとこないんだよね。「敵は”AI botがDDoS攻撃してる”って言いふらそうとしてるけど、それって自作自演なんじゃね？」って話。 ”their own” ＝ CloudFlareとか、インターネット閉鎖に利権持ってる連中のことじゃね？ サイトの作りがヘボいからコストが100倍になっただけじゃん。 ちょっと聞きたいんだけど、コストを100倍にせずにトラフィックを100倍にする方法って何？例えば、レシピページに写真数枚表示するのに0.0000000001ドルくらいかかるじゃん。それを100倍表示したらコストも上がるんじゃないの？ スケールアップはするかもだけど、効率的にやってれば最初から余裕持って準備してるはずだよ。計算コストはキャッシュで最小限に抑えられるし、帯域幅も大手クラウドじゃなければ安いし。例えば、dangによるとHNはシングルサーバーで動いてるのに、HNに投稿されてトラフィックが少し増えただけでダウンするサイトもあるじゃん。 ブラウザエンジンを潰そうとしてるわけじゃないと思うな。ブラウザを”ユーザー”と”AIのカス”に分けようとして、ユーザーを優先したいんだよ。これは完全にweb crawler 2.0の黙示録だよ。 マジで食料品買ってくれるbotが欲しい。 家を出る理由の数少ないうちの一つじゃん。俺はまず皿洗いと洗濯botが欲しいな。 食洗機と洗濯機のこと？ まあ、そうだけど、そうじゃないって感じかな。ロボットにロードとアンロードしてほしいんだよね。 もう10年以上も近所のコインランドリーにお願いしてるけど、想像してるより安いと思うし、マジで価値あるよ。 うちの家族は6人だから、洗濯機を1日に3回回すのも珍しくないし、少なくとも1回は回さない日なんてほとんどないんだよね。便利さは想像できるけど、この規模だとちょっと現実的じゃないかな。食洗機も毎日少なくとも1回は回すし、旅行してない限りは8割以上埋まってるよ。 「slop」って言葉は、生成AIシステムの出力に対してだけ使われると思うな。botとかcrawlerとかscraperとかspiderの方が、データ収集のために（過剰な）リクエストを送るソフトウェアを表すのには適切だと思う。 この人たち[0]と話した時に、署名（TCPスタックのことも含む）を作るような特性とか弱点について触れたんだよね。このcurlは大好きだけど、何か一つのコンポーネントが「追いつく」ためにごまかしの役割を担うと、メンテナンスが難しい「互換性」の遺産が蓄積されるんじゃないかって心配。理想的には「やあ、curlだよ、入れてくれ」って言うべきだよね。問題は、ドレスコードにうるさいサーバーにあるってことで、その問題はさらに、変装して侵入する悪党によって引き起こされるっていう、鶏と卵みたいな話なんだよね。[0]https://cybershow.uk/episodes.php?id=39 ＞理想的には「やあ、curlだよ、入れてくれ」って言うべきだよね マジそれな！プロトコルはクライアントの詳細に縛られるべきじゃない。「User Agent」文字列って一体どこから来たんだ？ 代わりにChromeがフィンガープリントをあんまり送信しないようにするべきなんだよ。そうすればサイトはフィンガープリントできなくなる。でもそれはないだろうね。Googleの利益に反するから。 これはTLSフィンガープリントの仕組みを根本的に誤解してるね。「フィンガープリント」は、ChromeがTLSネゴシエーションのたびに「fingerprint: [random uuid]」みたいな属性を送ってるからじゃないんだよ。それは、どんな暗号を受け入れられるかとか、TLSスタックの様々な特性から導き出されるんだ。Chromeがフィンガープリントを送るのを止めるなんてできないんだよ。全てのブラウザが同じTLSスタックに合意しない限りね。ユーザーが設定できるTLSスタックの側面はほとんどないから、すでに最小限なんだよ。Chromeは独自のものをバンドルしてるから、全てのChromeユーザーは同じTLSフィンガープリントを持つはずなんだ。それが本当に役立つのは、「偽物の」Chromeユーザー（例えば、カスタムヘッダーを設定したcurlとか、User Agentスプーファーを使ったFirefoxユーザー）を「本物の」Chromeユーザーと区別することだけなんだ。 えーマジ？ciphersを安全マージン込みで既知の使えるリストに固定すれば良くね？ユーザーごとに違うcipherが必要とかありえないっしょ fingerprintの一部は拡張機能の順序とかだけど、Chromeは簡単にできるのにやってないんだよね。GoogleのPlay StoreがTLS fingerprintingの最大の原因の一つらしいよ。 Chromeはもう2年前からClientHelloの拡張順序をランダム化してるよ。[0] 責められるべきはfingerprinting技術を使ってる企業と、そのサービスに頼ってる企業だよ（ウェブの大部分がそう）。例えばChromeの変更後、Cloudflareは順序をチェックしないfingerprinterに乗り換えた。[1] ＞fingerprinting技術を使ってる企業が悪いって言うけどさ ＞脆弱性を悪用する人を責めるのは違うって言うけどさ 大規模な問題と戦ったことがないんだね。問題は小規模なクローラーじゃなくて、大規模な攻撃者だよ。トラフィックが一定量を超えたらブロックするしかない。でも、ほとんどの条件は簡単に偽装できるんだ。 ＞fingerprinting技術を使ってる企業が悪いって言うけどさ スクレイパーの苦情でよくあるのが100gib/月だけど、それって300kbpsでしょ？IP transitに1ドルもかからないし、computeもほぼ0円。ブロックしなければ、数個のIPしか使わないし、制限すればバックオフするよ。 サイトによってはもっと酷い状況もあるよ。例えばJonathan Corbetのレポート[0]を見てみて。 rachelbytheebayがブログが荒らされてるって最近書いてなかったっけ？ データ返すのに計算が必要かどうか分かんないのに、どうやって計算コストがゼロって言えるんだ？ これってLadybirdがftp URLをサポートするってことかなー？ 昔は“cURL”って呼んでたけど、公式にはcurlが正しいんだよね？ “See-URL”ってこと？ずっとcurlって呼んでたけど、“see url”ってのもめっちゃ理にかなってる！今まで考えたことなかったし、声に出して言うことないもんね。 IP_TTLも設定して、なりすますプラットフォームに合わせてTTL値も設定してる？してないと、IPレイヤーでフィンガープリント取られるかも。TTL値が64未満だと、最近のWindowsじゃないか、TTLが変更されたWindowsだってバレる。TTLはWindowsだと128から、他のプラットフォームだと64から始まるからね。 ＞さっきも言ったけど、IPレイヤーでのフィンガープリントは難しいけど不可能じゃないよ。 TLSとかHTTPのフィンガープリントに比べて難しいって意味ね。berkeley socket APIじゃ情報が出てこないし、raw socket使って自分でTCPスタックを実装しないと。 入ってくるトラフィックを監視して、パケットをコネクションに関連付ければ良くない？自分でTCPやるのはナンセンスでしょ。 うん、パケットミラーリングの設定（例えばiptablesとかスイッチレベルで）とパケットキャプチャツールがあれば十分。あとはパケットキャプチャプログラム/マシンからのデータをロードバランサーと、src ip + port + timeでjoinするだけ。 受信したパケットのTTL値って、ネットワークの状態に左右されない？サーバー側からクライアントの値を復元できるの？ TTLが64のパケット送って問題ないなら、ネットのどこでも64ホップ以内で届くってことじゃね？個人的には32ホップ超えるルートがあるかすら怪しいけど。 Windows 9xはTTL32だったらしい。ごく稀なケースで問題あったとか聞いた気がするけど、ガセかも。でも99.999%は32で十分だと思う。これを利用してTTLでfingerprintingできるかもね。Windows 9xとかOpenSolaris使ってる人ほぼいないから、最近のシステムの値でfingerprintingは可能だって主張してる。 なんでTTLってカウントアップじゃなくてカウントダウンなの？ルーティングはルーターが決めるべきじゃないの？ 送信者がTTLを設定できるようにするためじゃね？パケットヘッダーにフィールド追加せずに済むし。 TTLの主な目的は、パケットがルーティング中に無限ループするのを防ぐこと。ループにハマるとTTLがゼロになって破棄される。 それ質問の答えになってない。カウントアップなら、各ホップが自分のポリシーを設定できるじゃん。それでも無限ループは防げるでしょ。 もしルーターが好き勝手にTTLを低く設定したら、ユーザーはどうすることもできないじゃん。一応、ある値より低いトラフィックを捨てることはできるけど。ルーターが勝手にポリシー設定したら、ネットワークトラフィックが根本的に壊れる可能性がある。 適当だけど、初期のインターネットはナイーブに作られたから、送信者が一番長く使える時間とか、いつ再起動/失敗させるかをよく知ってるからTTLを設定するんじゃない？ tracerouteは、パケットを送るたびにTTLを1ずつ増やしていくから実現可能になる。カウントアップだと無理だよね。まあ、max-hopsから数を減らしていくこともできるけど。いろんなデバイスが色んな上限持ってるとデバッグが面倒。 医者に余命128日って言われたらカウントダウンするでしょ？TTLも同じで、time to live（寿命）ってこと。 どっちかっていうと、これって「生放送」みたいなもんだよねー。名前はアレだけど、時間とは関係ないし。 ちょっと待って…TLSハンドシェイクが違うってことは、nginxレベルで、Chromeのユーザーエージェントを名乗るけど、実はPythonとかPHPスクリプトのトラフィックをフィルタリングできるってこと？それめっちゃ良くない？悪質なボットトラフィックの大半をブロックできるじゃん！もっとコメントを表示（1）
いや、最近フィンガープリンティング/ブラウザプロファイリングが増えてて、シェアの低いブラウザにどう影響するかを議論してるんだよ。
俺は、敵＝fingerprinters、that＝AI botのDDoS攻撃、their own＝webmasters、hosting providers、CDN（つまりfingerprinters）って読んでて、fingerprintersがDDoS攻撃の責任者みたいに聞こえるんだよね。でも、その解釈だと他の部分と合わない気がするんだ。なんかいい解釈ない？もっとコメントを表示（2）
え？理想的には「GET /path/to/page」って言うべきでしょ。User Agentを送るなんてありえない。どんなソースからであれ、そんなことすべきじゃない。
脆弱性を悪用する人を責めるのは違うと思うな。悪用はもちろん良くないけど、悪用される状態にあること自体が問題じゃん。
悪用はもちろん良くないけど、悪用される状態にあること自体が問題じゃん。
「脆弱性」と「データを安全に転送するための複雑なプロトコルの固有の性質」は違うんだよね。metadataはクライアントによって異なる可能性があるけど、それは標準の範囲内。もしそのmetadataで差別するなら、それは新しい独自のプロトコルを発明したのと同じ。UA stringみたいに、既存のブラウザのネットワークスタックをリバースエンジニアリングしないと同じユーザー体験が得られない。
・IP：IPv6なら簡単
・UA：基本
・SSL fingerprint：簡単
・IP stack fingerprint：簡単
・request/session tokens：簡単
ログイン必須にしても、スパムアカウントが大量に作られるだけ。detectionに使った時点で、そのsignalは使えなくなるし、効果測定もできなくなる。FAANGでこの問題を解決したけど、簡単だなんて言ってる人はマジでわかってない。
それは悲劇だよね。でもbotの状況とリソースの乱用を見れば、相手側の視点も理解できると思うよ。
さっきの会話でも言ったけど、行動fingerprintingに焦点を当てるべきだって話になったんだ。ブラウザ/agentだけでなく、何をするかに注目するべき。
自作ブログしてる人も言ってるし、Wikipediaもトラフィックの半分以上がbotだって言ってるよ。これって現実の問題じゃないって言うの？もっとコメントを表示（3）
まぁIPレイヤーでのフィンガープリントは難しいけど。
PaaS/IaaSプロバイダーがTCP/IPスタックへの低レベルアクセスを許可しない場合のみ。自前のサーバーを運用してれば、あらゆるTCP/IPプロパティのフィンガープリントを簡単に取得できるよ。
https://en.wikipedia.org/wiki/TCP/IP_stack_fingerprinting
どこでも64ホップ以内なら、TTL128で送ったパケットは、他のシステムで捨てられる前に64以上で届くっしょ。
カウントアップだと、どこまで上げていいか毎回パケットに含める必要がある。じゃないと、ネットワーク全体で同じTTLを使うか、ルーターのTTLに従うしかない。カウントダウンなら、常にゼロと比較するだけ。
