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

2007-11-29 いきなりで吹いたww

はっぱさん、すごすぎw

[]どんと来い、リスクマネジメント(from まるちゃんの情報セキュリティ気まぐれ日記さんとこ) どんと来い、リスクマネジメント(from まるちゃんの情報セキュリティ気まぐれ日記さんとこ)を含むブックマーク どんと来い、リスクマネジメント(from まるちゃんの情報セキュリティ気まぐれ日記さんとこ)のブックマークコメント

http://business.nifty.com/cs/column05/list/1.htm

やっぱり元ねたはこれ?isbn:4054017622

そのうち、「どんと来い、リスクマネジメント V・I・P用」とかなぜベスが出たりするのかな?w

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

2007-11-28 気持ち悪い

なんか胃の調子が悪いorz

[]Security Compass - Application Security Canada (from id:into_the_blueさんとこ) Security Compass - Application Security Canada (from id:into_the_blueさんとこ)を含むブックマーク Security Compass - Application Security Canada (from id:into_the_blueさんとこ)のブックマークコメント

http://www.securitycompass.com/exploitme.shtml

Firefox用PluginのXSSSQLインジェクション検査ツールらしい。SQLインジェクションのチェックツールは見た感じ文字列検索とレスポンスコードで判断してるみたいだな。

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

2007-11-27 ねむい、ねむすぎる

どうやらやっとのことで記事が出たらしい。

どこに載っているかはいつものように秘密ということでw

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

前にも書いたけど。

http://www.debugmode.com/wink/

動画マニュアルを作るには重宝する。定期的に指定した場所をキャプチャしたり、キーボードで任意のときにキャプチャしたりした後、一コマ毎に動画に解説入れたり、加工できるので、かなり楽に動画マニュアルができる。でも、一コマ一コマ指定していくから、結構大変だけどなw

あとは、マウスカーソル自動で補完してくれるので、マウスカーソル移動前と移動後をキャプチャすればよいので、マウスカーソルがさまよわなくて、見た目かっこよくなるのもGood!

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

2007-11-26 SQLインジェクションを知らない開発者はモグリw By T先生

[]オレオレ証明書 オレオレ証明書を含むブックマーク オレオレ証明書のブックマークコメント

オレオレ証明書がなくならないのは、SSLの正しい使い方を理解せず、通信文だけを簡単に読めなく(あえて暗号化とは言わないw)さえしておけばOKという誤った認識だけがまかり通ってるからかなぁ?と思ったり。

暗号化ということと通信先が正しいことというのは表裏一体だと思うんだけどねぇ。ネットワークの通信において、通信先が信頼できない限り、いくら通信経路が暗号化されていても盗聴されている可能性が否定できない。正しく暗号を使うためには、送信者と受信者の双方が信頼できる(いわゆる一般的な暗号においては正しい暗号鍵をもっていることとイコールなんだけど、インターネットにおいては正しい信頼関係が構築できることになるんではないかと)ことが要求されると思うんだけどねぇ。

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

はてな日記で指定した日の日記を削除するのではなく、非表示にすることは出来んものか?

アイデアに投稿しろってw

IkegamiIkegami 2007/11/27 10:26 とりあえずコメントアウトするんじゃダメ?

ikepyonikepyon 2007/11/27 11:30 日記の一部でなく、その日丸々見えなくしたいんです。
まあ、日付を変えたら、そっちに移動でもいいんですけどね。

IkegamiIkegami 2007/11/27 15:13 う〜む。それだとアイデアに投稿しかなさげ。ローカルに保存して削除だと、コメントも全部消えちゃうし。

ikepyonikepyon 2007/11/27 15:26 あーやっぱり、そうですよねぇ。
コメントを残しておきたかったりすると今の仕様だと無理なんですよねぇorz

2007-11-22 明日は休み

[]SANS、ソフトウェア開発者向けの新たなセキュリティ試験を実施へ (from id:ripjyrさんとこ) SANS、ソフトウェア開発者向けの新たなセキュリティ試験を実施へ (from id:ripjyrさんとこ)を含むブックマーク SANS、ソフトウェア開発者向けの新たなセキュリティ試験を実施へ (from id:ripjyrさんとこ)のブックマークコメント

http://japan.zdnet.com/security/story/0,3800079245,20361635,00.htm

日本でやるようなら受けてみようかなぁ。でも、50ドル〜450ドルってどんなけちゃうねんw

http://www.sans-ssi.org/essential_skills_java.pdf

こっちもざっくり見てみたけど、結構いろいろ必要ね。

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

超いい加減にアプリケーションの機能を細分化していくと、「データの保存」、「データの削除」、「データの検索」、「データの加工」、「データの取り込み」、「データの出力」って感じに落とし込めるのかなぁ?で、これらを組み合わせていけば、いろんな機能が構成できると(たぶんこれらの機能はもっと細分化できるはず)・・・

