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-03-31 結果はどうだったのだろう?

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

2008-03-28 春は、あけぼの。やうやう白くなりゆく山ぎは

[]WebScarabの機能とか WebScarabの機能とかを含むブックマーク WebScarabの機能とかのブックマークコメント

今更だけどちといろいろいじってみたので、メモ代わりw

Proxyとして機能して、リクエストを取得することができる。

  • Intercept

受け取ったリクエスト/レスポンスインターセプトして、内容を書き換えることができる。内容の変更にはRAWデータでも、パースされてわかりやすくなったリクエストでもOK。

  • BeanShell

受け取ったリクエスト/レスポンスJavaで記述したコード自動で変更することができる。ちとAPIの説明が少ないのが欠点かな?

  • Reveal hiddenフィールド

レスポンスHTMLを書き換えて、Hiddenフィールドを可視化する

GUIリクエストを作成送信する

  • Parameter Fuzzer

GUIオリジナルリクエストを作成し、別途指定した値で各パラメータに書き換えて送信する。テスト自動化ができるけど、問題の有無判定はしてくれない。

過去リクエスト/レスポンスを指定した文字列で検索する。XSSとかはPrameter Fuzzerと組み合わせることで発見できそう

まあ、他にもあるんだけど、とりあえずこんなところでw

問題は日本語UTF-8以外対応してないことかな。パラメータとかURLデコードして表示してくれるんだけど、化けまくるしw

一番使えるのはBeanShellかなと思う。

あ、そうそう、WebScarabはJakartaのHttpClientを使っているらしい。某ツールでも使っているのだけど、アレ内部でデータデコードして持っているので今一好きになれないのよねぇorzおかげで、Clientを作り直しているしw

h-ふじたh-ふじた 2008/03/31 09:41 Scarabはよくつかっております。日本語の問題は、、表示だけはなんとかするべぇ という感じで、ソースをいぢくってSJISとかEUCでもごにょごにょ表示できるようにしてみたりもしています。
それが使えるだけでも結構便利。
でも、Fuzzerはまったく使えてないので使い方を覚えたいこのごろ。

