例えば，Railsの入力のセキュリティ対策はセキュアであるとは言えません。Railsのバリデーションは「データベースにデータが保存される前」に行われます。データベースにデータを保存する必要がないようなアプリケーションの場合，入力のバリデーションをフレームワークとして行う仕組みになっていません。本来入力はデータベース利用の有無に関わらず入力を受け入れた直後に行うべきです。多くのフレームワークがRailsの影響を受け同様の仕様となっています。Railsが脆弱な仕様を採用したことは不幸なことだったと思います。 ……。 まず、バリデーションはセキュリティのためにする処理ではありません。たまたまセキュリティの役に立つこともありますが、役に立たないこともあります。たとえば、問い合わせフォームに本文の入力欄があり、任意のテキストが入力できて、DBにはText型 (任意の長さの任意のテキスト) として保存

公開: 2011年9月25日11時25分頃 librahack方面がまた盛り上がっていますね。吹田市立図書館が謎の「サイバー攻撃」を受けたという話が出ているようで。 （図書館へのサイバー攻撃） ９月１６日から２日間ほど、岐阜県を発信ポイントとするサイバー攻撃を吹田市立図書館が受けていました。ポイントは岐阜県になっていましたが、そこが経由地なのか実際の発信地なのかも特定できていないような説明を受けました。１秒間に５回アクセスされるような攻撃だったようですが、それで吹田市立図書館側のサーバがアクセス困難に陥ったのでした。 政治的な意図があってのことではない（愉快犯）だと思いますが、当該期間にアクセスできなかった市民には多大な迷惑が掛かりました。市は警察へ対応を申し出ています。 ※（追記）；ファイヤーウォールを云々・・・という箇所を削除しました。当該記事は吹田市ＣＩＯ（情報の最高責任者）から説明

公開: 2011年7月11日2時10分頃 secure.softbank.ne.jpが廃止されたことに伴い、なぜ廃止しなければならなかったのか、その背景についての解説が相次いで公開されています。 secure.softbank.ne.jp ヤバイの話 (subtech.g.hatena.ne.jp)SoftBankガラケーの致命的な脆弱性がようやく解消 (takagi-hiromitsu.jp)ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る (blog.tokumaru.org)secure.softbank.ne.jp ヤバイの話+ (subtech.g.hatena.ne.jp)先月まで、ソフトバンクのケータイサイトで https://example.com/ へのリンクを辿ろうとすると、以下のような動作になっていました。 ソフトバンクのケータイでサイトにアクセスすると、ゲートウ

公開: 2011年7月15日2時10分頃 これは驚きました……「モバイルバンキングは今でもsecure.softbank.ne.jp方式が主流 (d.hatena.ne.jp)」。 以下は、ログイン画面のURLがhttps://secure.softbank.ne.jp/～となっています。大手都市銀行は全てという感じです。 三井住友銀行三菱東京UFJ銀行みずほ銀行りそな銀行セブン銀行じぶん銀行住信SBIネット銀行楽天銀行新生銀行secure.softbank.ne.jpはホワイトリスト方式で残されるということでしたが、上記モバイルバンキングは、そのホワイトリストの対象なのでしょう。 なんということでしょう。 7月からは、secure.softbank.ne.jpで表示されるのは公式サイトのみ (かつ、ソフトバンクに申請したサイトのみ) になりましたから、公式サイトと無関係の者が罠コンテンツ

更新: 2011年7月9日23時0分頃 とあるシステムで徳丸本のストレッチングを採用することにしたという話がありましたが、その実装が佳境に入ってきました。私は指示だけ出して、実装はお任せ……と思っていたのですが、基本的な部分を作ってもらったところでバトンタッチされ、私が引き継ぐ形で実際にコードを書くことになりました。 基本的には徳丸本 (www.amazon.co.jp)のオススメどおりの実装にするという方針なのですが、実際にコードを書いてみると、いろいろと気になったり迷ったりした事も出てきました。そのあたりを簡単にメモしておきます。 ※ちなみに、このシステムはRuby1.9.2 + Ruby on Rails3での実装なので、PHPのコードサンプルをそのまま使っているわけではありません。 ストレッチ回数をどう決めるのか徳丸本327ページにあるコード例を参考にして実装。アプリケーションごと

