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 なかのひと

2008-09-30 やる気でない

誰か、やる気くださいw

[]簡単に安全なアプリを作る方法 簡単に安全なアプリを作る方法を含むブックマーク 簡単に安全なアプリを作る方法のブックマークコメント

この間のまっちゃ445の懇親会で出てた話なんだけど、セキュリティのことを考えずにアプリを作れるフレームワークがありゃいいんじゃないの?という意見id:sonodamさんから出てた記憶がある。

実際、そういうフレームワークを作れんこと無いと思うんだけど、難しいだろうなぁと思う。

例えば、誰が書いてもSQLインジェクションがないアプリを作るというのを考えてみる。最も簡単なのはSQL文を開発者に書けないようにすることだと思うんだよなぁ。でも、そうすると柔軟性がなくなって、やりたいことが出来ないということになったり、却って実装が難しくなったりするんだよねぇ。かといって抜け道を作ると、抜け道ばっかり使われて結局ダメダメとなるんだよなぁorz

ガチガチにすることと柔軟性を求めることはかなり相反することなので無利なんかなぁ?

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

http://slashdot.jp/security/article.pl?sid=08/09/30/0817247

面白いなぁ。これ

でも、この動作原理なら、ソースコードがなくても、バイナリ解析なんかで何とかならんかな?