yamagata21yamagata21 2008/03/31 10:28 21proxy に、シェルをつければ良いですか?(無理w

ikepyonikepyon 2008/03/31 11:23 Fuzzerは結構悩みましたwそのうち使い方を書いてみます。>h-ふじたさん
21proyにシェルとFuzzerをつけてくださいw>yamagataさん

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

2008-03-19 ねぶすぎ

[]数論で学ぶアルゴリズム(仮)第3回 数論で学ぶアルゴリズム(仮)第3回を含むブックマーク 数論で学ぶアルゴリズム(仮)第3回のブックマークコメント

http://exception.or.tv/ASNT/?study3

5/31に江戸で開催予定らしい。面白そうなので、都合がつけば参加したい。

しかし、数学ってすっかり抜け落ちてるよorz

[]BitVisor(α版) BitVisor(α版)を含むブックマーク BitVisor(α版)のブックマークコメント

http://www.securevm.org/index.html

ちと面白そう。

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

https://www.pcisecuritystandards.org/tech/download_the_pci_dss.htm

OWASPのガイドライン参考にしろとか書かれているのね。

でもちょっと気になったのが、

すべてのWeb に面したアプリケーションは、以下のどちらかの手法を適用することで、既知

の攻撃から防護されなければならない。

カスタムアプリケーションコードについては、アプリケーションセキュリティに特

化した組織に依頼して、一般的な脆弱性についての見直しをしてもらう。

Web に面したアプリケーションの手前に、アプリケーションレイヤー・ファイアウォ

ールをインストールする。

注:この手法は2008 年6 月30 日まではベストプラクティスの一つであるが、その後は必須

要件となる。

ですな。7/1からカード決済するところは、セキュリティ監査かWAFが必須になるようだ。

これで、売れてないらしいWAFが売れるようになるのかな?

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

2008-03-13 目がかゆすぎる

[]PHPは本当に危険なのか? PHPは本当に危険なのか?を含むブックマーク PHPは本当に危険なのか?のブックマークコメント

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

とか、IPAの「例えば、PHPを避ける」(IPA ISEC セキュア・プログラミング講座:Webアプリケーション編 第1章 総論:より良いWebアプリケーション設計のヒント)とかみるとPHP自身の問題と、PHPで作成されたWebアプリの問題をごっちゃにしている気がしている。

PHPという言語自体に問題があるのは確かだし、PHP4を未だ使い続けているというのも問題だけども、だからといってこういった記事を見て、明日から「PHP危険だから、Webアプリの開発にJava/.NETにしよう」といっても正しいプログラムの書き方を知らないことには、Webアプリ脆弱性はなくならないだろう。

PHPの問題は、以下の点の様な気がする。

PHP自身が抱えている問題は他の言語フレームワークを使うことで減らすことができるのは確かだろう。

それと、初心者が作るWebアプリケーション自身が持つ脆弱性の多さと分離して考えないといけないんではないかと思う。PHP初心者向きという誤った宣伝がなされているがために、初心者がきちんと危険性を理解せず脆弱性のあるWebアプリを大量に作りこんでしまっているのが現状ではないか?

今後新たにPHPのような「初心者向き」と呼ばれる言語ができたとして、そちらに移ったとしても同じことがおこるんじゃないかなぁと思う。

もっとも、新しい「初心者向き言語」が何も考えずに、安全なアプリケーションが作れるのであればそういうことは起こらないかもしれないけど・・・

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

2008-03-12 かゆかゆ

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

2008-03-11 むずむずする

[]あんなの飾りです。偉い人にはそれがわからんのですよ。 あんなの飾りです。偉い人にはそれがわからんのですよ。を含むブックマーク あんなの飾りです。偉い人にはそれがわからんのですよ。のブックマークコメント

ISO認証とかISMSとか認証、プライバシーマークとかとっても実際に運用が回ってなかったら飾りにしかならんと思うんですけど。結構認証取るのが目的になってしまって、運用が回ってないところってあるんじゃないかなぁ?そういうところの第三者認証は飾りでしかないよなぁ。

逆に、きちんと運用をまわして、セキュリティを保つことが目的となっていれば、第三者認証がなくても問題ない気がする。

あくまで、第三者認証はセキュリティとかが十分保ててるかではなく、その仕組みができていることを誰の目から見てもわかるようにするためのもんだと思うしね。

事務局員:80%? 冗談じゃありません! 現状で、当社のセキュリティ管理は十分できています!

CIOプライバシーマークは取れていないではないか

事務局員:あんなの飾りです。偉い人にはそれがわからんのですよ。

ってのはどうか?

こういったのもあったか。

事務局員:80%? 冗談じゃありません! 現状で、当社のセキュリティ対策は十分できています!

コンサルタント:定期的なパスワード変更がなされていないではないか

事務局員:あんなの飾りです。偉い人にはそれがわからんのですよ。

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

2008-03-10 私はOld Type

平成生まれの人に言われてしまったw昭和生まれは旧人類らしいw

2008-03-07 めたぼ!!

[]コーディング脆弱性 コーディングと脆弱性を含むブックマーク コーディングと脆弱性のブックマークコメント

脆弱性のうちコーディングだけで対策できるものと、設計時に対策しないといけないものがあるんではないかというのを前々から考えていたりする。当然、設計時に対策するものについては、実装であるコーディングでも対策は必要といやぁ必要だろう。

まあ、コーディングだけで対策できるものも場合によっては、設計時に検討するフレームワークやツールで何とかなるものもあるだろう。

とはいえ、コーディングがもっとも重要な防衛ラインといえるだろうなぁ。

というわけで、コーディングだけで対策できそうなWebアプリ脆弱性といったら以下のものがあげられるかなぁと。

他にもあるかも。

いずれも、自由に開発できるアプリor関数、メソッドと他のアプリDBとかブラウザとかOSとか)or他の関数、メソッドとの境界で発生するものだ。コーディング時に外部とのやり取りを行うデータがどういったものがあるのか、それは常に開発者自身が意図したものなのかといったことを検討しないといけない。こういった部分は、設計などの上流工程で対策しようとするのは不可能ではないが難しいと思う。

