ikepyonのお気楽な日々〜技術ネタ風味〜 このページをアンテナに追加 RSSフィード

気になった日々のニュースとメモのためのリンクと戯言のページ

To Do(というかやりたいこと。何時終わることやら)
-ITIL導入のための成熟度チェックシートみたいなの(あると便利だよね?)
-Hacknotes Web Security Portable Reference和訳(出版社募集中)
-Webアプリケーションセキュリティ検査ツールの改良(一応完成)
-Hacker HighSchoolの資料の日本語訳
-OSSTMMの日本語訳
-「燃えるセキュアプログラミング」若しくは「サルでも分かるセキュアプログラミング」とか書いてみたいなぁみたいな。

これだけはチェックしときなはれ!!受入れテスト用セキュリティチェックリスト公開中
Webアプリケーションセキュリティはてなぐるーぷ(テスト中やで)
SQL Injectionの仕組みと対策公開中
RSS feed meter for http://d.hatena.ne.jp/ikepyon/
Secure Coding に入ろう!! [MLの詳細]
メールアドレス
SKUF Meeting なかのひと

2010-02-25 だるい

[]mod_wafful mod_waffulを含むブックマーク mod_waffulのブックマークコメント

というのがあったなんて知らなかった。

これを使えば、中途半端文字コードを使った脆弱性を防げそう。

http://wafful.org/mod_wafful/mod_wafful.c

http://lc.linux.or.jp/lc2008/slide/lt-02.pdf

こんなことで嘆かなくてよいかも

http://blog.ohgaki.net/char_encoding_must_be_validated

トラックバック - http://d.hatena.ne.jp/ikepyon/20100225

2010-02-24 遅くなった

[]XHRのその後のその後 XHRのその後のその後を含むブックマーク XHRのその後のその後のブックマークコメント

http://d.hatena.ne.jp/ikepyon/20091119#p1

の件だが、Wininet.dllバージョン8.00.6001.18876 (longhorn_ie8_gdr.091218-1700)で直っている模様。

やっとって感じだなw

トラックバック - http://d.hatena.ne.jp/ikepyon/20100224

2010-02-17 カマ掘りたい

[]コードによる脆弱性が発生する仕組み コードによる脆弱性が発生する仕組みを含むブックマーク コードによる脆弱性が発生する仕組みのブックマークコメント

コードによる脆弱性が発生する原理は、XSSにしろ、SQLインジェクションにしろおんなじ何だが、理解できてない人には理解できないみたいなようなのでつれづれに書いてみる。

どんなアプリケーションも以下のような構造をしている。

入力データモジュールA→データ1→モジュールB→データ2→モジュールC→データ3→・・・・・→モジュールX→出力データ

要するに、どこかしらから入力データを受け取ったモジュールが、そのデータをごちゃごちゃ処理を行い、その結果をデータとして別のモジュールに渡す。そしてデータを受け取ったモジュールが今度はそのデータを元に処理を行って、また新しいデータを出力する。これを延々伝言ゲームのように繰り返すわけだ。

まあ、大きく考えると一つのモジュールブラウザRDBMSWebアプリケーションといったものになるし、粒度を小さくして関数やメソッド単位にして考えてもいい。どっちにしろ、あらゆるアプリケーションは複数のモジュールを組み合わせて作られている。

さて、伝言ゲームでは、受け取った情報を隣の人に伝えてるだけなのに、最初の人が受け取った内容と、最後の人が受け取った内容がまったく異なることが多々ある。これは、各人が受け取った情報の伝達にミスがあるとか、勝手解釈するからというのがあるために発生するわけである。コードによる脆弱性もまったく同じようなことが起こっているために起こる。

つまり、モジュール内では問題なく解釈し処理を行っているのだけれど、他のモジュールに渡すデータが受け取るモジュールからするとあいまい(正確に言うと違うのだけれど)というか別の意味解釈できるようなデータを渡してしまう。この結果、開発者意図しない処理を行ってしまう。これが、脆弱性として表面化するのである。受け取るデータが明確におかしなもの(伝言ゲームの例で言えば、出題内容が日本語とされているにもかかわらず日本語の文法に沿ってないものとか)であれば、受け取る側で「コレはおかしい!」と判断して、エラーなり、なんなり処理ができるんだけれども、たまたまデータはおかしくないけれど、別の意味に取れるようなものであれば、別の意味として処理を行ってしまう。

日本語で言えば、例えば次のような文章があったとする。

ここではきものをぬいでください

コレを書いた人(開発者)は「ここで履物を脱いでください」という意味でこの文章を書いたにもかかわらず、受け取った人(RDBMSとか他のモジュール)は「ここでは着物を脱いでください」ととって服を脱ぎだすということが起こっているかもしれない。

元の文は「は」を「HA」と読むか、「WA」と読むかで大きく意味が違ってくる。

日本語では「は」という文字は特別な意味を持っており、「WA」と読むことで「助詞?」になったり、「HA」と読むことでただの「は」という文字になったりする。先の文を一意の意味を持つようにするためには以下のようにすればいい。

ここで、はきものをぬいでください