ya_taya_ta 2008/09/30 17:43 >誰か、やる気くださいw
無利!(ぇ

ikepyonikepyon 2008/09/30 18:59 そんなこといわずにw>やたさん
おらに、みんなのやる気を少しだけ分けてくれ!!w

2008-09-29 寒くて眠い

今日寒い日だなぁ

[]コピー指向プログラミング コピー指向プログラミングを含むブックマーク コピー指向プログラミングのブックマークコメント

http://ameblo.jp/argv/entry-10144604985.html

まさに、安全でないサンプルコードコピーされて大量に出回っているよねぇ。

初心者向け本とかで、最初っから問題がないコードで解説して行ってくれればいい気がするんだが。

そんなことを445の懇親会で話したら、コードがでかくなりすぎて、解説できないから無利といわれた。

でも、セキュリティ対策部分はお約束事項ということで、「このように書いてください。詳しくは後で説明します。今は、正しくうごかすための呪文だと思ってください。」の記述でいいんじゃなかろうか?

まあ、コードがでかくなるというのは回避できないけどw

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

2008-09-25 赤短教授

からだがダルダル

[](IN)SECURE Magazine No.18 (IN)SECURE Magazine No.18を含むブックマーク (IN)SECURE Magazine No.18のブックマークコメント

http://www.net-security.org/dl/insecure/INSECURE-Mag-18.pdf

SDLの話が載っている?後で読む

[]文章の書き方 文章の書き方を含むブックマーク 文章の書き方のブックマークコメント

http://d.hatena.ne.jp/kazu-yamamoto/20080924/1222224226

なるほどと思うところがある

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

2008-09-19 台風警報

週末に台風が直撃しそうだなぁorz

[]Samurai Web Testing Framework (from:id:into_the_blueさんとこ) Samurai Web Testing Framework (from:id:into_the_blueさんとこ)を含むブックマーク Samurai Web Testing Framework (from:id:into_the_blueさんとこ)のブックマークコメント

http://www.madirish.net/?article=218

http://samurai.intelguardians.com/

Webアプリセキュリティテスト用LiveCDらしい。

しかし、Samuraiとあるのになぜに和服のおんにゃのこなんだろう?w

[]なぜPHPアプリセキュリティホールが多いのか? 第14回 減らないSQLインジェクション脆弱性 なぜPHPアプリにセキュリティホールが多いのか? 第14回 減らないSQLインジェクション脆弱性を含むブックマーク なぜPHPアプリにセキュリティホールが多いのか? 第14回 減らないSQLインジェクション脆弱性のブックマークコメント

http://gihyo.jp/dev/serial/01/php-security/0014

かなりびみょ〜

チェックポイント:すべてのパラメータ文字列として取り扱っているか?

これはいいですよ。でも、

ところで,uid,gid整数型であるなら整数型にキャストすればよいのでは? と考えられた方もいると思います。しかし,キャストする方法は2つの理由でベストプラクティスとは呼べません。

キャストした場合,不正な攻撃目的入力が行われてもクエリエラーが発生しない可能性があります。攻撃目的入力は検出できるほうが好ましく,文字列として扱えばクエリエラーで簡単に攻撃用の文字列が検出できます。またキャストを行うと,32ビットアーキテクチャコンピュータでは符号付き32ビット整数となり,データベースが一般的にIDに利用する符号付き64ビット整数に比べ著しく狭い範囲の整数でしか正常に動作しません。

これはいただけない。別にキャストする必要性はないし、文字列として'でくくる必要はない。この例であれば、ただ単に数値かどうかを確認するだけでよい。たしかこのあたりの考察を昔徳丸さんがやってたな。

http://www.tokumaru.org/d/20070924.html#p01

$_POST['first_name']に「表」などの“\”を含む文字が指定されると

first_name = '表\'

エスケープ処理され,サーバ側ではSJISとして処理されます。この結果,2つ目のパラメータ($_POST['last_name'])でSQLインジェクションが可能になります。

いや、それってphpヘタレなだけじゃ?他の言語ではこんな変なエスケープ処理しないはずだけど・・・ってかPHPでもやったっけ?

[]AppScan Developer Edition AppScan Developer Editionを含むブックマーク AppScan Developer Editionのブックマークコメント

http://www-01.ibm.com/software/awdtools/appscan/developer/

いつの間にかこんなのがw

一応ソースコード監査が出来るらしい。30日の試用版があるみたいなので、試してみようw

(追記 10/9)

現状AppScan DEをインストールするのに必要なバージョンのAppScan SEが無いため、インストールできないorz

早く何とかしてくんないかなぁ?

(追記 10/10)

AppScan SEを一度でもインストールすると、アンインストールしてもゴミがRegistryに残っているため、DEをインストールできないらしい。

AppScan関連のレジストリを削除したらDEインストールできたよ!

インストールマニュアルのどこにも書いてないんだよなぁorz

yamagata21yamagata21 2008/10/10 21:13 サポートに聞いてみるしか! (・・・あれ?w)

ikepyonikepyon 2008/10/11 02:07 自己解決してますからw

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

2008-09-18 買ってしまったorz

衝動買いをまたしてしまったorz

CFPには落ちてたし・・・orz

落ち込むこと多いなぁw

[]「WebサイトはWAFで守る」が企業セキュリティの新常識 「WebサイトはWAFで守る」が企業セキュリティの新常識を含むブックマーク 「WebサイトはWAFで守る」が企業セキュリティの新常識のブックマークコメント

http://members.techtarget.itmedia.co.jp/tt/members/0809/17/news01.html

常識って・・・Webアプリは開発時にきちんと対策しないと。その上で保険としてのわふの導入ならわかるんだけど。まあわふべんだーの記事なので仕方ないのかorz

[]WebアプリセキュリティSDL WebアプリセキュリティとSDLを含むブックマーク WebアプリセキュリティとSDLのブックマークコメント

ばりかたで使用した資料を公開します。

http://www.geocities.jp/ikepy0n/webappsecandSDL.pdf

ま、あまり役に立たないし、理想論しか書いてないけど・・・

ということでよかったらツッコミくださいw

vulcainvulcain 2008/09/19 03:59 WAFで対応できる範囲であれば、アプリなんて修正しなくていーんだー!WAF入れさえすれば!!!
とは、とあるWAFベンダーの弁(ぉぃ

ikepyonikepyon 2008/09/19 10:13 それ、なんか違うw
次回まっちゃ445でバトルに参戦ですねw

vulcainvulcain 2008/09/19 22:11 資料にアクセス出来ない?
まぁ参戦というか私とは正反対の意見ですけどねぇw

ikepyonikepyon 2008/09/20 17:56 なんかおかしいですね。なんでだろう?

ikepyonikepyon 2008/09/21 19:26 ちょいと直してみました。これでどうでしょう?

vulcainvulcain 2008/09/24 05:33 原因わかりゃした。Refer通ってないとファイルはDL出来ないみたいですね。
ファイル名削ってインデックス表示させたら、DL出来ましたw

ikepyonikepyon 2008/09/24 09:38 うーん、そんな制御してないんですけどねぇ?
うちのほうでは、ファイルをアップしなおしたら直ったので、それが原因かな?と思ってます

2008-09-17 だめだめっぽ

[]脆弱性の種類を識別するための共通の脆弱性タイプの一覧 脆弱性の種類を識別するための共通の脆弱性タイプの一覧を含むブックマーク 脆弱性の種類を識別するための共通の脆弱性タイプの一覧のブックマークコメント

http://www.ipa.go.jp/security/vuln/CWE.html

脆弱性の分類一覧

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

2008-09-16 うらしまたろう

1週間まともにネットアクセスしてないと、何がなんだかw

おかげでAVのCFPの申し込み期限過ぎてるしorz

[]日本HPWebアプリ脆弱性を診断・修正する「HP Application Security Center」 日本HP、Webアプリの脆弱性を診断・修正する「HP Application Security Center」 を含むブックマーク 日本HP、Webアプリの脆弱性を診断・修正する「HP Application Security Center」 のブックマークコメント

http://enterprise.watch.impress.co.jp/cda/security/2008/09/09/13810.html

ソースコード監査をするツールも出すんだなぁ。

世の中、そっちのほうに進むか、やっぱり・・・

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

2008-09-03 あきらめたorz

結局デモMacで動かすのをあきらめたorz

2台のPC持込かぁ、ちょっとアレダナァorz

[]Webアプリケーションの脅威モデリングの勘所(from id:hasegawayosukeさんとこ) Webアプリケーションの脅威モデリングの勘所(from id:hasegawayosukeさんとこ)を含むブックマーク Webアプリケーションの脅威モデリングの勘所(from id:hasegawayosukeさんとこ)のブックマークコメント

http://techtarget.itmedia.co.jp/tt/news/0809/02/news02.html

うーん、これを読んで思ったけど、やっぱり、コーディングに起因する脆弱性とそれ以外では区別しなきゃいけないんではなかろうか。

コーディングに起因する脆弱性SQLインジェクションとかXSS)は方法が面倒ではあるけれど、やり方がわかっている分、結構対策はとりやすいと思う。でも仕様とか設計に起因するものは、場合場合による&漏れが発生することがあるので、かなり難しい。

で、仕様とか設計に起因するものはリスク分析による対策の検討が必要で、コーディングに起因するものは、やっぱり教育ってことになるのかな?

教育教育で、底上げが難しいんだよなぁorz

[]ソースコードレビュー ソースコードレビューを含むブックマーク ソースコードレビューのブックマークコメント

http://d.hatena.ne.jp/higaysuo/20080901/1220241148

コーディングに起因する脆弱性は、ソースコードレビューすることで結構減らせるよなぁ。その上、教育にもいいかもしれない。

プログラマな人はきれいなコードをもっと読んだほうがいいと思う。けど、きれいなコードってなかなかなかったりするんだよなぁ。

[]GreenSQLでMySQLデータベースSQLインジェクション攻撃から守る GreenSQLでMySQLデータベースをSQLインジェクション攻撃から守るを含むブックマーク GreenSQLでMySQLデータベースをSQLインジェクション攻撃から守るのブックマークコメント

http://sourceforge.jp/magazine/08/09/03/024225

GreenSQLというMySQLProxyとしてDBを守るもの。

しかし、どう考えても、「それ、わふでできるよ!」と言いたくなるなぁ。もちろん、これ経由だとテーブル構造の変更できないと言うのはわかるんだが、普通アプリで使うユーザにはテーブル構造の変更権限なんて与えないだろ!!

ま、なんかあったときのふぉれんじっく取得用にはいいかもしれない。

けど、必要性をあんまり感じないなぁw

[]AV Tokyo 2008 AV Tokyo 2008を含むブックマーク AV Tokyo 2008のブックマークコメント

http://www.avtokyo.org/

10/11にやるらしい。Blackhatにいけない人も参加できるよ!

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

2008-09-02 ねむ〜

寝れなかったorz

会社来たら誰もいないしw

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

ちと考えているので。

  • 工程で、どうするかの計画を立て、実装し、実装の内容を確認するというサイクルをまわす(どうするんだったかな?アイデアあったのに忘れたw)
  • 要件定義ですること
    • 「誰」が「何」を「どうする」かを機能ごとに明確にする->これは、結局要件を明確にすることにつながる
    • 明確にした機能についてSTRIDE分析を行う(MSの資料参照)
    • STRIDE分析の結果、脅威に対してどうするかを決定する
      • 受容:この脅威は発生してもよしとする
      • 軽減:いわゆるセキュリティ対策
      • 回避:機能の実装自体をやめてしまうとか
      • 移転:他組織が提供しているサービスを利用することで、脅威を自組織で起こさないとか
  • 設計でやること
    • 入力と出力のデータ仕様を明確にする->設計で当たり前にやることだし
    • 機能の実行条件を明確にする->これもそう
    • 各機能を可能な限り単機能に分割する->これもやるよね?
    • 例外処理を明確にする->あんまり設計で意識してやってないかもw
    • 軽減するとした脅威に対して、どのような対策を行うかを検討し、機能として定義する
  • コーディングでやること
    • 設計どおりにコードを書く->当たり前
    • 実行時例外をうやむやにしない->結構もれる
    • 出力データ仕様通りにエスケープなどの処理を行う->同じくw
  • テストでやること

というようなことをやればいいかなぁ?

と書いてはみたものの、これ実際にやるとなると、要件定義と設計で結構工数取られるよね。

まあ、「何」の部分の重要度が高いのだけやりゃいいって話もあるけどな。

(追記)id:hasegawayosukeさんに教えてもらった。

http://e-chishiki.com/jpn/articles/information_security/application_security/security_principals_and_the_sdl/security_development_lifecycle

上のアイデアは、設計やコード依存するような脆弱性XSSとかSQLインジェクションCSRF)は実装でがんばってつぶす。それ以外の問題については、リスク分析やって、その結果に応じて対策する、しないを決定しようぜという感じ&正しいプログラム脆弱性が少ないという前提に立っている。各工程ではレビューを行うことで抜けとか間違いを正すということも必要。

