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-08-27 資料作りが進まない

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

2008-08-25 やる気でねぇorz

いつもながらやる気がマイナスorz

[]第1回まっちゃ445 第1回まっちゃ445を含むブックマーク 第1回まっちゃ445のブックマークコメント

参加した人お疲れ様でした。

会場に人が多くていすが足りなかったとか、ぜんぜん参加者の方と話せなかったとか心残りがありますが、非常に面白かったです。

まあ、内輪の人が固まっていたので、そこを今後何とかしないといけないなぁと思います。次回は後ろのほうの席を確保することにしようっと。

内容については、メモったものを後ほどまとめて公開する予定。

みんな書いているので、いまさらまっちゃネタ書いてますが、べ、別にまっちゃだいふくの日記★とれんどふりーく★に載りたいわけじゃ、な、ないんだからね!!(CV: 釘宮理恵)

本日の参考資料:セキュリティ&プログラミングキャンプ2008 - xcorp::When it rains, it pours.

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

まっちゃの目覚ましで出たネタ(http://d.hatena.ne.jp/hnw/20080823)の参考に

http://wizardbible.org/34/34.txt

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

と言うわけで、XHR使えば、Webサーバでなくても攻撃に使えるんですよ。

試したのは確かIE7だったと思うので、IE8ではどうかわからないです。

yamagata21yamagata21 2008/08/25 11:29 WB の 「0x03.)ポートの制限」 に “FirefoxやOperaではXHRで接続可能なポートについても厳しく制限しており、ス
クリプトを含むページと同じポートにのみ接続可能” という話も。(ところで、SMTP だったら、XHR 使わずとも、普通の multipart の POST でどうにかならないかな?)

ikepyonikepyon 2008/08/25 11:32 多分出来るでしょうね<multipart
昔試したら出来た記憶があります。

2008-08-22 だるい

今日涼しいなぁ

[]Web開発者の必須知識、Webアプリ不正遷移対策とは?(from id:kinnekoさんとこ) Web開発者の必須知識、Webアプリの不正遷移対策とは?(from id:kinnekoさんとこ)を含むブックマーク Web開発者の必須知識、Webアプリの不正遷移対策とは?(from id:kinnekoさんとこ)のブックマークコメント

http://codezine.jp/article/detail/2627

後で読む。

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

2008-08-20 うーん

[]プログラミングではホワイトリスティングが基本 プログラミングではホワイトリスティングが基本を含むブックマーク プログラミングではホワイトリスティングが基本のブックマークコメント

http://blog.ohgaki.net/-13

なんか違和感があるなぁと思った。

脆弱性がどこで発生するかと言うと、多くの場合、他のプログラムへの出口だと思うんですよ。入り口で閉める(ホワイトリストブラックリストフィルタリングする)ことで、そりゃある程度の対策は取れる。なぜなら、プログラムの挙動は入力データによりある程度左右されるから。でも、それらを通過してしまってなお、攻撃が有効なケースと言うのもあるわけで。作成したプログラム単体(DBとかファイルシステムとか)使ってないと言うのであれば、話は簡単なんだけど。実際のプログラムは他のプログラム連携を取っていて、他のプログラム仕様は変更できないから、出口で何とかしなけりゃいけないと思うんだよなぁ(ま、いじれる自分が開発したプログラムで何とかするということ)。

ホワイトリストが基本と言われると、あらゆるデータを受け付ける必要がある仕様の場合どうすんの?ってなるんだけど・・・それが特殊って言われるとかなり違うんじゃない?と思う。

プログラミングの基本は、どのような条件であっても常に想定した動作(仕様に沿った動作)をすること」じゃないのかなぁ?

そのための方法として、ホワイトリストエスケープ処理、ブラックリストがあるんじゃないのかなと思ったり。

じゃ、仕様に抜けがあった場合どうするか?それはもちろんエラーにしてしまうとか安全側に倒すと言うことを行う必要があるんじゃないかなぁ?仕様外のことが発生したのでどうなるかわかりませんじゃ正しいプログラムじゃないと思うんだけど、違うかなぁ?

