タグ別アーカイブ: セキュリティ

2013-12
10
00:23:28
SQLインジェクション対策で大垣靖男氏は何を勘違いしていたか


以下のTogetterでまとめて頂いているが、大垣靖男氏と「何故氏はSQLインジェクション対策においてプリペアドステートメントの利用よりも入力データのエスケープ処理を優先するのか」について議論させて頂いた。

SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論

僕の疑問は一番最初の方にもあるが、「プリペアドステートメント+プレースホルダーで複雑な自作エスケープなどせずともシンプルにさほどの技術力も無く少なくとも『SQLインジェクション対策』としては機能するのに、何故そこまでエスケープ処理対応を一義に拘るのか」という点だった。

この優先順位度合いは以下のブログの部分からも明らかだ。

出力先のシステムが同じでも、出力先が異なる、を意識する

実際の開発に利用するコーディングルールでは出力先によって「API > エスケープ > バリデーション」の順番になる場合もありますが、セキュリティを維持するための重要度は「エスケープ > API > バリデーション」であることは変わりません

さて経緯は上記Togetterに譲るが、結論として何故氏はそのような無謀な主張を延々繰り返すか、氷解したような気がする。
少しツイートもしたが誤解があるかも知れないのでもう少し詳しく説明しておきたい。またこれは以外に面白い視点も内包しているかも知れない。

Continue reading

2013-09
04
06:44:48
ワンタイムパスワードの送付先にケータイメールは相応しくない


近年大手のWEBサービスも含めて所謂リスト攻撃などで不正ログインが多発するなどしており、一躍注目を集めているのが二要素認証(二段階認証)だ。通常のユーザーID/パスワードでの認証に加えて、その一時にだけ有効なワンタイムパスワード(OTP/One Time Password)を発行しこれも一致しないとログインを認めない方法である。
このワンタイムパスワードの発行方法またはユーザーへの送付方法には幾つかのパターンがある。
最も「厳しい」物理的なハードウェアトークンをユーザー毎に配布して表示される番号をワンタイムパスワードとして入力する方法(Paypalでの例)や、より簡易にスマホなどのソフトウェアでワンタイムパスワードを確認できる方法(有名なソフトウェアとしてはGoogle Authenticatorなどがある。但しサービスがこれらのソフトへ対応していないといけない)のほか、もっとも一般的には「ユーザーが別途指定したメールアドレスへワンタイムパスワードをメールする」方法がある。

ワンタイムパスワード自体は二要素認証のためだけの方法でも無い。ログイン時だけでは無く、例えば銀行サイトで他口座への振込などの資金移動をする際にワンタイムパスワードの設定をしていなければ操作できなくしている銀行も多い。これもまた近年高まっているセキュリティ保護の機運を反映したものだろう。

最近ではスマホなどモバイル環境の一般化によってか、「メールアドレスへのワンタイムパスワードの送付」パターンの場合にはPC用メールアドレスでは無く「ケータイメール」(すなわち携帯キャリアが提供しているメール)への送信を強く要請してくるようになった。
例えば三菱東京UFJ銀行や楽天銀行では最近になって「携帯メールでの登録」を勧める旨の記載が増えた。

三菱東京UFJ銀行 / インターネットバンキングのログイン時の本人確認方法を一部追加します。(平成24年2月12日(日)より)

楽天銀行 / セキュリティ強化のためのワンタイム認証のルール変更について

一方以下はGoogleでの二要素認証設定時の様子だ。ワンタイムパスワードの取得方法としてGoogle Authenticatorを使用することも出来るが、デフォルトではこのように各携帯キャリアのメールアドレスを指定することになっており、設定後は信頼できない端末からのログインの際はこのアドレスへワンタイムパスワードが送られる。

スクリーンショット 2013-08-02 5.19.49

前述の通り幾つかのバリエーションはあるものの、これらの例のように近年ではワンタイムパスワードは「ケータイメール」へ送付することが大変一般的になってきたと感じるし、実際多くの方がそのようにされているのでは無いだろうか。

しかしながらPCメールなどよりも「ケータイメール」をワンタイムパスワードの入手元とすることは果たして「より安全」な方法だろうか。

Continue reading

2011-07
02
01:55:07
オープン化への変貌とキャリアの隠蔽体質を考える – secure.softbank.ne.jpの問題を受けて


7月になってsecure.softbank.ne.jpという一種のSSLプロキシの廃止を受けて、高木さんと徳丸さんから続けて背景説明のエントリーが発表されている。

SoftBankガラケーの致命的な脆弱性がようやく解消
ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る

