新生鳩丸掲示板♯

>　IE6の話はFTPに限らず、basic認証のパスワードなんかも送られる感じですかね? だとすると「FTPって何?」みたいな人も注意が必要になってくると思うわけですが。

フォームにオートコンプリートで入力されるパスワードも対象だと思われるので、パスワードをブラウザに記憶させているとかなりやばいです。

IE7以降は、フォームが存在するページのURLを暗号化のキーとして使うようになったので、IEが起動していない状態でパスワードを盗むことは困難になったようです。

https://bugzilla.mozilla.org/show_bug.cgi?id=355538

もちろん履歴に入ってるURLで総当たりしてみるとか、ブラウザの起動中ずっと監視し続けるとか、著名なサービスに関してはURLを推測できるとか、いくらでも方法はあるので決して安心してはいけませんが。

>ALFTPもWinSCPも対象であることが判明したので、Gumblar「対策」目的で乗り換えるのはほぼ無駄ですね。

　ですねぇ。

　マルウェア側も日々進化しますしね。

>※でもIE6からの乗り換えは勧めてほしいかも

　IE6の話はFTPに限らず、basic認証のパスワードなんかも送られる感じですかね? だとすると「FTPって何?」みたいな人も注意が必要になってくると思うわけですが。

ALFTPもWinSCPも対象であることが判明したので、Gumblar「対策」目的で乗り換えるのはほぼ無駄ですね。まあ最初から分かっていたことではありますが。

http://www.jpcert.or.jp/at/2010/at100005.txt

※でもIE6からの乗り換えは勧めてほしいかも

> そう考えると、「マルウェアに感染したら駄目」という当たり前の話になってきますね。

そもそも発端となった感染実験

http://www.smilebanana.com/archives/2010/01/23-2158.php

も、Windows XPのSP3をアンインストールまでして故意に脆弱な環境を作り出して、ようやく感染させたそうですしね。

http://www.smilebanana.com/archives/2010/01/14-1912.php

こんにちは、初めて投稿させていただきます。

> というかこれ本当に経済産業省のサイトなんでしょうか?

http://after-ideabox.net/

は、経済産業省の当該企画のブログによれば、サイト内の全コンテンツの責任は経済産業省にあるが、サイトは経済産業省のものではないそうです。

http://d.hatena.ne.jp/ideaboxFU/20100101/1262335333

まあ、完璧に経済産業省のサイトである

http://www.no-trouble.jp/

なんてのもありますけどね。

>サッズ好きなのにここで用いられていないのに少し切なさを感じましたが

　悲しいことに、サッズには「ラストリーヴ」が無いという欠点があるのですよね……。

　主要ロール以外も取った場合、エンハンサーとしてもファングに負け気味になってきたりして、サッズがやたら冷遇されている気がするのは私だけでしょうか。

# あと、ケアルダ×2の回復力を重視したのでホープになっています。

# 強くなってくればサッズでも問題ないはず。

>個人的には今作のモンスターのレベルの意味を知りたい。

　私も知りたいです。

　アルティマニアには出るのでしょうかね。

サッズ好きなのにここで用いられていないのに少し切なさを感じましたが興味深く読みました。

自分はウェルキンゲトリクスやラクタヴィージャなどは燃えました。

バイオがないと厳しい強敵いますね。

ところでロングイはグラフィックや設定から判断すると老亀かもしれません。エルダーというか。

しばらくFF13をやっていなかったように見受けられますが、攻略サイトでもあまり掲載されていないような未知の連鎖アビリティを活用した面白い戦術もありそうですね。

みやぶるでも表示されないお宝とか。

個人的には今作のモンスターのレベルの意味を知りたい。お祈りしてるガチャコッコみたいなのが1だったり、一部ボスなど60を越えるクラスはブレイクできなかったりと、耐性と関係あるような気もします。

>> go.jp.baker.jp

　ぅは。修正しておきました。

> go.jp.baker.jp

開設者の皆様【誰】には、h1（レベル1の見出し要素）に「bakera.jp」が付いていることを確認した上で、公開頂くようお願い申し上げます【謎】。

>としか書いてなくてどこに「go.jp」をつけてもいいようにみえるので、たとえば「http://bakera.jp/#go.jp」とかでも良さそうに思えます。

http://go.jp.bakera.jp

# 勢いだけ :-)

>政府機関のサイトならドメイン名の末尾に.go.jpが付いているはずです、とか言い切れればいいのですが、

http://www.cao.go.jp/sasshin/hatomimi/20100112kokuminnokoe.html には

> 利用者の皆様には、『ハトミミ.com「国民の声」』のURL（ホームページのアドレス）に「go.jp」が付いていることを確認した上で、ご利用頂くようお願い申し上げます。

としか書いてなくてどこに「go.jp」をつけてもいいようにみえるので、たとえば「http://bakera.jp/#go.jp」とかでも良さそうに思えます。