後開発サイクルのことを考えると、あんまり重くしたくない。ただでさえ工数削減が言われているのに、それに対して重いセキュリティ対策もといわれると、無利!!となるのは目に見えてるからね。

もちろん、MSSDLのようにあらゆる部分に対してコストかけてセキュリティ対策を行うというのが理想だけど、理想ばっかり言っても出来ないものはできないわけで。そういった落し所がSonyDNAのレビュー中心の手法であったり、考え中の方法だったりするんでないかなぁ?

ま、これでも現場で実践するのは結構難しいとは思う。要件も決まってない、設計も出来てない、でもカットオーバーが決まっているから、コード書かなきゃという現場もあるわけで。その結果バグが発生し、そのバグ脆弱性につながるんじゃないかと考えてる。

そろそろ、再度ウォーターフォールのよさを見直して、それをうまく短期間の開発手法に組み込むというのが必要じゃないのかな?

[]Twitterが熱いw Twitterが熱いwを含むブックマーク Twitterが熱いwのブックマークコメント

いやぁぶつくさつぶやいているだけでw、みんながいろいろネタを発言してくれるので、ブレインストーミングに使うにはいいっす。

2008-09-01 もう9月

夏も終わりだな。今年の夏もいつもと同じく何もなかったorz

[]Security を意識した発注をするためにはどうしたらいいんだろう? Security を意識した発注をするためにはどうしたらいいんだろう?を含むブックマーク Security を意識した発注をするためにはどうしたらいいんだろう?のブックマークコメント

