Scribble at 2023-07-24 14:56:10 Last modified: unmodified

添付画像

先日、100 GB の Blu-Ray は問題なく焼けて安堵した。そこで、二枚目にも取りかかっているところだ。ISO ファイルを作成するのはもちろん、メディアに記録するときでも、余計な負荷をかけて記録の邪魔をしたくないので、余裕があるときにしか行えない。実はそれほど深刻にならなくてもいいような気はするのだが(実際、何十枚も焼いている 25 GB のメディアだと、極端なことを言えば MMORPG をプレイしながらでも焼けたという事実がある)、100 GB ともなるとメディアが高額商品であるため、失敗はしたくない。

さて、そうして最初に ISO ファイルのイメージを作成しているわけだが、フォルダを指定してファイルを作成し始めると、たいてい上の画面で示したようなエラーが出る。つまり、ファイルを保存している階層が深すぎたり、あるいは(そして)ファイル名が長すぎるために、パスが Juliet などの規格で定められた文字数を超えてしてしまうのである。正直、いまどき何百文字の単位でしかパス名を許容しないなんてショボい規格だなと思うのだが、こういう規格は民生品としてメディアが出回るより何年も前に決まったりするわけなので、当時のテクノロジーやリソースからすれば妥当なところなのだろう。

そもそも、僕らは他にも古臭いテクノロジーを前提にした規格を当たり前のように使っている。たとえば、ファイル名の話にも通じるが、ファイルの「拡張子」なんてものこそ旧時代の発想で決まった仕様なり規格であろう。僕らのように情報セキュリティの実務家という立場で言えば、実行環境やファイルのコンテクストを拡張子で判断するのは非常に危険である。フォームからアップロードできるファイル形式に拡張子を変更して、他の攻撃とセットにして異なるファイル形式のコードとして実行させてしまうといった攻撃手法は昔から知られている。そのため、まともなプログラミングをしている会社では、フォームなどからアップロードされたファイルを受け入れるかどうかにおいて、単に MIME タイプやら拡張子やらだけで判定するわけにはいかない。少なくともバイナリー・ファイルとしてマジック・ナンバー(フォーマット識別子)を確認するくらいの手間は加えるであろう。逆に言えば、拡張子なんて無視してもいいのである。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook