LSL における XML-RPC のセキュリティ

Second Life サーバと外部のサーバとで通信を行う方法として、
LSL で使用できるのは HTTP, E-mail, XML-RPC などがあります。

この中で、外部からSL内にデータを送信することが可能なのは
E-mail と XML-RPC の二つです。

E-mail は、通信の際に一旦メールサーバを経由するので
リアルタイムな通信を行うことができません。
普段メールを使用するときにおこなうような 受信作業を
LSLで行う必要があるので、「メールが届いた」ということを
自動的に知ることができないのです。

なので、リアルタイムなインバウンド通信を行う手段としては XML-RPC
しかありません。

XML-RPC というのは外部サーバ上の関数を実行するための通信方法の一種で、
XML を用いて実行する関数、パラメタの指定、戻り値の受けとりなどを行います。
SL においては、外部サーバ上から SLサーバ上のスクリプトの remote_data() という関数を
実行することができます。(正確に言うとちょっと違うかもしれませんが、大体そんな感じです)

外部サーバからSLにアクセスできるというのは、なかなか便利で面白そうな機能なのですが、
この XML-RPC を LSL で使用するにあたって重大な問題点が一つあります。
それは、誰が 接続してきたかというのを LSL で判断する方法がないということです。

つまり、正規のクライアントになりすました悪意のある第三者が
自分自身に対して接続を行ってきたとしても、それを判別する方法がありません。
これはセキュリティ上、大きな問題となります。

しかしながら、別の機能制約のおかげで、このことは致命的な問題とは
なっていません。

XML-RPC 通信を行う際には、SLサーバ上の「どのスクリプトに対して
接続を行うのか」というのを、１２８ビットのキーで指定します。
(これは Channel と呼ばれています)

１２８ビットの名前空間というと、軽く１兆を超える
（１兆どころではない天文学的な桁数になります）ほどの数となり、
( 7958661109946400884391936 くらい？ )
でたらめにうっても任意のスクリプトにつながる可能性はかなり低いです。

このキーを知らなくては、任意のスクリプトに対して接続することはできません。
逆にいえば、このキーを知っている＝信頼できる相手だと、一応は
判断できます。（本当ならこれだけで、通信相手を信頼してはいけないです）

つまり、このChannelがパスワード的な役割を果たし、ある程度の
セキュリティは確保されます。

クレジットカードの番号でも、これと同じような形でセキュリティを確保してます。
クレジットカードが番号だけで買い物できるのは、１６桁の連番でない番号を
使用しているので、でたらめに入力しても正規の番号に当たる確率は低いのです。
（最も最近は有効期限や、名前なども確認するところが多いですが）

ただ、SL の XML-RPCでは通信に暗号化されていない HTTP を用いているので、
通信の傍受にたいしては脆弱です。

本当に重要な情報をやり取りする場合には、XML-RPC でやり取りするデータ自身を
暗号化するなどした上で通信を行ったほうが良いでしょう。

ただし、LSLのメモリサイズ制限上、RSA などの複雑なロジックを組むことはできなさそうですが・・・。