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

2006-12-28 最期の日

[]その対策正しいですか? その対策正しいですか?を含むブックマーク その対策正しいですか?のブックマークコメント

SQLインジェクション対策にはPrepared Statement使え、XSS対策にはタグを使うな、エスケープしろとかいわれるけれども、本当にそれだけで十分なの?

脆弱性が発生する仕組みがわかって言ってるのならいいんだけど、そうじゃなくてただ機械的に対策をとっていると、思わぬ落とし穴にはまる可能性があるってこと忘れてないですか?

例えば、SQLインジェクション対策のPrepared Statementも多くの場合は防ぐことが出来るけど、場合によっては防げないものもある。もちろん、その対策が意味ないというわけではない。

ただただ、仕組みも知らず機械的に対策だけを教え込まれると、対策漏れが出てくるのが怖いなぁと思う。だから、開発する人には脆弱性の仕組みを正しく知ってもらい、その上で対策を教える必要があると思う。

TIPSとして対策だけをまとめてしまって、それを使うのは非常に怖いなぁと思う。

もちろんTIPSが使えないってわけでも、TIPSいらないというわけじゃないんだけどね。どちらかというとあった方が便利だし。ただ、それだけが一人歩きしちゃうのが怖いだけで・・・考えすぎかなぁ?

ほんとは、そんなこと考えなくてもフレームワークなどで対応してくれてるといいんだけどねぇ。

[]既存の日本語文字コードUnicode の間のマッピングルール 既存の日本語文字コードと Unicode の間のマッピングルールを含むブックマーク 既存の日本語文字コードと Unicode の間のマッピングルールのブックマークコメント

http://www.asahi-net.or.jp/~hc3j-tkg/unicode/

この辺で何か面白いことできないかなぁ?

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

2006-12-27 あと1日

[]専門家の「脆弱性専門家の「脆弱性」を含むブックマーク 専門家の「脆弱性」のブックマークコメント

http://blog.nikkeibp.co.jp/pconline/security/2006/12/sonoda008.html

あー、そうそう、こういうことが言いたいんだ。

高木先生のアレは開発者にとってすごくいいガイドラインだとは思うんですよ。

でも、アレが守られていることを開発者じゃない人が、どうやって検証すればいいの?というのがすごく難しい。

その為のアプローチとして、「ナニ」を「ドンナ」脅威から守りたいのか?という方向からの方が分かりやすいんじゃないかなぁというのが意見だったり。

このアプローチの対として、「ドンナ」結果なら、守りたい「モノ」が守れているかという基準が必要なんで、それが、コレだったりするわけで。

コレはコレで抜けが多いんだけど、でも、最低限の守れているかどうかを判断する基準にはなると思うんだな。

ホントは、うちを建てるときのように発注側が面倒なことを考えなくても、専門家が必要な考慮(建築の場合は、構造設計とか、消防法とか)をしてくれていればいいんだけどねぇ。

(追記)

アレを発注する時に「このセキュリティガイドラインに沿って作ってね♪」と言うためのものとしてしまうと、

「このガイドラインに沿っているから問題ないよね」といって脆弱性を作りこんでくれる開発者が出そうで怖いというのもあったり・・・ま、アレが完璧ではないということは分かっているけどねぇ。

問題の本質を理解してないと、ガイドラインも使えないことが多々あるので気をつけないと。

[]議事録、会計報告公開 議事録、会計報告公開を含むブックマーク 議事録、会計報告公開のブックマークコメント

すみません。すごく遅くなりましたが、第3回の議事録と、第4回の会計報告と議事録を公開しました。

http://skuf.s-lines.net/hiki/?report20060617

http://skuf.s-lines.net/hiki/?report20061103

http://skuf.s-lines.net/hiki/?SKUF+Meeting%B2%F1%B7%D7%CA%F3%B9%F0

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

2006-12-26 ぐっすし

[]H18年度ウェブアプリケーション開発者向けセキュリティ実装講座の資料 H18年度ウェブアプリケーション開発者向けセキュリティ実装講座の資料を含むブックマーク H18年度ウェブアプリケーション開発者向けセキュリティ実装講座の資料のブックマークコメント

http://www.ipa.go.jp/security/vuln/event/200612.html

行けなかったので、これでも読んで涙を流しますw

高木先生の資料を見て思ったこと。

http://www.ipa.go.jp/security/vuln/event/documents/200612_5.pdf

確かに、これはいいんだけど、使えるのは開発者か、開発が分かる技術者だよなぁ。