データの生成から、消失までを考えると、細分化された機能を安全にすることと、各機能の接点を安全にすると安全なアプリケーションができる?

また、データの流れが信頼できるように構成されていれば安全?あ〜なんかイメージはあるんだけど、言葉が出てこないw

で、細分化された機能を部品化して安全なものにしていけば、開発者は接点部分の安全性に注意すればよいから楽になる?

というふうな具合に、ボトムアップで考えてみるテスト

あくまで思考実験なので・・・

しかし、デザインパターンを勉強せんといかんな、これは。

「現代用語の基礎知識」欲しい! 「現代用語の基礎知識」欲しい!を含むブックマーク 「現代用語の基礎知識」欲しい!のブックマークコメント

やっぱり技術屋なら一度はいってみたい「こんなこともあろうかと!」

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

2007-11-20 最近空目が多いorz

[]動画キャプチャ 動画キャプチャを含むブックマーク 動画キャプチャのブックマークコメント

http://www.debugmode.com/wink/

動画マニュアル作るのに便利。キャプチャ後に注釈つけたり、いろいろ加工ができるので遊べそうだ

[]Web Application Vulnerability Scanners Web Application Vulnerability Scannersを含むブックマーク Web Application Vulnerability Scannersのブックマークコメント

http://samate.nist.gov/index.php/Web_Application_Vulnerability_Scanners

Webアプリ検査ツール一覧。さすがに宣伝していないだけにねえよw

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

2007-11-19 眠すぎる

[]Watchfire Application Security Insider Watchfire Application Security Insiderを含むブックマーク Watchfire Application Security Insiderのブックマークコメント

http://blog.watchfire.com/wfblog/

こんなものがあったのか

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

2007-11-16 のうみそしんでます

試そうと思ってたアレは影響が小さいことを知って、ちょっとアレorz

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

2007-11-14 だるだる

アレを試そうと思って、調べ中

[]睡眠は寝不足で不良債権化する! 睡眠は寝不足で不良債権化する!を含むブックマーク 睡眠は寝不足で不良債権化する!のブックマークコメント

http://enterprisezine.jp/article/detail/225

非常に睡眠時間が少ない酒好きの人へw

[]OWASP Code Review Guide OWASP Code Review Guideを含むブックマーク OWASP Code Review Guideのブックマークコメント

http://www.lulu.com/content/1415989

OWASPのコードレビューガイド。ダウンロードは無償らしいので、落として読んでみる。

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

2007-11-13 くわっぱ!!

[]発注者ビューガイドライン 発注者ビューガイドラインを含むブックマーク 発注者ビューガイドラインのブックマークコメント

http://www.nttdata.co.jp/cview/guideline.html

ちと読んでみる。中身見てないのでアレだけど・・・

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

2007-11-12 ダウンロードおわらねぇorz

かったるい一日。

[]政府機関統一基準適用個別マニュアル群の一覧表(from まるちゃんの情報セキュリティ気まぐれ日記さんとこ) 政府機関統一基準適用個別マニュアル群の一覧表(from まるちゃんの情報セキュリティ気まぐれ日記さんとこ)を含むブックマーク 政府機関統一基準適用個別マニュアル群の一覧表(from まるちゃんの情報セキュリティ気まぐれ日記さんとこ)のブックマークコメント

http://www.nisc.go.jp/active/general/kijun_man_index.htm

いろいろありまんがな。中でも、6章あたりが面白いかな?

じっくり読んでみよう。

このあたりがよさげ?

http://www.nisc.go.jp/active/general/pdf/dm6-03-051_sample.pdf

http://www.nisc.go.jp/active/general/pdf/dm6-07-071_manual.pdf

調達者は、セキュリティ要求仕様を作成し、セキュリティ提案仕様を正しく評価

するための能力を確保すること

提案者が具体性の高いセキュリティ提案仕様を作成するために十分なセキュリテ

ィ要求仕様を調達者が提示すること。このためには、調達者は、外部委託を行う

に当たり、情報システム等の概要、保護すべき情報資産、前提条件及び脅威を十

分に明らかにすること。

さすがに、これをできる組織は限られてる気がするけど・・・

ockeghemockeghem 2007/11/13 12:12 コンサルタント雇えと書いているようにしか見えませんなぁ(^O^)
でも、漠然としたことしか言わない、「なんちゃってコンサルタント」が多くて困るわけよね。

ikepyonikepyon 2007/11/13 12:58 なんちゃってコンサルタントでごめんなさいorz
やっぱり、具体例とかテンプレート集みたいのが欲しいと思いますねぇ。

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

