アカウント名:
パスワード:
セキュリティ的には大文字小文字を区別しないと不利なんじゃなかったっけ? 理由はわからん。 何かで見た。
最初から小文字だけとか大文字だけしか受け付けないとかいう設計にすればよかったんじゃね? そうすればデジタル化!で、英語でも大文字か小文字が廃止されていたかもしれん。 FAXは古い、的ノリで。
インジェクションでcmd.exeを置き換えてcmd.exe の自動実行をすげ替えるとき、区別だと呼び出し cmd.exe に対して CmD.eXE とかは反応しないけど、Windowsだとしちゃうね。んでインジェクション検知の正規表現マッチングで grep -i みたいにしないといけないし、Perlなら[A-Z][a-z] しないといけない。パターンがザルだとくぐり抜けられちゃう。多分そういうことだと思う
そういう脆弱性は良くありますね。特に、Unix向けに開発されたソフトウェアをWindowsに移植した場合にね。CWE-178: Improper Handling of Case Sensitivityhttps://cwe.mitre.org/data/definitions/178.html [mitre.org]
あと、8.3形式や代替ストリームの事を忘れてるパターンも良く有る。IPA ISEC セキュア・プログラミング講座:C/C++言語編 第9章 ファイル対策:ファイルの別名検査 [ipa.go.jp]
逆に、WindowsのソフトウェアをLinuxに移植した場合、symlinkの扱いが雑でsymlink attackを踏むのもあるある
[A-Za-z]と書きたかったんだろうけど、もしそうしたとしても今度はCP932の第2バイトの問題が発生してしまうのでPerlではなくてJPerlを使う必要がある。
物理ファイルにアクセスできる可能性が増えるからじゃね。AAAAAAAA.EXEとaaaaaaaa.exeが区別されないなら、1tryで2patternのattackしたのと等価になる。
>最初から小文字だけとか大文字だけしか受け付けないとかいう設計にすればよかったんじゃね?MS-DOSは小文字を受け付けませんでした。小文字で指定してもファイルは大文字で作成される。
仕事を持って帰って、家のX68kで作業してうっかり小文字で保存したまま会社に持って行って、ファイルにアクセスできなかった時はどうしようかと思いました。
幸いにもFDで「名前の変更」→即確定で大文字に出来たので事なきを得ましたが。FILMTNでは駄目でした。
>MS-DOSは小文字を受け付けませんでした。小文字で指定してもファイルは大文字で作成される。 なんとなく、システムファイルは小文字、ユーザーファイルは大文字にすれば、面白いと思った。そうすれば、ユーザーがシステム予約で作
まあファイル名で区別しないと不便だよね
コンピュータ側はIDだろうと何でもいいけど人間が番号だけで理解できるとは思えないのですが?
別に番号だけを使う必要はない。 ファイルを一意に特定するのに、ファイル名を使う必要はない、と思っているだけ。 人間向けには名前を別に付ければいい。でも、それをIDとしては使わない。
MS-DOS時代のPC-98向けOASYS互換ワープロがそんな作りだった。ファイル名に不自由しない現代では意味があるとは思えない。
ファイル名はなんか256バイトくらいの手打ち文字列なので、そんなもんをキーにするのはおかしいという発想には同意できるものもないでしょうか。はしご高とかファイル名がエスケープシーケンスみたいなエッジケースもありますし。
同意できる点もなくはないが、内部のIDを知らないとファイルを一意に指定できないのって実用的に困ったりしない? TRONのファイルを開くダイアログに相当するものってユーザーはどうやって同名のファイルを区別できるようになってたの?
人間がファイルを指定したいときのために人間にも扱いやすい一意の識別名としてファイル名が存在するのだと思うんだけど。人間向けの名前をID扱いできなかったら、人間が指そうとしているファイルの特定がめんどくさくなるじゃないか。
ファイルIDは16ビットなんだよな。
自分が作ったファイルだけを扱う分にはどうでもいいことだが、他人がよこしたのが混じると大文字小文字違いの同名ファイルができて面倒なことになったね、何度か。
BTRON2は?
パーソナルメディアにファイルシステムを作り直す能力はないからBTRON1のを流用した。パーソナルメディアに能力がないからできないのではない、仕様だということにするためにああいう仕様にしたんじゃないかな。
BTRON3仕様が出る何年も前にパーソナルメディアがBTRON2仕様OSを実装したことになってたけど、それから30年たってもリリースされない。
パーソナルメディアが新製品を出すと、同日にTRON文字収録センターで突如として(公式に定義されているレビュープロセスやらなにやらすっ飛ばして)GT書体の文字追加が発表されるのはウケたな。
BTRON3は、BTRON1.1のことだから大きな変更はできなかったんよ。
同じだろ。BTRON3でファイルIDが16ビットなのは、それだけあれば十分という理由だそうだから。十分ではないと思っているなら20年以上放置するのはまずいし。
同時に「文字コードは16ビットで十分だ」という主張に反対してなければ話を聞いてやる余地もあるんだが。組込機器ならまだしもPC向けのBTRONでファイルIDが16ビットで足りるわけがない。20年前ですら実身数が足りなければパーティションを分ければいいとか馬鹿なこと言ってたのに
AAAAAAAa.EXEAAAAAAaA.EXE
も区別されないので 2^8 tryになるのでは?
セキュリティな話をするなら大文字小文字対応テーブルはファイルシステム上にあるってのがホント気持ち悪いんだよな https://dfir.ru/2021/07/15/playing-with-case-insensitive-file-names/
APFSもUnicodeバージョンが上がってmacOSがそれに対応するたびに使用可能な文字種が変わるとかいうクソみたいな仕様じゃなかったっけ。正規化の仕様を固定していいるHFS+のほうがなんぼかマシだった
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
セキュリティ的には (スコア:0)
セキュリティ的には大文字小文字を区別しないと不利なんじゃなかったっけ? 理由はわからん。 何かで見た。
最初から小文字だけとか大文字だけしか受け付けないとかいう設計にすればよかったんじゃね? そうすればデジタル化!で、英語でも大文字か小文字が廃止されていたかもしれん。 FAXは古い、的ノリで。
Re:セキュリティ的には (スコア:1)
インジェクションでcmd.exeを置き換えてcmd.exe の自動実行をすげ替えるとき、区別だと呼び出し cmd.exe に対して CmD.eXE とかは反応しないけど、Windowsだとしちゃうね。んでインジェクション検知の正規表現マッチングで grep -i みたいにしないといけないし、Perlなら[A-Z][a-z] しないといけない。パターンがザルだとくぐり抜けられちゃう。多分そういうことだと思う
Re:セキュリティ的には (スコア:2, 参考になる)
そういう脆弱性は良くありますね。
特に、Unix向けに開発されたソフトウェアをWindowsに移植した場合にね。
CWE-178: Improper Handling of Case Sensitivity
https://cwe.mitre.org/data/definitions/178.html [mitre.org]
Re: (スコア:0)
あと、8.3形式や代替ストリームの事を忘れてるパターンも良く有る。
IPA ISEC セキュア・プログラミング講座:C/C++言語編 第9章 ファイル対策:ファイルの別名検査 [ipa.go.jp]
Re: (スコア:0)
逆に、WindowsのソフトウェアをLinuxに移植した場合、symlinkの扱いが雑でsymlink attackを踏むのもあるある
Re: (スコア:0)
[A-Za-z]と書きたかったんだろうけど、もしそうしたとしても今度はCP932の第2バイトの問題が発生してしまうのでPerlではなくてJPerlを使う必要がある。
Re: (スコア:0)
物理ファイルにアクセスできる可能性が増えるからじゃね。
AAAAAAAA.EXEとaaaaaaaa.exeが区別されないなら、1tryで2patternのattackしたのと等価になる。
>最初から小文字だけとか大文字だけしか受け付けないとかいう設計にすればよかったんじゃね?
MS-DOSは小文字を受け付けませんでした。小文字で指定してもファイルは大文字で作成される。
Re:セキュリティ的には (スコア:1)
仕事を持って帰って、家のX68kで作業してうっかり小文字で保存したまま会社に持って行って、
ファイルにアクセスできなかった時はどうしようかと思いました。
幸いにもFDで「名前の変更」→即確定で大文字に出来たので事なきを得ましたが。
FILMTNでは駄目でした。
Re: (スコア:0)
>MS-DOSは小文字を受け付けませんでした。小文字で指定してもファイルは大文字で作成される。 なんとなく、システムファイルは小文字、ユーザーファイルは大文字にすれば、面白いと思った。そうすれば、ユーザーがシステム予約で作
Re: Re:セキュリティ的には (スコア:1)
Re: (スコア:0)
まあファイル名で区別しないと不便だよね
Re: (スコア:0)
コンピュータ側はIDだろうと何でもいいけど人間が番号だけで理解できるとは思えないのですが?
Re: (スコア:0)
別に番号だけを使う必要はない。 ファイルを一意に特定するのに、ファイル名を使う必要はない、と思っているだけ。 人間向けには名前を別に付ければいい。でも、それをIDとしては使わない。
Re: (スコア:0)
MS-DOS時代のPC-98向けOASYS互換ワープロがそんな作りだった。
ファイル名に不自由しない現代では意味があるとは思えない。
Re: Re: Re:セキュリティ的には (スコア:2)
ファイル名はなんか256バイトくらいの手打ち文字列なので、そんなもんをキーにするのはおかしいという発想には同意できるものもないでしょうか。はしご高とかファイル名がエスケープシーケンスみたいなエッジケースもありますし。
Re: (スコア:0)
同意できる点もなくはないが、内部のIDを知らないとファイルを一意に指定できないのって実用的に困ったりしない? TRONのファイルを開くダイアログに相当するものってユーザーはどうやって同名のファイルを区別できるようになってたの?
Re: (スコア:0)
人間がファイルを指定したいときのために人間にも扱いやすい一意の識別名としてファイル名が存在するのだと思うんだけど。
人間向けの名前をID扱いできなかったら、人間が指そうとしているファイルの特定がめんどくさくなるじゃないか。
Re: (スコア:0)
ファイルIDは16ビットなんだよな。
自分が作ったファイルだけを扱う分にはどうでもいいことだが、他人がよこしたのが混じると大文字小文字違いの同名ファイルができて面倒なことになったね、何度か。
Re: (スコア:0)
BTRON2は?
Re: (スコア:0)
パーソナルメディアにファイルシステムを作り直す能力はないからBTRON1のを流用した。
パーソナルメディアに能力がないからできないのではない、仕様だということにする
ためにああいう仕様にしたんじゃないかな。
BTRON3仕様が出る何年も前にパーソナルメディアがBTRON2仕様OSを実装したことに
なってたけど、それから30年たってもリリースされない。
Re: (スコア:0)
パーソナルメディアが新製品を出すと、同日にTRON文字収録センターで突如として(公式に定義されているレビュープロセスやらなにやらすっ飛ばして)GT書体の文字追加が発表されるのはウケたな。
Re: (スコア:0)
BTRON3は、BTRON1.1のことだから大きな変更はできなかったんよ。
Re: (スコア:0)
同じだろ。
BTRON3でファイルIDが16ビットなのは、それだけあれば十分という理由だそうだから。
十分ではないと思っているなら20年以上放置するのはまずいし。
Re: (スコア:0)
同時に「文字コードは16ビットで十分だ」という主張に反対してなければ話を聞いてやる余地もあるんだが。組込機器ならまだしもPC向けのBTRONでファイルIDが16ビットで足りるわけがない。20年前ですら実身数が足りなければパーティションを分ければいいとか馬鹿なこと言ってたのに
Re: (スコア:0)
Re: (スコア:0)
AAAAAAAa.EXE
AAAAAAaA.EXE
も区別されないので 2^8 tryになるのでは?
Re: (スコア:0)
セキュリティな話をするなら大文字小文字対応テーブルはファイルシステム上にあるってのがホント気持ち悪いんだよな https://dfir.ru/2021/07/15/playing-with-case-insensitive-file-names/
Re: (スコア:0)
APFSもUnicodeバージョンが上がってmacOSがそれに対応するたびに使用可能な文字種が変わるとかいうクソみたいな仕様じゃなかったっけ。正規化の仕様を固定していいるHFS+のほうがなんぼかマシだった