■
■Secret computer name API functions (C#)
Secret computer name API functions (C#)
MSDNに出ていないのだそうで。C#とのことですが、そもそもシステム開発とは無縁な私にはこれらの価値がわかりません。DNS names や NetBIOS names あたりをいぢくるAPIfunctionsなのだそうで、XPで使えるとのこと。
関係のありそうなリスト
- Secret computer name API functions (C#) :
- AddLocalAlternateComputerName
- RemoveLocalAlternateComputerName
- SetLocalPrimaryComputerName
- EnumerateLocalComputerNames
- COMPUTER_NAME_TYPE
- Reference:
- Secret computer name API functions
While poking through kernel32.dll recently I stumbled upon an interesting group of API functions introduced in XP, all having to do with primary and alternate computer names. Apparently someone started to document them but then dropped the ball. At least they made it into the platform SDK header files.
■Windows98/98SE/MeへのMS05-002適用で様々な不具合 (その３)
2005/04/13追記
MS05-002ないしKB891711関連を検索してご訪問頂いた方にご案内いたします。当日記の記事、■MS05-002改訂版 for Windows 98、98SE および ME がリリースされました。を是非ご覧下さい。不具合修正の為の改訂版のパッチが出ているようです。
追記：その４もあります。
めぐみとなおみ
MS05-002関連でみかけたのですが、古めのAMDのCPUではのきなみ駄目なのではというウワサが一部でたっていました。サウンドやビデオカードのドライバーとの相性も囁かれており、最新のドライバに置き換えて見ないか？という話も出ているようです。結果は不明です。また、不具合が出るのはダイアルアップユーザに限られるのではというウワサもありました。要するに混乱中なのですが、新しいハードに古いＯＳをのっけてブロードバンドでつなげてTESTをしたとするならば、Micorosoftさんの社内TESTでは現象が出なかったとも考えられます。先行してパッチが出たかもしれない軍関係ではどうだったのでしょうねぇ。
そうだ、めぐみとなおみのお話をしたくて書いているのでした。ほとんどスペックがクリソツな２台のcomputerにmegumiとnaomiという名前をつけて今回の件について調べた人がいて笑いました。どこって、megumiとnaomiだから。素敵だ。さて、結果はどうかと言えば、MS05-002適用にて、めぐみだけがスネてしまっているのです。クリソツなのに。今回の不具合がいかに難しい問題を孕んでいるのかががよくわかる好例です。
しいて言うとMegumiのほうがHardDiskの容量が大きめなのと（こんなの不具合に無関係だわさ）、Grisoft AVG7 搭載ってところがアレなんですけど、アンチウイルスじゃん、これ。関係なさそう。それにしても不思議ですよねぇ。ここまでくると、ハードの相性もさることながら、それ以前に、常駐するKB891711.exeがいつスタートするのかというタイミングだけの問題のような気もしてきました。ハードや追加インストールしているいろんなソフトがKB891711.exeの立ち上がりを遅らせているうちにブルースクリーンになってしまうような気がしますけど。kernelへのフックでつながっているだけのKB891711.exeだと推測されますので、そのへんがアレかなぁと。大胆な予想をするとKB891711.exeがバッファオーバフローしているような気がするんですわ、タイミングが悪くて。知らんけど。おっこちるのはKB891711.exe側ではないけどね。駄目か。
KB891711.exeをkernelの中にもぐらせたものをリリースすれば良かったのではないかとかなり思ったのですがいかがでしょうかねぇ。そうすればタイミングうんぬんはなくなると思います。有償サポートをうけていた企業ユースのみなさんのコンピュータのkernelが一般人のコンピュータのkernelと同一のものであれば出来るはずだと思います。同一でなければ、共通で役に立つ外部の常駐プログラムに見張らせることにした、ということにもなるのですが勘ぐりすぎ？
■exblogでオブジェクトが貼り付けられている
Googleで検索キーを "exblog embed"として検索してみるとなかば公然化していることがわかりますが、Flash等のオブジェクトが自由に張られているようです。私の最近の日記を見ての感想でメールを頂戴しまして、その中でこの事実を教えてもらいました。
embed要素は同ブログでは入力を禁止されているはずです。通常はエラーチェックでひっかかるのです。それなのに何故？
（同ブログ運営開始当初、object要素が禁止されているのにembed要素が禁止されていないことを知った私は運営者にそれはまずいですよと数度メールしましたがまとまな反応は返ってきませんでした。考慮中としか。最近になって同ブログはリニューアルをしたらしく正式にembed要素は禁止するつもりの仕様になったようなのです。）
私にメールを下さった方は、私の与太話、３大ブラウザで動く不思議なJavaScriptソースのお話をごらんになったのでした。このお話自身、実は他のタレコミで知ったのですけれどね。閉じタグがない終了区切り子の無い、例のものです。exblogでは全く同様の仕掛けでembed要素が記述されていたのでした。唖然。
<foo attr="hoge"
こういうのがまかり通っていることがおかしいのだと各ブラウザベンダーにはお願いをしたいところですね。
そして、Webアプリケーション開発者サイドにお願いすることですが、サニタイズを安易に考えて頂いていては困るということです。ひとたび<をみつけたら、<で危険な文字列探索を終了、というのは駄目ですよ、と。<と>とが必ずペアになるはずという教科書的な知識でもってサニタイズすることなぞ、どうかやめてください。たとえば、<script というのを見つけたらその瞬間にやべぇと思ってください。>がないから大丈夫とかいう検査は無能です。頼みます。本当に。
ひとつアイデアがあるのですけれどね。
このhtmlfilterは凄く固いです。思想はというと、まずヘタレなhtml記述を強引に補完するのです。閉じタグないとか。その上でヤバげなものはガンガンとデリします。残ったのは許されたピュアなHTMLなんですけど。これを標準にしたらええと思うんですわ。但し、スタイル要素は禁止ですけどね。スタイル属性は許されているです、はい。普通充分でないですか？リッチな掲示板とか豪華なブログとか、WEBメールとかでは。リスメール系統のナニがこのhtmlfilterを放逐した意図がわかりません。ときどきXSS問題が発生するのはそのせいだろうと思うのですよねぇ。ちなみにhatenaのようにstyle要素を書かせて平気というのは凄く幸せなことなのですよ。HTMLは美しくあらねばならない、という思想があれば脆弱性はかなり軽減されるハズというのが私の信条です。
