Scribble at 2022-09-30 14:44:13 Last modified: 2022-09-30 14:50:07
情報セキュリティのマネージャとしては利用してもらいたくないのだが、「短縮URL」というものは一定のニーズがあるのも確かで、メール・マーケティングでは DM を送信するときに ad network が発行する長いクエリ文字列を URL にぶら下げたくないという事情があったりする。また、サービス・サイトの運営部門でも、GA/Tag manager が発行するクエリ文字列をアンカー・タグの値ならともかく、メールの本文に
https://somedomain.com/?utm_source=service&utm_medium=sv&utm_campaign=sales
などと貼り付けて URL を紹介するのは嫌だという要求がありえる。
もちろん、他人が発行する短縮 URL は信用できない。フィッシング・サイトへ飛ばされる可能性があるし、悪意が無くても短縮 URL を運営するサービスのサーバを経由することになるため、途中でどういうデータを抜かれるか分かったものではない。最後は au/KDDI のページや読売新聞の記事であることに変わりはなくても、途中の経路で ad network のサーバを通って情報を提供してよいなどというオプト・インを実装しているサイトは少ない（全くないわけではなく、行政などでは外部のサーバへアクセスすることを事前に承諾してもらうようなページを挟んでいることがある）。
とは言っても、自社のサービスであれ短縮 URL にアクセスする不安と、長い URL や長いクエリ文字列を並べた URL にアクセスする不安とを考慮すれば、その双方を解決する手段として HTML メールが採用される事情も分かる話ではある。HTML メールを使えば、どこへアクセスするのであろうとメールの受信者には「見えない」から、HTML メールの URL をクリックするということ自体に不安を感じる人でない限りは、長いクエリ文字列も短縮 URL も関係なくなるし、そもそも HTML メールでアンカー文字列をクリックしてもらえばいいなら短縮 URL なんて最初から使わなくてもいい。
そういうわけで、僕は昔から短縮 URL も HTML メールも、情報セキュリティに気を付けたい受信者にとっては避けるべきものであると啓発しているが、サラリーマンというものはサービス提供者とサービスの受益者・利用者という立場が変われば、同一人物であってもサービスについての考え方が変わってしまうものだ。情報セキュリティの技術者が往々にして初歩的なソーシャル・ハッキングの被害に遭ったり、メール・マーケティングの本まで書いている人物が実生活では HTML メールを絶対に使わないとか、そういうことはよくある。
ということで、僕も個人情報保護のマネジメントや情報セキュリティのマネジメントを担っている一人ではあるが、営利企業の distinguished（あるいは divine とすら言われたこともあるが）developer として、短縮 URL の実装を色々と考えて試験的に実装してきた経緯がある。もちろん、２年ほど前に現実の受託案件で某家電メーカーのスクラッチ・キャンペーン用に実装したこともある。SMS のように文字数が限られている媒体を使うには仕方のないことだし、事前にそういう短縮 URL（というか、短縮 URL の信頼性が乏しい本質的な理由は FQDN にあるわけだが）を使うと告知してあるという条件は必要だが。
考え方は非常に簡単である。まず最初に、FQDN は DNS を利用するから変更しようがないため、これはあらかじめ短い文字数のドメインを取得しておくとする。仮に domain.com としておこう。そして、短縮 URL としては https://domain.com/foobar という形式が最も短くて望ましい形式と言える。"https://domain.com/" というルートまでの文字列はどうしようもないが（メールの本文からブラウザへと URL の処理が関連付けされていれば、"domain.com/foobar" でもいいのかもしれないが、あまり多くを期待しすぎてもいけない）、ルートから後は好きにできる。
まず、ウェブ・サーバのアプリケーションに URL の書き換えを設定し、Apache であれば mod_rewrite でルート直下の DirectoryIndex にあたるファイルは除外して、それ以外を全て redirect.php に URL の書き換えで転送し、なおかつルート以下の文字列を全て "query" というクエリの値として書き換える。（もちろんだが、転送先の redirect.php も URL 書き換えの対象から除外しないと無限ループになってしまう。）
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_URI} !(index|redirect)\.php$
RewriteRule ^(.+)$ redirect.php?query=$1 [NC,L,R]
あとは、受け取った側の redirect.php でクエリ文字列を処理するだけである。GA/tag manager のクエリ文字列を付けて更に他のページへ転送してもいいし、redirect.php で本来の目的である何らかの処理を完結してもいい。
こういうわけで、短縮 URL を実装する際の要点はユニークな文字列として発行される "PU3ZxZy0" のようなランダムな文字列ではなく、ウェブ・サーバ側での設定、そして発行した "PU3ZxZy0" という文字列の中でどれが正規で有効な文字列なのかというルールを決めて実装することだ。
文字列の仕様そのものは、かなり単純であろう。たいていどこのサービスでも８桁前後の文字列で済ませている筈だ。
・英小文字
・英大文字
・数字
以上の三つの文字種を使って８桁の文字列を作るという仕様だけでも、短期的な利用という目的なら十分と言えるパターンの数を確保できる。実際に計算してみれば分かるが、英小文字（26文字）＋英大文字（26文字）＋数字（10文字）＝62文字だから、８桁の文字列として可能なパターンの合計は62の８乗であるから、218,340,105,584,896、約218兆3401億個の文字列が使える。日本の国民１人に１個ずつ割り当てても、一人あたり200万個くらいの文字列が使える。そもそも１回のキャンペーンでユニークな文字列や ID やシリアル・ナンバーを200兆個どころか数億個も払い出すなんて事例は、アリババや Amazon の大売り出しとか僅かな事例を除けば地球上に殆どないはずである。
あとは、発行した文字列をデータベースに登録し、登録済の文字列かどうかを検索したり、その有効期限について確認するといった、馬鹿でも実装できるフローを追加すれば、本当のところ短縮 URL なんて簡単に実装できる。それこそ、ひととおりのプログラミングと DBMS への接続方法を教えた段階の学生に開発させる実習課題のようなレベルのシステムであろう。