SSLは盗聴では解読は困難ですが、MIM(Man In the Middle:中間者攻撃)を行えば、通信の内容は平文で取り出すことが可能です。 (～中略～) これまでネット家電やゲーム機では「外部からの攻撃」に対して対策が取られていました。また、ネット家電やゲーム機が直接侵入されたり踏み台にされたりしないような対策ということが論じられてきました。しかし、サーバーとの通信を密に行うようなケースでは、サーバーとの通信の2重の暗号化などの総合的な対策が必要とされます。 これはちょっとわかりにくい記事だと思いました。 まず、普通の利用者が普通に利用する際に中間者攻撃が問題になることはないはずです。サーバ証明書を検証することによって中間者攻撃を防ぐ仕組みがありますので、普通の利用者は中間者攻撃を恐れる必要はありません (PS3 (www.amazon.co.jp)自体に脆弱性がなければの話ですが)。

公開: 2010年10月1日18時25分頃 国勢調査ですが、今年から一部地域 (東京都) のみオンラインで回答できるようになったそうで……「国勢調査オンライン ( トップ画面 ) (e-kokusei.go.jp)」。 私も一部地域に該当しているため、せっかくだからということでオンライン回答を体験してみました。以下、気づいたことや直してほしいと思った点をつれづれにメモ。 国勢調査の封筒にはがきっぽい案内が同封されていて、IDとパスワードのようなものが書かれています。「フィッシングにご注意」などと結構しつこく書いてありますが、そのわりにトップページはHTTPSでない模様。アドレスバーを確認してください、ということでアドレスバーの画像が掲載されているのですが、なぜかこのアドレスバーの画像が間違っています。画像ではURLが http://e-kokusei.go.jp となっていますが、これは正

JIS規格表の公開についてJIS規格表が無料では公開されていないという主旨の説明をしましたが、以下のサイトで閲覧することができます。 日本工業標準調査会：データベース検索-JIS検索 (www.jisc.go.jp)ただし、ここでできるのは閲覧のみです。ダウンロードして保存することはできませんし、印刷もできませんし、文字をテキストとしてコピーすることもできません。しかも、閲覧するにはAdobe ReaderのJavaScriptを有効にしなければなりません。 ※セキュリティ上の理由により、Adobe ReaderのJavaScriptの機能は無効にすることが推奨されています。 これは非常に不便ですので、やはり実用のためには規格表を購入することをお勧めしますが、「無料では公開されていない」という説明は事実に反するものでした。お詫びして訂正いたします。 RFCの状態を確認する方法についてRFC

公開: 2010年6月14日23時40分頃 ソフトバンクのiPhone用アプリ「電波チェッカー (mb.softbank.jp)」に関して、こんなお話が。 iPhoneアプリ「電波チェッカー」がUDIDを送信していることへの問い合わせまとめ (togetter.com)電波チェッカーに関してソフトバンクモバイル宮川CTOに「じゃあ説明するから来社して下さいよ」と誘われた件 (togetter.com)iPhoneアプリ「電波チェッカー」がUDID偽装可能だったことが発覚してからのまとめ (togetter.com)言うまでもありませんが、これは、最近議論されているケータイサイトのセキュリティ問題に関連する話です。実際に多数のサービスに問題が発見されている状況があり、電波チェッカーはそれと同じことをしているように見える……という話の流れがあります。togetterのコメントを見ていると、流れ

公開: 2009年7月15日18時50分頃 「携帯電話向けWebアプリのセッション管理はどうなっているか (d.hatena.ne.jp)」。 PHP×携帯サイト 実践アプリケーション集 (www.amazon.co.jp)のアプリケーションが、ことごとく個体識別番号に依存した作りになっているらしいというお話。携帯電話向けサイトでは、Cookie非対応端末のために、セッションIDがURLに含まれるという作りが一般的です。が、この本ではそういうことはしないで、アクセスごとに個体識別番号を見る設計になっているのだそうで。 個体識別番号に依存した認証については、高木さんの「無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者 (takagi-hiromitsu.jp)」でも問題が指摘されていますが、ここではさらに「標準的なセキュリテイ対策手法が使用できない」ことが指摘

公開: 2009年6月24日15時20分頃 「XMLをparseするアプリのセキュリティ (d.hatena.ne.jp)」。 以前に書いたXML entity explosion attackの話の最後の方でもちらりと触れましたが、外部からXMLを受け取るとき、パーサが外部実体を解釈するとまずいことになる場合があります。 サーバから外部の任意のURLにGETアクセスしてしまうため、踏み台として使われる危険性がある受け取ったXMLの内容を何らかの形で表示している場合、本来外部から見えないはずのリソースの内容が見えてしまう場合があるということですね。特に後者の場合、ディレクトリ・トラバーサルよろしく、サーバ内の任意のファイルの内容が見えてしまう可能性があるので注意が必要です。 SOAPなどで外部からXMLを受け取るAPIは良くあると思いますが、外部からやってきたXMLをパースする際は、DTD