大きい会社とかだと、多分そういう人材はいるし、確認することは出来るだろう。でも、ちっちゃいとこだと多分、この内容を理解して使いこなせないと思う。

もっと、技術よりのことではなく、機能の側から見た仕様が必要なんじゃないかなぁと漠然と思う。

もう少しこのあたり、後で考えてまとめてみよう。

yamagata21yamagata21 2006/12/27 09:40 たぶん、発注する時に「このセキュリティガイドラインに沿って作ってね♪」と言うためのものだと思う。(例え、発注者側が内容を理解できないとしても、)このガイドラインに沿っていなかったことによって生じる脆弱性が見つかった場合は、瑕疵として修正させることが出来る、のかも。

ikepyonikepyon 2006/12/27 10:20 なるほど、そういう使い方がありましたか。
イメージ的に、要求仕様というと、「こういうの作ってね」というのだけ並べていて具体的は方法はお任せというものがあるので、一寸イメージが違うかなぁと思ったんです。

ikepyonikepyon 2006/12/27 10:22 というか、要求仕様を出したら、受け入れ側はそれに沿った機能が実現されているか確認する必要があると思っているので、こんな細かいこと書いてても確認できないよなぁというのが、実のところ・・・

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

2006-12-25 腹いっぱい

白菜4分の一を一気に一人で食うもんじゃないw

[]「livedoor Wireless」にMACアドレス自動認証サービス DSSkypeフォン向け 「livedoor Wireless」にMACアドレス自動認証サービス DSやSkypeフォン向けを含むブックマーク 「livedoor Wireless」にMACアドレス自動認証サービス DSやSkypeフォン向けのブックマークコメント

http://www.itmedia.co.jp/news/articles/0612/25/news037.html

えーと、ただの無線スポット展開するんですか?w

MACアドレスなんて認証に使えませんよ。

こんなの登録する人が馬鹿を見るようなサービスだなぁw

犯罪を助長するつもりはないので・・・

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

2006-12-22 げほげほ

[]セキュリティ対策まんが クジョたいさく物語無線LANでとなりに筒抜け」 セキュリティ対策まんが クジョたいさく物語「無線LANでとなりに筒抜け」を含むブックマーク セキュリティ対策まんが クジョたいさく物語「無線LANでとなりに筒抜け」のブックマークコメント

http://www.ipa.go.jp/security/personal/kujo_manga/08.html

って、ちょっとまてぇぃ>IPA

いまどきWEPを推奨かよorz

WEPなんて、暗号化されてないのと同じなんですが・・・

WPAか、WPA2にしとこうよ・・・

※追記

ぐはっo....rz

http://www.ipa.go.jp/security/ciadr/20030228wirelesslan.html

リンク2003年から変わってないよ・・・

IPA無線LAN推奨はWEPですか・・・

※追記すべき情報がある場合には、その都度このページを更新する予定です。

ってあるのに、更新されてないし・・・

カンベンシテクダサイ・・・

※追記そのに

http://www.ipa.go.jp/security/personal/kujo_manga/quiz08.html

ではしっかりWPA使った方がいいとは書いてるけど、ここまで見る人そういないと思うぞ・・・

しかもこっそり目立たなく書いてあるし・・・

※追記そのさん

そうか、ぶつもりどうもり対策かw

DSがWPA対応じゃないしなぁorz

※注釈

WEPは1時間もあればWEPキーなんて簡単に解読できます。MACアドレスも簡単に偽装できます。ってかMACアドレスなんて認証には使えんです、はい。SSIDなんかも簡単に分かったはずだし・・・

というわけで、WPAかWPA2が無線LANでは推奨です。出来れば、無線LANは使わない方がベターなんだけどねぇ。

サナキサナキ 2006/12/26 17:09 先日、教えていただいたんですが、
http://sid.rstack.org/videos/aircrack/whax-aircrack-wep.html
だと、10分弱です。
IEEE802.11i の鍵の交換時間より早いかも。って言ってました。
from NTcomittee2 の勉強会より

ikepyonikepyon 2006/12/26 17:37 このサイトのことすっかり忘れてました^^;
NT comitee2のときは時間がかかってましたけどね・・・
IPAなんで、せめて注釈ぐらい入れて、修正してほしいなぁと思います。>誰となく

2006-12-15 突かれてる?

[]OWASP Orizon Project OWASP Orizon Projectを含むブックマーク OWASP Orizon Projectのブックマークコメント

http://www.owasp.org/index.php/Category:OWASP_Orizon_Project