あと、WAFでゼロデイ攻撃を防ぐってどうやるんだろう?ゼロデイ攻撃と言うのは知られていないからこそ、ゼロデイと言うのであって既知のものはゼロデイじゃないと思うんだけど。ああ、市販とかOSSの未知の脆弱性に対するものってことか?それなら理解できるけど、Webアプリゼロデイと言うと新しいXSSの攻撃方法が見つかったとかそういうイメージがあるんだけど。そういうのってWAFじゃ防げないよね?

(追記)

独自開発のWebアプリの場合、あらゆる攻撃はゼロデイ攻撃と言うツッコミをもらったw

感覚的にWebアプリゼロデイ攻撃と言わなくてもゼロデイ攻撃だから、意図的に言わなくてもいいんでないかという話もある。そういうわけで、ゼロデイ攻撃?と違和感があったんだw

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

2008-08-15 あっちぃち、あっちぃ

[]ratproxy――Webアプリケーションのセキュリティレベルを検証するGoogle提供ツール(from セキュリティホールmemoratproxy――Webアプリケーションのセキュリティレベルを検証するGoogle提供ツール(from セキュリティホールmemo)を含むブックマーク ratproxy――Webアプリケーションのセキュリティレベルを検証するGoogle提供ツール(from セキュリティホールmemo)のブックマークコメント

http://opentechpress.jp/opensource/08/08/14/0159247.shtml

試してみないとなぁ。

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

2008-08-14 月見先生

世間では盆休みと言うものらしい。世のお父さんたち大変そうだなw

[]結構使えそう 結構使えそうを含むブックマーク 結構使えそうのブックマークコメント

最近検証している某ツールなのだが、結構使えそう。これは期待できる。中身のロジックも考えてたとおりっぽいしw

まあ、何のことなのかはひ・み・つということでw

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

2008-08-13 猪鹿先生・雨四先生

世間は盆休みのようですが普通仕事・・・

しかし、暑い

[]DNS脆弱性問題の説明資料 DNSの脆弱性問題の説明資料を含むブックマーク DNSの脆弱性問題の説明資料のブックマークコメント

https://www.tokai-ic.or.jp/dnscrisis/img0.html

なるほど、そういうことかって今頃理解するorz

[]第7回ばりかた勉強会 第7回ばりかた勉強会を含むブックマーク 第7回ばりかた勉強会のブックマークコメント

http://d.hatena.ne.jp/barikata-sec/20080906

ということで、話すことになりました。押しかけ講師ということでw

ネタは前から考えている開発工程におけるセキュリティ対策と、セキュリティ検査についてです。

これから資料作らなならんのだけど、出来るか心配w60ページは用意しないといけない予感。そんなに話すネタがあるのかアレなんだけど・・・

ya_taya_ta 2008/08/13 10:47 >猪鹿先生・雨四先生
猪鹿蝶、雨入り四光にしか思い浮かばなかった私は負け組でしょうか?w

ikepyonikepyon 2008/08/13 11:26 当たりですw
携帯電話の花札ゲームに称号があるんですが、それを書いてみましたw

2008-08-08 暑すぎる

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

今一よくわかってないけど、自分自身の理解の確認のために書いてみる。

まず、HTTPSの利点だが、これは以下の2点が挙げられると思う。

  1. 正しい接続先であることを信頼できる。
  2. 通信が暗号で行われるため、盗聴されるリスクをほぼなくせる。

さて、多くの人の理解では、HTTPSを使うことで2.が重要視されている。このため、オレオレ証明書でも問題ないんじゃね?という意識がまかり通っていると思われる。

しかし、HTTPS重要なのは1.のほうだと思う。いくら情報暗号で行われていても、接続先が正しいものでなければ、送信した情報が通信したい相手以外に渡されてしまう。

例と言うのはあまりよくないかもしれないが、オレオレ証明書と言うのは、こんな感じだ。

  • Aさん、Bさん、Cさんはそれぞれ相手の名前、所属する会社は知っているが、それ以外のことは知らない。
  • AさんはBさんと実際に会って、共通鍵暗号の鍵を手渡ししたいと考え、Bさんと会う約束をした。
  • CさんはBさんとAさんが会おうとしていることを知り、Bさんに成りすまして、Aさんと約束を取り付けた。
  • 当日、CさんはBさんの名義の名刺を作成し、それを使って、Aさんを信用させ、まんまと共通鍵を受け取った。
  • AさんはBさんに暗号で通信していると思い、後日機密情報をCさんに送った。

つまり、AさんはCさんをBさんと誤解して情報を渡してしまったことになる。このようなことが起こった原因は、信頼できない名刺(自分で自分はBさんだといってるようなもん)と言うものを信頼することで、相手が確かにBさんであるとAさんが判断したことによる。なぜ、名刺が信頼できないかと言うと簡単に偽造が出来るからだ。それこそ、PCプリンタさえあれば誰にだって作ることが出来る。この例における名刺が、オレオレ証明書である。

一方、偽造可能な名刺を相手の確認のために使うのではなく、免許書(最近の免許書であればICチップが組み込まれているので、偽造は難しい)で行った場合を考えてみる。ここで、Bさんの免許書が盗難されれば意味はないが、盗まれていないとする。その場合、Bさんの免許書はBさん以外には持っていないので、AさんがCさんの免許書を確認することにより、AさんはCさんがBさんではないということがわかる。その結果、共通鍵をCさんに渡すことはしなくなる。したがって、機密情報をCさんに送ることはない。

この例では、偽造が不可能かつ、国という信頼できる発行機関が個人を証明している免許書というものを使っている。これは、Verisignなどで発行される正規の証明書と同じ考え方だ。

正規の証明書を使うことで、通信の相手先が確実に正しいものであると言うことがある程度保証される。その結果、他人に情報が渡ることを防ぐことが出来るのである。

オレオレ証明書でもいいじゃないかという人の言い分は、「通信の暗号だけが出来ればいいんだヨ!」と言うものであるが、暗号と言うものは送りたい相手にのみ内容が理解できると言うものでなくては意味がない。相手先がどこの誰とも知れないにもかかわらずいくら暗号情報を送ったとしても、その情報漏れてしまう。

先にも書いたが、オレオレ証明書は偽造可能な名刺のようなものだ。実際、オレオレ証明書を使っているサイトに対し、DNSキャッシュ汚染やARP Spoofなどの方法を使って、フィッシングサイトに対してクレジットカードなどの機微情報を送信してしまうことも簡単に可能だ。

オレオレ証明書使用しているサイトアクセスした場合、証明書を受け入れるか聞かれる。それが普通だと思っている利用者は、偽造した証明書(表面上は同じ情報を表示するようなことも可能だ)であっても、同じように証明書を受け入れるか聞かれるため、フィッシングサイトでも、それが普通と考え、安心して機微情報を送ってしまうことだろう。なぜなら、オレオレ証明書は、自分自身で自分は正しいですよということを言っているに過ぎないからだ。それは、本当に正しいことなのかユーザからは判断できないし、判断する責任ユーザ存在する。

このように、オレオレ証明書を使っている場合は、送りたい相手以外に機微情報を送ってしまう危険性がある。

一方、正規の証明書は、証明書発行機関がそのサイトは本当に正しいサイトかどうかをオフライン情報などで確認している(ただし全ての発行機関がそういったことをやっているわけではない。これが問題になっているのは確かである)。また、証明書は基本的に偽造できないので、ユーザは安心して、そのサイトが正しいものであると判断できる。したがって、正しい接続先にしか機微情報を送らないことが確実であると言える(必ずしもそういうわけではないが、そうでない可能性はかなり低い)。

もちろん、オレオレ証明書を絶対使うなと言うわけではなく、オレオレ証明書を使ったHTTPSHTTPと同程度(というより毛の生えた程度のほうが正しいのか)の安全性しかないことを理解したうえで使うのであれば問題ないかもしれない。また、フィンガープリントを確実に相手に渡し、常にフィンガープリントを確認するなどであれば、ほぼ問題ないと考えられる。でも、そういった運用は手間だけが発生し、実際にはされない危険性が高いのでお勧めはしない。

オレオレ証明書なんて、せいぜい開発などの段階でテスト用に使用するのがいいんでないの。

[]Blackhatの資料(from id:tessyさんとこ) Blackhatの資料(from id:tessyさんとこ)を含むブックマーク Blackhatの資料(from id:tessyさんとこ)のブックマークコメント

http://164.106.251.250/docs/bh2008/

これとか面白そう。

http://164.106.251.250/docs/bh2008/Clark_SQL_Injection_for_Fun/

http://164.106.251.250/docs/bh2008/DeMott_AppSec_A-Z/

DEFCONの資料も出てたので、見てみてるけど、面白そうなのに限ってないorz

http://164.106.251.250/docs/dc2008/

プログラムとあわせてチェックしてたらツールが見つかったので、チェック。

http://www.grendel-scan.com/

2008-08-06 暑いなぁ

脳がとろけそうだぜぇ

[]【速報】通販サイト大手のナチュラム,65万件以上の個人情報漏えい (from 21♥SOLITUDEさんとこw) 【速報】通販サイト大手のナチュラム,65万件以上の個人情報を漏えい (from 21♥SOLITUDEさんとこw)を含むブックマーク 【速報】通販サイト大手のナチュラム,65万件以上の個人情報を漏えい (from 21♥SOLITUDEさんとこw)のブックマークコメント

http://itpro.nikkeibp.co.jp/article/NEWS/20080804/312073/

またLACか。というかまたSQLインジェクションかって言えなくもないw

いやまあ、これを書きたかっただけなんですw

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

http://slashdot.jp/security/article.pl?sid=08/08/06/0237247

を見て、SSLと証明書について今一理解されてないなぁと思った。私も、あまり正しく理解してないけどorz

ちょっとここらで一言後で書いてみる。

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

2008-08-05 眠すぎる

[]Analyzing Websites for User-Visible Security Design Flaws Analyzing Websites for User-Visible Security Design Flawsを含むブックマーク Analyzing Websites for User-Visible Security Design Flawsのブックマークコメント

http://cups.cs.cmu.edu/soups/2008/proceedings/p117Falk.pdf

後で読む

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

2008-08-01 寝不足

遅くまでおきていたにもかかわらず、朝早く目が覚めてしまったorz

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

SDLのやり方考え中。

主に設計&コーディング規約みたいな感じだけど、アイデアとしては、アプリの機能を細分化して、チェックリストみたいなのを作る感じかな?

例えば、こんな感じ。

■指定したファイルへのアクセス

ファイルが幾つか特定できている場合

 ファイル名の直接指定は行わない。必要なファイル名を配列に格納し、ファイルの指定には添え字を使用する。

ファイルが特定できない場合

 指定したファイルを正規化し、指定したディレクトリ配下にあるかを確認して、使用する。

こういったのをいくつも作っておけばその機能に応じて、どうすればいいか選ぶだけですむから開発に手間かかんないかなぁ?

多分、機能を細分化していけば、どんなアプリでも似たような物になるだろうし・・・

ぶっちゃけ言えば、アプリって、データを受け取って、それを加工して、HDDなどに追加、更新、削除したり、参照すると言うもんだろうし。で、多くの脆弱性は境界で発生するから、何とかなるんじゃないかなぁ?

MS様にのSTRIDE分析してってのはいいんだろうけどやっぱりWebアプリのように開発スピードが要求される場合には似合わないしなぁ。

セキュリティ対策が手間となると絶対やらないのは目に見えているから、手間じゃないようにする工夫が必要だと思う。

そのための、チェックリストってのを作ってみたいけど、実際のところどうなんだろう?

って、よく考えたらこれって脆弱性対策を延々と書くだけにならんかw

ま、いいやもっと考えよう。

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

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 |