こうすることで「は」は「HA」としか取れなくなる。もちろん「はきもの」を「くつ」に変えてしまって、「ここでくつをぬいでください」としても日本語としてはほぼ同じ意味を持つので問題ないと言うかもしれない。しかし、文章が改変されてしまい、もとの文章とは違うものになってしまっている。「くつ」をぬげとあるが、では「げた」は脱がなくてもいいのか?とか「さんだる」は?という具合に厳密に考えると不具合が起こる。もっとも、人間はいい加減なので「くつ」=「はきもの」と解釈するので現実社会では問題は起こらないだろう。


これと同じこと(「は」を「WA」でなく「HA」と読んでしまうこと)がコード脆弱性でも起こっている。例えばSQLインジェクションであれば「'」は文字列リテラルの区切りを意味するので「Tully's」といった文字列リテラルをそのまま検索しようとすると「'」が文字列リテラルの終了とみなされて、SQL文法エラーが発生してしまう。

これを防ぐには「は」を「HA」と確実に読ませるように「、は」としたように、「'」を文字列リテラルの区切りをいう意味を持たないただの文字データ「'」として表す必要がある。そのためには「'」を「''」にするという処理を行う。こういった特別な意味を持つデータを特別な意味を持たないデータにする処理をエスケープ処理と呼ぶ。この処理を行うことで、RDBMSは、開発者意図どおりの意味解釈することができる。

こう理解するとコード脆弱性対策って当たり前のことと思えないかなぁ?

トラックバック - http://d.hatena.ne.jp/ikepyon/20100217

2010-02-10 あと一日

[]iモードセキュリティガイドライン iモードのセキュリティガイドラインを含むブックマーク iモードのセキュリティガイドラインのブックマークコメント

http://www.nttdocomo.co.jp/service/imode/make/content/browser/

ガイドラインといっておきながら、内容が無いようw

せめてリンクIPAトップページじゃなくて、安全なWebサイトの作り方とか、セキュアプログラミング講座とかへのリンクにしとこうよ。

IPAトップページリンクなんかじゃきっと見つけられない人出てくるよw

まあ、auとかソフトバンクはこういったガイドラインを出そうという気がないようなので、それよりましだけどさ

トラックバック - http://d.hatena.ne.jp/ikepyon/20100210

2010-02-08 おねむ

[]ほんとに安全なアプリ開発に高いコストが必要か? そのに ほんとに安全なアプリ開発に高いコストが必要か?  そのにを含むブックマーク ほんとに安全なアプリ開発に高いコストが必要か?  そのにのブックマークコメント

開発側でやるべきことを書く前に、アプリケーション脆弱性についてどこの工程が原因で脆弱性が発生するのかちょっと分類してみる。

あらゆる脆弱性は、以下のどれかといっていいと思う。

  1. 仕様の問題による脆弱性
  2. 設計の問題による脆弱性
  3. コードの問題による脆弱性
  4. 運用の問題による脆弱性

現状これらがすべてごっちゃになって論じられているのではないだろうか?

仕様の問題による脆弱性

仕様の問題による脆弱性を実装段階で何とかしようとすると確かに非常に莫大なコストがかかる。しかし、仕様策定の段階でこれを対策しておけばそれに比べるとコストはかからない。もちろん、そういったことを洗い出さずに仕様策定するよりはコストがかかる。ただしこの仕様策定段階でのセキュリティ対策というのは発注側が本来コストを払うべきものではないだろうか?

開発側からすれば、発注側の会社がどのようなセキュリティポリシーを持っていて、どういう脅威を問題視するか?というのはわからないと思う。これは通常の機能についても同様だ。発注側は思いつく限り自分たちがほしいと思う機能を上げて、それが実現可能かどうかも考えずに、全部作れという。その結果莫大なコストがかかるというのはよく聞く話だ。発注側は想定したコスト内で実現するために、どの機能が必要で、どの機能はいらないといった重要度を考えなければならないが、同じことをセキュリティ面でも考えなければいけないと思う。

こういったことをやらずに何でもかんでも機能を追加しているのではないか?

設計による脆弱性

仕様の問題による脆弱性と同様の議論が成り立つと思われる。加えて、この段階でコードによる脆弱性が発生するのを少なくする仕組みを作ることで、コードによる脆弱性を減らすことができる。例えば、SQLインジェクションが発生しやすいというのであれば、SQL文を一切書かなくてもいいフレームワークなり、デザインパターンを使用するようにすればいい。また、安全なコーディング規約を決めて、それにしたがってコードを書くように教育しておくということも有用だと思う。もちろん、アプリケーション仕様によってはフレームワークなどが使えない場合もあるだろう。その場合は、黙っていても安全なコードを書ける技術者にその部分の実装をお願いすることになるかもしれない。

設計でつぶせる脆弱性というのをまったく考えずに設計していることで、余計なコストコーディング時に増えてないだろうか?

コードによる脆弱性