2007-11-06 DELLのキーボードは使いづらい

最近DELLキーボードはスペースバーがスペースキーになっていてすげ〜打ち辛い。何とかならんものかorz

[]Hiddenを使う必要のあるアプリケーション Hiddenを使う必要のあるアプリケーションを含むブックマーク Hiddenを使う必要のあるアプリケーションのブックマークコメント

昨日の日記にHiddenを使って、値をページ間で受け渡しするのは「シーラカンスアプリケーション」と書いたけれど、実際のところ、どうしてもHiddenを使用しなければならないケースというのが存在する。それは、多くの場合、たぶん以下の4つ(もしかしたら1と2はひとつと考えてもよいかもしれない)のケースぐらいかと思う(もっとあるかもしれないけどいまいち浮かばん)。

  1. Cookieを使用できない場合(携帯アプリのようなケースが上げられる)、セッションIDをHiddenで受け渡すケース
  2. CSRF対策としてワンタイムトークンの格納場所として使用するケース
  3. 以前のページでユーザから受け取ったデータJavascript内で使用したいケース
  4. 指摘のあったボタンなどで機能などを選択するケース

これら4つ以外のケースでページ間のデータをやり取りするような場合(Hiddenをあたかもグローバル変数のように使うときとか、例えが悪いかも)には、Hiddenを使用するしかないが、それ以外の場合はセッション変数を使用することで対応できることが多いと思う。

1のケースでは、HTTPがステートレスプロトコルであるため、現在セッションの状態を把握するためのセッションIDWebアプリでは必要となるため、CookieかHiddenというユーザが一見すると操作できない箇所にセッションIDを格納しなければならないため、Cookieが使用できないとなるとHiddenを使用するほかなく仕方がない。

2のケースでは、グダグダここで書くより、金床さんのApache Tomcat/6.0.18 - Error reportを見てもらったほうが早いw

で、問題の3のケースだけれど、これはJavascript内での入力データエスケープ処理の複雑さに由来する。Javascript内で入力データを使用したい場合、XSSが発生しないように、エスケープ処理するのは、Scriptに埋め込む箇所に依存して、方法がさまざまなので、非常に困難である。しかし、Script内で入力データを使用したい場合、方法が確立しているHTMLエスケープ処理で対応できるHiddenをScript内から参照するほうが楽である。したがって、このようなケースの場合はHiddenを使用することが望ましい。

4のケースは言わなくても当たり前ということで。でもこのケースも仕様を変えれば案外対策できたりするけど…どうしてもHiddenを使わなきゃいけないって物でもない気もするなぁ。まあ、仕様としてこうだといわれりゃしかたがないけど。

これら以外のケースでページ間で入力されたデータの受け渡しをする際にはセッション変数を使用するほうが楽だろうし、安全だろう。

とはいえ、複数のサーバで負荷分散しなくてはならないケースとか、処理が複数のサーバに渡るケースなどではそうは言ってられないのだろうけど…

そういったケースでも安全に使用する方法をちと暇なときでも考えてみよう。

(追記)指摘があったので、いろいろ加筆修正。

内容にはいろいろ問題あるのでまだまだ検討中の話ということで・・・

ockeghemockeghem 2007/11/06 16:15 これって、hiddenは危険だから極力使うなというように読めますねぇ。現実には、hidden使わないとならない(あるいは使った方がよい)ケースは、もっといっぱいあると思いますぜ。

ikepyonikepyon 2007/11/06 16:20 うーん、あんまり思いつかないんですが、ほかにどういったケースがありますかねぇ?
まあ、セッション管理機能がない環境とかありますけど…

ikepyonikepyon 2007/11/06 16:21 まあ、もともとHiddenって必要?ってところから考えが始まっているので…

ikepyonikepyon 2007/11/06 16:29 後は、トラフィックが多いサイトとかか?

ockeghemockeghem 2007/11/06 16:54 例えば、ECサイトの画面にボタンがたくさんあって、ボタンごとに購入商品が異なるような場合は、hiddenで商品コードを渡しますよね。

ikepyonikepyon 2007/11/06 16:56 オーなるほど、そういえばそういうケースがありましたね。視野狭窄してるorz

aTeradaaTerada 2007/11/06 23:42 個人的には、Webアプリだと、トランザクション処理とF5キーとか
Backspaceキーが絡むと、セッションに値を保持して画面の遷移の制御を考えるより、毎度画面に必要な項目を持たせる方がらくだと思います。(…問題はデータ改竄チェックをどれくらいまでするかになってきますが)。
一応、セキュリティというよりかは、DBのデータの整合性が取れるかを重視してますです。

ikepyonikepyon 2007/11/07 23:43 なるほど、そういった使い方もありますか。ちょっとどういうときにHidden使ったほうがよくて、どういったときは使わないほうがいいか検討します。

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