http://blogs.wankuma.com/tyappi/archive/2008/09/01/154896.aspx#FeedBack

発注側として、本当にセキュリティ意識する必要性があるのか?というのが最近考えるんだよねぇ。

建築業界(まあ、構造偽装とかあったけど)では、発注要件の中に、震度いくつの地震があっても倒れないこととか、火災が起こっても直ぐに全焼しないこととかってないよなぁと思ったけど、法律で決まってるかw

セキュリティ要件が必要じゃないというわけじゃなくて、受注側が考えて提示すべきなんだけど、工数とかそんなところにつながるからなぁ。結局、見た目、簡単な受け入れテストじゃわからないから手抜きしたところが、安い受注額でとってしまうというのが現実だよねぇorz

RFPの回答を受け取ったら、発注者はB.シュナイアーの5段階評価を考えればいいというのをもらった。

http://twitter.com/bugbird/statuses/905570077

  1. 守るべき資産は何か
  2. その資産はどのようなリスクにさらされているのか
  3. セキュリティ対策によって、リスクはどれだけ低下するのか
  4. セキュリティ対策によって、どのようなリスクがもたらされるか
  5. 対策にはどれほどのコストとどのようなトレードオフが付随するか

http://winnie.kuis.kyoto-u.ac.jp/~okuno/Lecture/07/Ethics/Ethics-071221-Okuno.pdf

のも参照?

ふむふむ、確かに、RFPの回答にこういったことが考慮されているか?というのはチェックリストとしていい気はするが、受注側はセキュリティについて何も書いてなければ、こういったこと書かないだろうなw

結局、鶏が先か卵が先か?ってことになるのか?

書いてなかったら、再度こういうこと考えて作れといえばいいのか?->じゃ、最初から書いとけよって感じだけど・・・

書いてあったら書いてあったで、結構回答作るの難しそうw

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

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 |
Connection: close