よく聞くSQLインジェクションXSSはこの部類になる。これらの脆弱性は当たり前のことをしていればほぼ防ぐことができる。しかし、現状その当たり前のことがなされていないことが多い。これはプログラミング教育においてセキュリティは難しいからということや、当たり前にしなければならないことを説明が難しいからという理由できちんと教えていないことが原因ではないだろうか?教育には確かにコストがかかるが、それは安全なアプリを作るには必要なことだろう。この部分をケチって余計なコストをかけているということはないだろうか?

安全なコードを書くためのコーディング規約をつくり、それを遵守させるというのも対策としてはいいだろう。

また、脆弱性発見するためにセキュリティテストをする工数がかかるというのもあるだろう。しかしこテスト工数自動化ツールを使うことで削減できるだろう。もちろん、自動化ツールで検出できる脆弱性は限られているが、多くの攻撃というのは自動化ツールで見つけられるものだったりするので、ある程度役には立つ。

もっとも、テストというのは実装したものが、仕様どおりに動いているかどうかを確認するためのものと思うので、テスト脆弱性発見するというのはちょっと違う気もするけど・・・

確かにテスト工数は大きくかかるが、現状の開発ではテストがおざなりになっていることは否めない。設計が終わった段階で、自動テストツールを並行して作るチームというのもあってもいいかもしれない。そうすることで、納期が短くてもテストが十分できるようになるのではないか?もっとも、テストチーム事態がコスト増加の原因となるだろうけど、複数プロジェクトで似たようなものが作れると思うので、量産化できるのではないか?Webアプリに関していえば、そういった汎用ツールって結構できるんじゃないかな?

運用による脆弱性

日々の運用重要であるにもかかわらず軽視されることが多い。まあ、正常に動いて当たり前というのがあるからなぁorzまた、実装の段階で実装が困難なものを運用カバーするという無茶も結構あるのではないだろうか?これは開発側が運用のことを考えずに設計しているということが大きい気がする。結果ミスをしやすい運用になったり、そもそも運用条件が現実的にありえないとかありそうである。こういったものも設計の段階からきちんと考慮していれば防げるだろう。

というわけで、(何がというわけかわからんがw)きちんと各工程セキュリティについて考えていれば大きくコストが跳ね上がることはないのではないだろうか?現状それができていないor何をやればいいのかわからないというのが問題で、やるべきこと、考えることというのはそれほど難しいものではないと思う。また、業務アプリなんてそうそう大きな違いがないのだからテンプレート化、ツール化ってできるのでは?

そういったものを作るには確かにそれなりの知識や技術が必要だろうけどねぇ。

トラックバック - http://d.hatena.ne.jp/ikepyon/20100208

2010-02-05 フォアグラ状態orz

[]ほんとに安全なアプリ開発に高いコストが必要か? ほんとに安全なアプリ開発に高いコストが必要か?を含むブックマーク ほんとに安全なアプリ開発に高いコストが必要か?のブックマークコメント

http://www.atmarkit.co.jp/fsecurity/rensai/talk13/talk01.html

を読んで、違和感を感じたので書いてみる。

まず、セキュリティというのは当たり前のことを当たり前にさえやっていれば、ある程度防げるものだと思っている。そしてその当たり前のことはそれほど大きくコストがかかるわけではないことが多いんだと思う。現状はその当たり前のことができてないために、いろいろな問題が出てきているのではないか?

なぜできないかというと、関係者全員にセキュリティ=難しいもの、コストがかかるものという誤った認識が出来上がっているために、必要以上に大きく見積もってしまっているのではないか?それこそ、「幽霊の正体見たり枯れお花」ってやつなのだと思うのだけど・・・

その上で、現状のアプリ開発において、発注側が適切にセキュリティ対策について考えていないことがセキュリティ要件を入れると高い見積もりが出てくるということになるのではないだろうか?

例えば、「セキュリティには十分に注意すること」なんてRFPに書かれていれば、何をどこまでやればいいのかわからないからちゃんとした会社は非常に大きくリスク見積もって、高い見積もりが出てくるのではないだろうか?

逆に詳しくセキュリティ要件を書いているつもりが、実は実装をぎちぎちに制限してしまって、他の機能要件の実現が難しくなってないだろうか?あるいはあまり意味のないセキュリティ要件をたくさん書いてないだろうか?

本来、セキュリティ要件では、どのデータ、処理がどのくらい重要で、それがもれたり、使えなかったりしたらどういう損害が出るか?ということを考慮したうえで、どういった対策をとるか?というのを決定して、(要するにリスク分析)それを発注側が記述しなければいけないと思う。

ところが、発注側がよくわからないという理由で、その手順をやらず、話題になっていることを適当に取り入れて作っているのではないか?

アプリケーションなんて、機能を細分していくとそれほど複雑なものではないと思う。そうすると、リスクテンプレート化できるのではないかなぁと思うのだけどどうだろう?

開発側だけに問題を押し付けるのではなく、もっと発注側も開発に責任を持つべきではないだろうか?

開発側についてはまた後で書こうっとw

トラックバック - http://d.hatena.ne.jp/ikepyon/20100205

1900 | 01 | 06 |
2003 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 02 | 03 | 04 |
2011 | 01 | 02 |