2007-11-05 だるい

今日は朝からひどい夢を見たorz

[]HiddenとWebアプリケーション HiddenとWebアプリケーションを含むブックマーク HiddenとWebアプリケーションのブックマークコメント

http://d.hatena.ne.jp/ockeghem/20071104/1194187563

を読んで、これは生きた化石の設計だなぁと思ったw

元々、HTTPはステートレスなので、複数ページに渡って内部データをやり取りしたいために、Hiddenと言うものが使われてきたんだと思うんだが(実際のところは知らんw)、今となってはそのようなやり方は古生代のやり方だと思う。

かつて、WebアプリケーションCGIプログラムと呼ばれていたころは、セッション管理と言うものを自作せざるを得ず、その為、セッション変数と言うものを使うにはしきいが高かったから、簡易的にHiddenが使われてきたと思うんだな。データがページに埋め込めて、内部データの引継ぎを簡単に実装できるから、かつてはCGIプログラムで使われてきた。それでも、きちんとしたCGIプログラムでは、入力データのチェックを行うことで安全に実装することが可能だったりするんだけど、そういったことをしてないアプリケーションの方が多かった。

時代は下ってw、今やフレームワーク言語セッション管理を実装しているため、Hiddenで内部データの受け渡しをやる必要がなくなったんだけど、未だにそれが行われているって事は、頭の切替ができてない開発者(設計者)がまだまだいるってことだよなぁ。

それとも、いわゆる入門書でセッション管理の仕組みとかセッション変数の使い方とか解説してない?

いずれにせよこんな設計は古臭いやり方なので、早急にやめて欲しいんですが、実際のところどうなんでしょ?

まあ、美しくて、安全な設計パターンみたいなのを作ってそれを広めたほうがいいのかもしれないけどねぇ。

とりあえず、こういった古臭いアプリケーションは「イトウ」ではなく「シーラカンス」と言うことを提唱してみるw

[]検査ツール 検査ツールを含むブックマーク 検査ツールのブックマークコメント

前にも書いたかもしれないけど、今ある検査ツールのほとんどが特定のデータリクエストとして送信した場合に、エラーとして表示される文字列を検出していたり、正常ケースのレスポンスと比較して異なっていたら脆弱性ありとかしている。エラーメッセージとかってアプリローカライズで異なっていたりするので、結構面倒なんだけど、何故かそうしているし、検索結果が異なっていた場合も脆弱性ありとして検出してしまうことがあるらしい(ほんとのとこはしらんw)。で、作成したツールでは、エラーとそうでない場合は、HTMLタグの構造が異なるだろうと言う仮定の元に検出ロジックを作ってみたんだけど、今一かも知んないなぁと思う今日この頃

ll 2007/12/28 00:48 「hiddenは危険脳」的解説の悪影響の典型例。「セッション変数を使えない開発者」と見下すことで満足し、そこで思考停止する。

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

2007-11-02 また記事書かなきゃ

[]どうしたことだ? どうしたことだ?を含むブックマーク どうしたことだ?のブックマークコメント

今回の記事は食いつきがいいぞw

やはりXSSの話は食いつきがいいのか?w次回はSQLインジェクションを予定しているのだけど、どうだろうねぇ。まあ、書くネタSQL Injectionの仕組みと対策あたりの焼き直しを検討中

後はSQLインジェクション文字コードがらみもちょっと書こうかな?

[]マカフィー、HACKER SAFE®を提供するScanAlert, Inc.を買収(from id:ripjyrさんとこ) マカフィー、HACKER SAFE®を提供するScanAlert, Inc.を買収(from id:ripjyrさんとこ)を含むブックマーク マカフィー、HACKER SAFE®を提供するScanAlert, Inc.を買収(from id:ripjyrさんとこ)のブックマークコメント

http://www.mcafee.com/japan/about/prelease/pr_07b.asp?pr=07/11/01-1

このサービスってかなりびみょ〜な気が前からしてるんだけど。確かにユーザとしては安全だと言うことが分かってうれしいんだけど、危険と言う指標が表示されたら、クラッカーホイホイになると思うんだけどねぇ。

どうしても、対応できないこともあるだろうし・・・その辺どうやるのか疑問なんですが。

かといって、対応できてないにもかかわらず安全とするにはユーザにとって不利益になるわけだし・・・

yamagata21yamagata21 2007/11/02 19:08 対応できない脆弱性が出てきてしまった場合には、HACKER SAFE の検査元IPアドレスをファイアウォールでDROPすれば・・・。(←バカw

ikepyonikepyon 2007/11/02 19:10 それこそ脆弱性ありがずっと表示されたりしてw

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

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 |