なので、どうしてもプログラマの力量にかかってくると思う。しかし、現状では境界部分の重要性が十分に検討され、脆弱性対策できているわけではない。

これは、正しいコードと間違ったコードが世の中に広まってないからかなぁと思う。

やっぱり、間違っているサンプルコードではなく、間違っている生きたコードと、正しい生きたコードデータベースみたいなのが欲しいなぁ。

[]Hiddenは危険Hiddenは危険?を含むブックマーク Hiddenは危険?のブックマークコメント

ってことはないんだけど、実際のところ、Hiddenにエスケープ漏れや妥当性検証漏れって言うのが発生しやすいというのが現状だと思う。これは、HiddenがTextとは違って、一見するとブラウザから変更できないように見えるからじゃないかと思う。実際、脆弱性が見つかることが多いのは、Hiddenだったり、Option、Checkboxだったりするしなぁ。

Hidden全てにおいて必ずエスケープ、や妥当性検証ができるのであれば問題ないけど、それができなくて、エスケープ漏れ、検証漏れが発生する危険性を減らせるのであれば、Hiddenを必要最低限しか使わないという規約もありじゃないかと思う。全然いい規約じゃないけどね。

って書くとHiddenは危険脳っていわれるかなぁ。

yamagata21yamagata21 2008/03/08 00:10 もしもし、漢字が間違っていますよ−?w >無利

ikepyonikepyon 2008/03/10 09:39 えっ、これが正しいんじゃなかったでしたっけw<無利

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

2008-03-06 ほっかいど〜行きたいなぁ

[][] 無料Webアプリありがちな脆弱性を調べて治す(from id:ripjyrさんとこ)  無料でWebアプリにありがちな脆弱性を調べて治す(from id:ripjyrさんとこ)を含むブックマーク  無料でWebアプリにありがちな脆弱性を調べて治す(from id:ripjyrさんとこ)のブックマークコメント

http://www.atmarkit.co.jp/fjava/rensai4/safetomcat_05/safetomcat_05_1.html

なんかひどひ。

niktoって既知の脆弱性しか調べないんじゃなかったっけ?パラメータ改ざんとか、XSSセッションハイジャックとか調べないと思ったけど、違ったかなぁ?

それに、XSSが発生することが多いのはGETのクエリパラメータって言うより、POST、GETに関係なく、Hiddenとか、ListBoxとか、Optionとか、CheckBoxなんだけど・・・

対策もかなり微妙・・・基本はエスケープで間違いはないんだけれども、XSSの対策が難しいところは、入力データを埋め込む場所によって有効な対策が微妙に異なるところだと思う。そういったことを書いてないのは微妙かなぁ?といいつつ自分の記事はどうだったっけ?w

後は、開発したWebアプリケーションセキュリティ検査自動でやってくれるツールってのはそんなになくて困ってたりw

それに、TRACEがたいしたことないって・・・そんなことないよなぁと思いググって見た。

エラーメッセージの危険性:Webアプリケーションに潜むセキュリティホール(4) - @IT

結構危険ですよ、だんなぁ

(追記:2008/3/7)

ツッコミうけたみたいなのでw

各ブラウザでのTRACEの挙動を確認してないのでわかりませんが、TRACEは問題ないと言い切ってしまうのはちょっとなあと思いますね。

[][]初心者プログラマーが簡単なフォームを作るときにやりがちな6つのミス 初心者プログラマーが簡単なフォームを作るときにやりがちな6つのミスを含むブックマーク 初心者プログラマーが簡単なフォームを作るときにやりがちな6つのミスのブックマークコメント

http://en.yummy.stripper.jp/?eid=835168

初心者にかかわらずよくあるミスですな。ただまあ、SSLに関する部分は状況によるので、なんともいえない気がするけど・・・

[]まっちゃ139勉強会 まっちゃ139勉強会を含むブックマーク まっちゃ139勉強会のブックマークコメント

http://d.hatena.ne.jp/ripjyr/20080419/1203745616

試験申し込み忘れたので、出る予定。ねたを仕込められたら仕込んで行きたいな


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