どうやら、コードレビューツールを作成するプロジェクトらしい。

今後に期待。

[]それUnicodeでw それUnicodeでwを含むブックマーク それUnicodeでwのブックマークコメント

DBフレームワーク側の文字コードが違うと、PreparedStatementを使っていてもSQLインジェクションが発生しちまったよorz

あ、ちなみにフレームワークUnicodeで、DBS-JISって奴での検証ね。

逆の場合、どうなるか試してみる価値があるかなぁ?

というわけで、PreparedStatementも万能じゃないということで・・・

やっぱり文字コードは一緒にしましょう。

そうだ、あの文書も直さないと・・・

というかちと追加してみた。

実証はTomcatとMySQLでやっているので、MySQLのJDBCドライバの問題の可能性が高いなぁ。

2006-12-14 おねむ

[]Winny裁判罰金刑は重いか?軽いか?--自己矛盾を抱えた判決 Winny裁判、罰金刑は重いか?軽いか?--自己矛盾を抱えた判決を含むブックマーク Winny裁判、罰金刑は重いか?軽いか?--自己矛盾を抱えた判決のブックマークコメント

http://japan.cnet.com/news/biz/story/0,2000056020,20338740,00.htm

なるほど、そういうことか。

まーまー 2006/12/15 00:16 こんなのどう?http://www.jasst.jp/

ikepyonikepyon 2006/12/15 11:27 面白そうですね。参加できればしたいけど・・・

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

2006-12-13 げっそり

[]ウィニー開発者罰金150万円の有罪判決 京都地裁 ウィニー開発者に罰金150万円の有罪判決 京都地裁を含むブックマーク ウィニー開発者に罰金150万円の有罪判決 京都地裁のブックマークコメント

http://www.asahi.com/national/update/1213/TKY200612130126.html

マジか?

Webアプリ脆弱性検査ツールを作って公開した場合も「不正アクセス禁止法幇助」に問われるのかな?

開発する側は、あくまで、アプリを開発したときのセキュリティ検査を簡単にするために作るんだけど・・・

てか、フリー検査ツールがないから、検査コストを考えるとやられてないという現実もあると思うんだが・・・

こりゃ、日本じゃ使っちゃだめっていうライセンス作らないとw

[]それUnicodeで(from id:hasegawayosukeさんとこ) それUnicodeで(from id:hasegawayosukeさんとこ)を含むブックマーク それUnicodeで(from id:hasegawayosukeさんとこ)のブックマークコメント

http://openmya.hacker.jp/hasegawa/public/20061209/momiji.html

面白いw

タダちょっと気になったのはこの問題はXSSディレクトリトラバーサルだけの問題じゃないってこと。

SQL Injectionや、Command Injectionなどでも起こりうる問題なんだけど、はてなブックマーク見ているとXSSの問題と見てる人がちらほら・・・

この問題の本質は、文字コードが違う処理系データをやり取りするときには、相手先の文字コードに変換してからチェックしないと、チェック漏れが発生するってことなんだけど。

hasegawayosukehasegawayosuke 2006/12/13 23:48 データベースわかんないw

ikepyonikepyon 2006/12/14 11:27 何をおっしゃる葉っぱさんw

2006-12-12 ぐったり

[]grabber (from bunさんとこ) grabber (from bunさんとこ)を含むブックマーク grabber (from bunさんとこ)のブックマークコメント

http://rgaucher.info/beta/grabber/

Webアプリケーション脆弱性検査ツール。

ちと見てみたけど、ここら辺が検査できるらしい。

  • Cross-Site Scripting
  • SQL Injection (there is also a special Blind SQL Injection module)
  • File Inclusion
  • Backup files check
  • Simple AJAX check (parse every JavaScript and get the URL and try to get the parameters)
  • Hybrid analysis/Crystal ball testing for PHP application using PHP-SAT
  • JavaScript source code analyzer: Evaluation of the quality/correctness of the JavaScript with JavaScript Lint
  • Generation of a file [session_id, time(t)] for next stats analysis.

ソースコードも一寸だけ見たけど、やっぱり、エラーメッセージでのみのチェックっぽいorz

それに、基本自動巡回みたいなんだけど・・・

やっぱり、プロキシタイプで巡回してから、検査というツールはないんだなぁ・・・

[]JavaScriptでつくるSchemeインタプリタの基礎の基礎 JavaScriptでつくるSchemeインタプリタの基礎の基礎を含むブックマーク JavaScriptでつくるSchemeインタプリタの基礎の基礎のブックマークコメント

