このところどうも暗号づいてます。Java ですと簡単に暗号化が利用できるのもあって、「暗号」というものの利用法をいろいろと考えるのですが、特に Web アプリの場合には、単に「読まれない」というだけではない利用法があるように感じています。

というのは、

平文と対立する意味での「暗号文」を、勝手に第３者がそれらしく偽造することができない。

 というメリットじゃないか、ということなんですね。要するに「電子署名」で作られた「署名」は、これを作ることができるは本当にその暗号鍵を持っている人だけである、というのと同様なメリットです。

ですから、暗号化されたキーを解読して、それが意味の通った内容であるかどうか、をチェックすることで、そのリクエストの正当性を保証する、というような使い方があるようにも感じるわけです。

たとえば、Web アプリとそれ以外のサービスを組み合わせて使う場合（とか Servlet でもコンテキストが違う場合）、セッションを共有させるができませんから、何らかの手段で互いを紐づける必要があるわけです。この時に、単なる ID で相互に紐付けた場合、悪戯心（悪意まではいかなくてもね）のあるユーザが、「その前後の番号を入れたらどうなるの？？」と、手入力でそういう ID を入れて実験してみる可能性を否定できないわけです。

勿論セッションキーは「使われていない番号が圧倒的に多い巨大な数値」ですから、こういう「手入力でセッションキーを入れてみて大当たり」という可能性が極端に少ないわけですが、アプリ側で相互のデータ紐づけに使う　ID の場合、意外に脆弱な値を使っていることもあります。たとえば、

ウェブアプリへの入り口はこちらへどうぞ！ http://web.app.jp/context?user=yamada@mydomain.jp

というような文の埋め込まれたメールを、yamada@mydomain.jp 氏に送った場合、ひょっとして yamada@mydomain.jp 氏は

http://web.app.jp/context?user=myfriend@mydomain.jp

でトライするかもしれません！

この時、user の引数である「yamada@mydomain.jp」 を何らかのやり方で暗号化して、 

http://web.app.jp/context?user=31dIWa7lHSOWE

というかたちになっているだけで、こういうトライを未然に防止できるわけです。

たとえば、この暗号の中に「有効期限」を含ませて暗号化すれば、「期限切れ」というようなかたちで再利用を防止することもできます。ここまでやるとほとんどセッションＩＤみたいな使い方になりますよね。

あるいは、「これをイジられたら他人の情報が見えちゃう」というキーなりＩＤは、たとえばフォームの中にあるかもしれませんし、あるいはクッキーの中にあるかもしれません。もし、悪意あるプログラマが「弱点を衝いてやる！」とリクエストを解析した時には、こういう一般ユーザは意識しないデータでさえ、侵入の糸口になるかもしれないわけです。

一般論として内部的な管理データ（ＩＤ）を外部に晒すのは良いことではありません。そういう内部データを保護するために、暗号を使うというのが私の場合一番頻繁に使う使い方...なのは、歪んでるかなぁ？？