簡単に言えばこのSSLプロキシの廃止は重大なセキュリティリスクを回避するために絶対的に必要だったと言うことなのだが、詳細はぜひ上記を参照して欲しい。

正直に言うと、この高木さんとソフトバンクモバイル宮川氏のやり取りの前に少しきっかけに関わったので興味を持ってみていたのだが、当初は発端となったアプリ側でのCookieの取り扱いにくさ以上の感触を得ていなかった。
それが違うなと思い直したのは両名が7月を前に盛り上がりだしてからで(笑)、それが同一生成元ポリシーに関わる問題であろうことはその後すぐ気付いた。
しかし実は水面下では、端末のJavaScriptを調整してsecure.softbank.ne.jpでの挙動のみ変更したいたことなどは今回のエントリーで始めて知った次第だ。
アクロバティックな対応だなと思うし、非常に感じるのはこれまで閉塞した世界でなら何も考えずとも良かった問題がJavaScriptやあるいは通信路の解放などといった「オープン化」によって大きく揺らいで行くであろう未来の姿だ。

先のエントリーで徳丸氏は以下のように述べている。

この事例から言えることは、(ガラパゴスと表現されることもある)日本の携帯Web独自の仕様というのものが非常にきわどく、もろいものだということです。

 

携帯Webの仕様がオープンにならないことも問題です。私は前述のJavaScript等の仕様を調べるために、公開されている仕様書だけでは十分でないために、実機での試行錯誤が必要でした。携帯Webの安全性確保のため、開発者やセキュリティ研究者に向けた十分な情報開示を希望します。

僕も全く同意見だ。
そもそもの問題はあまりに日本のケータイWEBがガラパゴスと言われるような独自進化をし、それはクローズドだったからまだよかったものの、ここへ来てスマートフォンに始まり、JavaScriptなどブラウザがリッチ化しOSはAndroidなどよりオープンなもの(逆に言えばキャリアやメーカーが手を加えにくい) となり、また通信路はWi-Fiや定められた端末しか繋げられない閉塞したものではなくPCなどと同居するよりオープンなものへと変貌しつつある。
日本のケータイシーンはただ端末がガラケーからスマートフォンへ置き換えられているだけではない。技術的な観点からすると「一般的なインターネット」へ変貌つつある。

問題はそうした急速な変化の中で果たしてキャリアはこうした旧世代の脆い仕様との乖離に伴う脆弱性に正しく対応可能なのか、ということだ。

少し古い話になるのだが、実は半年ほど前個人的に一ユーザーとして各キャリアに以下のような質問を行ってみた。

1. 具体例は示しませんが、近年携帯電話やスマートフォンに関して、セキュリティ上の脆弱性がネットなどで指摘されることが多くなってきました。
この1年間において御社にて脆弱性が発覚または発見しこれを修正などの対策をされた実績がありますか。ある場合、もし宜しければ具体例をお教え下さい。
2. 1のケースに関わらず、一般論で結構なのですが御社では脆弱性が発覚した場合修正し対応なさいますか。対応する/しないの判断基準はどの点だと認識していらっしゃいますか。
3. その場合、脆弱性があった旨ユーザーに情報を開示されますか。
4. 御社にてこうした脆弱性対応のためのポリシーを策定し運用されていらっしゃいますか。またそれは公開されユーザーへ周知されていらっしゃいますか。

各社様々経緯があり返答に時間もかかり結局一ヶ月近くかかった覚えがあるのだが、簡単にまとめると各社の回答は以下のようなものだった。

質問事項 脆弱性が発覚または発見しこれを修正などの対策をされた実績はあるか 脆弱性が発覚した場合修正し対応するか。対応する/しないの判断基準はどの点だと認識しているか 脆弱性があった旨ユーザーに情報を開示するか 脆弱性対応のためのポリシーを策定し運用しているか。またそれは公開されユーザーへ周知されているか
ドコモ 特に回答無し – ウィルス対策、パターン更新などの対策を行っている
– 対策の判断基準は脆弱性の程度や影響などを総合的に判断
– お客様にお伝えできる情報は弊社ウェブサイト等にて公開させていただきますことをご了承ください 特に回答無し
au – 脆弱性事例はあり(最近の例を例示) – システムに脆弱性があることについて事実確認されアップデートによって脆弱性が解消できることが判明した場合には必ずWEBサイトで告知を実施した上でアップデート対応を実施する – セキュリティに関わる問題については悪用される危険性があるため詳細な内容については公表しない。但し該当ユーザーについては個別に周知している 特に回答無し
ソフトバンク 弊社の機密事項に関するものとなるで社外への情報開示はWEBサイトで公開している内容のみでそれ以外は答えられない
イーモバイル 特に回答無し 特に回答無し – お客様に影響を及ぼす問題が発見された場合には、すみやかに情報を開示し対策を実施することとしています。
情報の開示方法は、弊社ホームページ上に掲載するケースや、
個別にご連絡する場合など案件によって最適な方法で実施いたします。
特に回答無し

 