http://codezine.jp/a/article/aid/739.aspx

おもしろそ〜

後で読んでみるかな。

[]Googleブック検索 Googleブック検索を含むブックマーク Googleブック検索のブックマークコメント

http://books.google.com/

こんなんあったんや。

色々な本が読めそう(全部英語だけどw)。

こんなんとか

http://books.google.com/books?q=Hacknotes&btnG=Search+Books

http://books.google.com/books?q=Web+Application+Security&btnG=Search+Books&as_brr=0

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

2006-12-11 風邪っぽいなぁ

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

2006-12-08 凹み中

自分のダメさ加減を再々認識orz

[]XSS対策 XSS対策を含むブックマーク XSS対策のブックマークコメント

XSS対策の基本は、タグを使わせないことだと思うんだけど、Blogなどのようにどうしても使いたい場合は、どうしたらいいだろう?

はてなの対策は一般的に有効なんだろうか?

http://hatenadiary.g.hatena.ne.jp/keyword/%E3%81%AF%E3%81%A6%E3%81%AA%E3%83%80%E3%82%A4%E3%82%A2%E3%83%AA%E3%83%BCXSS%E5%AF%BE%E7%AD%96

例えば、擬似プロトコル(「javascript:」、「vbscript:」、「about:」)、イベントハンドラを削除すれば安全?

うーん、そういう文書どこかに落ちてないかなぁ?

[]エスケープ エスケープを含むブックマーク エスケープのブックマークコメント

ぬーやはり、JAVAでは「0x5c」と「0xa5」は別物として認識して、バックエンドのDBMySQLだと「0x5c」と「0xa5」は同じもの「\」として認識するっぽいorz

というわけで、Unicode周りで、色々問題が出てきそう。というかすべてにおいて文字コードは統一しないとダメですな。

ま、当たり前といえば当たり前だけど。

はせがわはせがわ 2006/12/08 17:44 許可されてるタグか検査 → タグごとに許可されている属性を検査( href は A のみ、とか) → 属性値ごとに許可された内容か検査(href や src なら ”http” と ”https” のみとか)
というのが基本ではないかと。

ikepyonikepyon 2006/12/08 17:52 ま、そうですよねぇ。
タグごとに許可する属性一覧、許可する内容一覧とかあればうれしいかなぁとか思ったりして・・・

2006-12-07 ぐったり

[]こと脆弱性に関しては「Webアプリ開発会社を信じるな」?(from id:hanazukinさんとこ) こと脆弱性に関しては「Webアプリ開発会社を信じるな」?(from id:hanazukinさんとこ)を含むブックマーク こと脆弱性に関しては「Webアプリ開発会社を信じるな」?(from id:hanazukinさんとこ)のブックマークコメント

http://www.itmedia.co.jp/enterprise/articles/0612/06/news103.html

ふむふむ。最近デザイン会社アプリ作ってるところが多いからなぁ。

そういったところはどうしても弱かったり・・・

でも、検査ツール高いんだよねぇorz

受け入れ側では検査できなかったりするし、検査ツールが必要なんだけど・・・

やはり作るしか・・・w

[]Unicodeサニタイジング回避テクニック(from id:ripjyrさんとこ) Unicodeとサニタイジング回避テクニック(from id:ripjyrさんとこ)を含むブックマーク Unicodeとサニタイジング回避テクニック(from id:ripjyrさんとこ)のブックマークコメント

http://rocketeer.dip.jp/unicode/index.htm

うは、こういったのできるだろ〜なぁと思いつつ、ほったらかしにしてる間に・・・

後で読もう

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

2006-12-05 ねむっ

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

http://jp.fon.com/

無料無線APスポットを作ろうというらしい。

この間のNT-Com2の話を元に、ネタとして参加してみようっとw

sen-usen-u 2006/12/05 10:53 AOLの人が結構がんばるねぇ。w <対ウイルス

ikepyonikepyon 2006/12/05 12:16 全くですw
メッセでユーザが焦っているのが面白いですw

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

2006-12-04 ぐてぇ〜

いろいろあってぐったり中

[]サニタイズ言うな サニタイズ言うなを含むブックマーク サニタイズ言うなのブックマークコメント

http://takagi-hiromitsu.jp/diary/20051227.html#p02

今更ながらに反応してみる。

今一、よく分からなかったけど、

http://kmaebashi.com/zakki/zakki0042.html

をみて、やっと理解。

