すべての無料プロキシを信頼できないインフラとして扱うこと。なぜなら、実際にそうだからだ。運営者は匿名であり、資金調達モデルは不明瞭で、同じソケットが1週間のうちにボットネット、侵害されたホームルーター、研究者のハニーポットを経由する可能性もある。だからといって無料プロキシが使えないわけではない——いくつかの習慣を絶対条件にする必要があるだけだ。
よくある攻撃
脅威は劇的なものではない。ほとんどのユーザーが防御しようとしないために成功する、退屈な種類の攻撃である。
平文HTTPでの認証情報の窃取。 http://経由で未知のプロキシを通して何かにログインすると、運営者にパスワードが見えてしまう。常にCONNECT経由でTLSをトンネリングするか、HTTPSを強制する宛先に対してSOCKSを使用すること。最近のログインフローは主要サイトではHTTPSのみだが、レガシーなイントラネット、IoT管理画面、古いCMSのデプロイメントはそうではない。
ヘッダーとコンテンツのインジェクション。 悪意のあるHTTPプロキシはリクエストの任意の部分を書き換えることができる。Cookieの変更、リファラのすり替え、トラッキングパラメータの注入、キャッシュヘッダーの除去などだ。同じプロキシはレスポンスにコンテンツを注入することもできる——HTMLへのスクリプト、JSONへのリダイレクト、静的ページへの広告など。プロキシ経由でサーバーサイドのレスポンスを読み取る場合、信頼できる経路から整合性を検証できるまでは、それらが侵害されているものとして扱うこと。
SOCKS5によるDNSハイジャック。 SOCKS5はプロキシ側でホスト名を解決できる。プロキシがDNSレコードについて嘘をつくと、運営者の管理するサーバーに接続することになる。可能な限りクライアント側でローカル解決を行う設定にすること。curl --resolve example.com:443:93.184.216.34、またはコード内ではホスト名ではなくIPアドレスを渡す。
トラフィックのログ記録。 善意のプロキシであっても、取得したすべてのURLをログに記録する可能性がある。「この人物がどのURLをリクエストしたか」が脅威モデルに含まれる場合、公開プロキシはすべて誤ったツールである。Torか、公開されたノーログポリシーと異議申し立てを受けた召喚状の実績がある有料VPNを使用すること。
クライアントに対するリソース枯渇。 一部のプロキシは意図的に接続を低速にしたり、非常に大きなレスポンスを返したり、データを送信せずにソケットを開いたままにしたりする。クライアント側で厳格なレスポンスサイズ制限と接続タイムアウトを設定すること。
防御策（優先順位順）
すべての通信をCONNECT経由のTLS内に収めるか、SOCKS経由でHTTPS宛先に送信すること。公開プロキシの背後で、他の場所で使い回すような認証情報を決して再利用しないこと。証明書は厳格に検証すること——カジュアルな利用には発行元のピン留めは過剰だが、任意のチェーンを受け入れるのは無謀である。接続と読み取りに短いタイムアウトを設定すること。ワークロードが重要な場合は、フォレンジックレビューのためにプロキシのレスポンスをログに記録すること。頻繁にローテーションすること。5分前に動作していたプロキシが、今も同じプロキシであるとは限らない。
無料プロキシが実際に有用な用途
3つのカテゴリの作業が、そのノイズを正当化する。地理的なコンテンツバリエーションのテスト：CDNはフランクフルトとサンパウロで正しいページを配信しているか？ 公開・未認証データのスクレイピング：検索エンジンの結果、IP単位のレート制限がない公開API、すでに他でインデックスされているコンテンツ。アプリケーションが、ターゲットにとって未知のアウトバウンドIPに対して正しく動作することを確認する——IPベースの不正ヒューリスティックを持つシステムのQAに有用。
それらの用途に使うこと。失敗率を受け入れること。失いたくないものをその背後に置かないこと。