多少の違いはあるが、どれも判で押したような特に具体性のない内容であることは間違いないだろう。
注目すべきはどこのキャリアも回答には数週間から一ヶ月かかっている、つまりあらかじめ想定している内容ではなく、 社内調整した結果の回答であったのだろう。それは脆弱性ポリシーの有無の質問に対していずれも明確な回答がなかったことからも察しが付く。
つまりは各社とも今回のような脆弱性への対処については明確な社内規定やルールがあり運用されている訳ではなく、発覚した場合のケースバイケースということなのではないだろうか。
これは一言で言って常に対処が後手に回り対処療法に陥りやすい危険な兆候とも言えるだろう。

「フルディスクロージャ」という言葉がある。これは「脆弱性情報を隠蔽しこれを知り得ている一部の悪意あるユーザーに悪用されるよりは、脆弱性情報を発見したらすぐに広くオープンにして全てのユーザーに完全に周知した方が安全だ」という考え方だ。
これはこれで極端な考え方で、例えば0Dayアタックと呼ばれるような一般ユーザーにこのような脆弱性から守る術を持たないうちから攻撃されるリスクが十分あるからだ。
そこまで極端なフルディスクロージャーは近年では採用されることは少ないが、しかし一方で上記のようなキャリアの態度というのは、これまた極端な「隠蔽体質」と言われても仕方ないだろう。

しかし実はこのフルディスクロージャーの考え方には、インターネット黎明期に脆弱性の隠蔽が頻繁に行われ、その結果被害が拡大した結果、反省と反発からの一種の極論から生まれたという背景がある。

キャリアが理解しているかどうかは分からない。しかし僕にはこれまでのキャリアは閉塞網と完全に制御された端末でのうのうと暮らしてきた「井の中の蛙」に見える。
スマートフォンの伸長は歴史の針を一気に進め、蛙を大海へ叩き込んだ、とも言えるだろう。
彼らが今後暮らさなければならない「本当のインターネット」の大海では、脆弱性情報は共有され適切に管理され、インターネット全体の安全性のバランスを取る仕組みと常識感が既に熟成されている。それはインターネットの巨大なプレーヤーとしてはほぼ責務と言っていい。 だがそんな「本当のインターネットでの常識」に付いていけるだけの力を身に付けられているだろうか。僕は甚だ疑問だ。

キャリア各社は今後スマートフォンへ軸足を移し、また「普通のインターネット」を提供したいと発言している。一方で各キャリア毎に課金・認証の仕組みを導入しようとしており、ドコモはiモードを、auはau one IDをすでにAndroidに組み込んでいるようだ。
けれど彼らは本当にそれらがインターネットの大海でどういう意味を持つか理解して実現できるだろうか。
僕はこうした脆弱性ポリシーや、インターネットでは当たり前の技術情報の周知1つ出来ていない現状では結局同じことを繰り返し、更に酷いセキュリティ問題を繰り広げる未来としか思えないのだ。

 

2011-02
16
20:45:48
続々: 楽天銀行アプリのセキュリティについて – 結局UDID送信は中止しないし使用理由開示も行わない


前々回前回の続きをご報告したいと思う。
かなりあれから時間がかかったが、結論としてはシンプルで楽天銀行および楽天CERT・楽天グループとしてはUDIDの送信は停止しないし、また何故送信しているか、どのように利用・管理しているか は「当行不正取引防止システム運営の機密事項」のため一切開示しないとの結論であった。
以下、その詳細。

Continue reading

2011-01
23
02:40:40
続: 楽天銀行アプリのセキュリティについて – プロトコルを解析してみた


結論から書き出すと、結局のところ楽天銀行アプリはUDIDを通常(初期)ログインとクイックログインそれぞれのタイミングでサーバー送出をしていた。この事実からは楽天CERTの説明には不信がある。
さてどうしてくれようというのが現時点な訳だが、まずはどういう仕様で楽天銀行アプリが動作しているのか明らかにしてみよう。楽天CERT担当者からは「即座に悪用できるものではない」との見解ももらっているしまたそもそもリバースエンジニアリングしている訳でもなく公共のインターネットを飛び交っているデータプロトコルについての解説なのだから誰に謀るものでもないだろう。ということで、安心して内容について考察してみる。

Continue reading