まぁ、「信頼できないもの」をそのまま使うと、意図しない動き(例えばSQLの検索条件に「'」を入れると、文字列区切りとしてDB認識してしまうとか)をするから、意図する動き(さっきの例だと、「'」を文字列区切りではなく、「検索条件」として「'」を使用したい)しかしないようにするというところか。

どういった条件であっても意図した動きしかしないようにすることは「サニタイズ」とは言わへんでってこと?そんなの当たり前のことだよなぁ。

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

2006-12-01 あと1日

すれば、やすみぃ。

[]XSS Fragmentation Attack XSS Fragmentation Attackを含むブックマーク XSS Fragmentation Attackのブックマークコメント

XSS Fragmentation Attackなるものがあるらしいが、こんなこといったら、SQL Injection Fragmentation Attackなんてものも出来まっせ。

XSS Fragmentation Attackは、2つの入力フィールドに「<body test='」と「'onLoad="alert('XSS');"></body>」のようなデータを入れてチェック機能を回避するらしい。

SQL Injection Fragmentation Attackとなると、同様に、2つの入力フィールドに「hoe\' or 1=1 or ' = "」と「1"」なんて物を入れると、「'」を「''」としかエスケープしていないアプリケーションで、「\'」をシングルクォートの文字データとみなし、「"」を文字の区切りとみなすRDBMS(MySQLとか)の場合、全件検索となるとか・・・

これは、デモサイト作っているときにJDBC経由だと「;--」が使えないのでたまたま見つけただけだけどね。

こういった例は他にも幾つかあると思う。

というわけで、こんなのに名前付けて分類しちゃうと余計に混乱しちゃうんでないかなぁ?

[]分類の複雑さ 分類の複雑さを含むブックマーク 分類の複雑さのブックマークコメント

上の文章を書いて、思ったのだけど、下手に攻撃手法が細分化されてるから混乱しやすい?

脆弱性を大雑把に分類すると、「仕様による脆弱性」と「実装による脆弱性」の二つにわけられるかな?

仕様による脆弱性

文字通り、実装で何とかできない脆弱性。それこそ「パスワードが4桁の数字」だとか「WEP」とか、そんなのね。これなんか実装で何とかしようとしてもなんともなんない。だから、仕様を決定するときに対策をとらなきゃいけない。

実装による脆弱性

いわゆる「XSS」とか「インジェクション系」とかの脆弱性。よく、セキュリティホールとして発見されるのがこっちかな?

これが発生する理由は、ぶっちゃけ「何を信頼し、何を信頼しないか」をはっきりさせておらず、「信頼できないもの」を利用するときには、「必ず」、「それが、信頼できる基準をみたしているか?」をチェックしていない、又は、「信頼できないもの」を「信頼できるようにする」方法を「漏れなく」実装していない為だと思う。

で、この脆弱性を対策するには、

    1. 信頼できるものと信頼できないものを明確にする。
    2. 信頼できないものはどういった条件で信頼できるかを明確にし、それを間違いなく実装する。
    3. 信頼できないものを信頼できるようにする方法を明確にし、それを間違いなく実装する。

必要があるかと。

基本的な考え方として、「信頼出来ないものは使わない」というものでないといけないんだけど・・・

そう考えると、コーディング時だけじゃなくて、設計時にセキュリティ対策を行う必要があるのは当たり前のように思うんだけどねぇ。

[追記]

これだと、「信頼できるもの」と「信頼できないもの」というのが分からんかw

「信頼できるもの」というのは「自分自身で生成したもの(外部のデータを変換して生成していないもの)」又は「自分でコントロールできる処理」。

「信頼できないもの」というのは「外部で生成されたもの」または「それから生成されたもの」、「自分でコントロールできない処理」。

という定義でいいかなぁ?

それより、「身内」を「信頼できるもの」、「よそ様」を「信頼できないもの」としてもイメージとしては分かりやすいかもw

[追記そにょに]

というか、ホスト系ってこういう考えが普通だったような。少なくとも、私が関った奴ではそうだったよ。初めてホスト計の開発の仕様書見たとき、何で入力チェックしてるのかわかんなかったしw

最近になって、理由が分かってきたよw

ホスト系の考え方が、Webアプリとか最近の考えでは普通じゃなくなってるんかなぁ?

hasegawayosukehasegawayosuke 2006/12/01 16:01 禿同w < 混乱
というか、ちゃんと対策してれば fragment されてようがいまいが防げるはず。

ikepyonikepyon 2006/12/01 16:20 全くそうですね。
混乱すれば、専門家が必要になるから、わざとやってるとかw

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

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 |