政府機関のサイトならドメイン名の末尾に.go.jpが付いているはずです、とか言い切れればいいのですが、

http://after-ideabox.net/

みたいなことを平然とされるのでどうしようもありません。というかこれ本当に経済産業省のサイトなんでしょうか?

https://after-ideabox.net/

でアクセスするとGPKIの証明書ですらないオレオレ証明書が出てくるし。

強いガラハドなんか、ガラハドじゃない…！

さっさとサクッとブチ殺されるのが奴のアイデンティティのはずなのに…！

>そもそも固有IDを用いていないPC用Webブラウザでは完璧に対策する必要がないからでしょうか。

そうですはないですか?ローカルネットワークに対する攻撃は、LAN側のDNSキャッシュサーバーで対策する、インターネット側のサーバーは元々問題はおきにくいからということで。

奥一穂さんの以下のエントリが参考になると思います。

http://labs.cybozu.co.jp/blog/kazuho/archives/2007/11/djbdns_and_anti-dns_pinning.php

http://b.hatena.ne.jp/kazuhooku/20071112#bookmark-6474799

iframe内での遷移かどうかは判別していますが、pinを保持するかどうかの判定には用いていないようです。単にDNSのTTLを無視して一定期間名前解決の結果を保持しているだけです。

そもそも固有IDを用いていないPC用Webブラウザでは完璧に対策する必要がないからでしょうか。

> 遷移した方は破棄する

遷移のタイミングで無条件に破棄するのは問題ありませんか? 「少なくとも遷移するまで破棄しない」ならともかく。

>>iframeでの遷移なども考えられるので、単に「ページ単位」の処理ではうまくいかないケースもありそうに思うのですが。

>ブラウザはページがiframe内に読み込まれているかどうかを判別できます

　実際にiframe内での遷移はどう扱われるのでしょうか?

　たとえば、

・あるページにiframeが2つあって、同じコンテンツを読み込んでいる

・うち、片方のみで遷移が起こった

　という状況のとき、遷移していないほうは従前の情報をpinningし続け、遷移した方は破棄することになるのでしょうか。

　それはそれで想定外のことが起きそうな気もするのですが……。

>ふと思ったのですが、普通のWebブラウザなどではどういう処理になっているのでしょう……?

>iframeでの遷移なども考えられるので、単に「ページ単位」の処理ではうまくいかないケースもありそうに思うのですが。

ブラウザはページがiframe内に読み込まれているかどうかを判別できますし、サードパーティーCookieの判定などのために実際に判別していますが、ゲートウェイはそうではありません。

ゲートウェイでの対応が困難なのは、正しく判別するにはゲートウェイの知り得ない情報が必要だからだということです。

ありがとうございます。理解できたような気がします。「ページ単位」というのは範囲の話というより、時間の話ということですね。

pinningしている時間を、

「名前解決が行われてから、次のページ遷移が行われるまでの間」

とする感じでしょうか。

ふと思ったのですが、普通のWebブラウザなどではどういう処理になっているのでしょう……?

iframeでの遷移なども考えられるので、単に「ページ単位」の処理ではうまくいかないケースもありそうに思うのですが。

ご説明ありがとうございます。よく理解できました。

仰るとおり、ゲートウエイ側のTTLを長くすることが、良いリスク低減策だと思います。

>[5676]で「ドメイン」と「ホスト名」の表現はいずれも「FQDN」のことを指しているという理解で良いですか？

はい。それで良いです。説明が悪くてすいません。具体例で説明します。

http://example.jp/a.htmlから、XMLHttpRequestによりa001.xml、a002.xml、a003.xmlを呼び出すとします。同様に、/b.htmlからb001.xml…b003.xml、/c.htmlから、c001.xml…c003.xmlを呼ぶと仮定します。以下では、a.htmlからb.htmlに遷移する状況でIPアドレスを変更するタイミングが来た状況を使って説明します。

このようなサイトで、exmaple.jpに割り当てられたIPアドレスを「変更して良い」タイミングは、a.htmlからb.htmlに遷移した瞬間（b.htmlのリクエストを処理する瞬間）です。a.htmlのリクエストからa001.xml…a003.xmlを呼び出すタイミングや、b.htmlからb001.xml…b003.xmlを呼び出すタイミングで変更を許すと、DNS Rebindingが発生します。

しかし、ゲートウェイ(PROXY)では、この「FQDNに割り当てられたIPアドレスを変更して良いタイミング」が分かりません。

さらに、マルチユーザを想定すると、ユーザ毎（端末毎）に「FQDNに割り当てられたIPアドレスを変更して良いタイミング」は異なることになります。

通常のPROXYには、そのような複雑な機能はないと認識しています。それができるのは、ブラウザが名前解決をしている場合です。携帯電話の場合は、ゲートウェイが名前解決をしているので、DNS Pinningはできないと考えます。