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-06-29 あつ〜い

昨日、暑くてむしゃくしゃしたので、例のブツを某所に放置してみたw

さて、どうなることやらw

[]より良いWebアプリケーション設計のヒント より良いWebアプリケーション設計のヒントを含むブックマーク より良いWebアプリケーション設計のヒントのブックマークコメント

http://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/003.html

なかなかすごいなぁ。「例えば、PHPを避ける」って・・・

確かにPHPで作ったアプリケーション脆弱性が多い傾向があるけど、それって、PHPだけのせいじゃないと思うんですが。PHPには変な機能があるので、それが脆弱性を招いているといえるけど、全部が全部そういうわけじゃないし。

どちらかというと、

PHPは簡単に作れる=>経験の少ないプログラマが作ることが多い=>結果として脆弱性が盛りだくさん

と言うケースの方が多いと思うんですよ。JAVAでも.NETクラスライブラリ豊富でそこで吸収してくれるから、比較的安全というわけであって、そんなの使わずに、経験の少ないプログラマが作れば、PHPアプリとどっこいどっこいになるんではないかなぁ。まあ、PHPを避けたほうが無難といえば無難だけどねぇ。

結局、作る人に脆弱性の有無は依存するということで。

こっちがトップページみたい

http://www.ipa.go.jp/security/awareness/vendor/programmingv2/index.html

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

2007-06-28 なんかだめ

[]LAPSE: Web Application Security Scanner for Java LAPSE: Web Application Security Scanner for Javaを含むブックマーク LAPSE: Web Application Security Scanner for Javaのブックマークコメント

http://suif.stanford.edu/~livshits/work/lapse/

前に書いたかもしれないけど、ソースコード監査をするツールっぽい

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

2007-06-27 なんか頭遺体

[]セキュアデベロップメントそにょに セキュアデベロップメントそにょにを含むブックマーク セキュアデベロップメントそにょにのブックマークコメント

というわけで、セキュアコーディングではなくセキュアデベロップメントというものを推進してみたいと思うんだけど、具体的に何をすればいいのか検討していくことからはじめてみる。

開発工程では以下のようなものがあると思うんだな。

  1. 要件定義
  2. 設計
  3. 実装
  4. テスト
  5. 運用

で、セキュアデベロップメントでは、それぞれの工程で、セキュリティを検討することになる。ただ、要件定義の段階でセキュリティを検討する必要があるのか?というのは未だにかなり疑問。

建築など他分野では要件定義で安全について検討することはそうそうないし、安全性については専門家にまるっきりお任せでも、最低限のものは検討してくれる。でも、ことITに関してはそうじゃないんだよなぁ、今のところorz

本来論から言えば、要件定義の段階で安全性について事細かに指定する必要はないと思うんだけど、現状では、指定せざるを得ないかなぁ。

理想論をいっていても仕方が無いので、要件定義で何をセキュリティに関して検討するかは、後ほど検討してみよう。

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

http://www.microsoft.com/japan/technet/security/secnews/community/community070627.mspx

うーん、やっぱ醜いなぁorz

編集してくれるのかと思ってたw

yamagata21yamagata21 2007/06/27 13:09 「一級プログラム設計技師」みたいな資格を作る。(冗談w 
そして、耐DDoS強度偽装問題とか・・・・。w

IkegamiIkegami 2007/06/27 13:14 え”〜っ!DDoSにも配慮するんですかぁ?境界ルーターに任しちゃいけないんですかぁ?
# と、ネタにマジレスしてみる。

ikepyonikepyon 2007/06/27 13:17 www
「検査は実施していたけれど、検査項目に無かったのでセキュリティの検査は実施していません」とか?w

yamagata21yamagata21 2007/06/27 17:01 「安いWebアプリを喜んで買う消費者にも問題がある」とかねw

金床金床 2007/06/29 13:31 頭遺体 ってコワイんですが…(;´Д`)
ってヤマガタさんが軽く真実を語ってますね>安い…

ikepyonikepyon 2007/06/29 13:51 いやぁ、変換一発で何故か出たので面白いかとw<頭遺体
発注側は、値段でしかモノのよしあしを判断できないんですよねぇ。だから、yamagataさんのが確かに一番真実ですね。

hasegawayosukehasegawayosuke 2007/06/29 13:53 Webアプリはタダで使えると思ってる利用者にも責任ありますか?

金床金床 2007/07/01 03:48 ユーザが危なそうなWebアプリに敏感になってくれないと、発注者がセキュリティに金出さないですからね〜
カカ○コムなんか、あんなにひどかったのに普通に営業続いてますし…w

ikepyonikepyon 2007/07/02 16:09 一般の人は「専門家」に信仰がありますからねぇw
専門家が作ってるから安全だとか、専門家が言っているから大丈夫とか・・・
専門家にもピンからキリまであって、ひどいのはむちゃくちゃひどいというのが分かってもらうとこから始めないと・・・

IkegamiIkegami 2007/07/02 16:11 一般人が専門家の専門能力を評価するのは無理な希ガス。(W

ikepyonikepyon 2007/07/03 18:31 一般人が専門家を評価するのは無理でしょうけど、他の専門家が評価した専門家の専門能力を評価することはできると思うのですが。
いわゆるセカンドオピニオンって奴ですね。

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

2007-06-26 血の池地獄

[]セキュアデベロップメント セキュアデベロップメントを含むブックマーク セキュアデベロップメントのブックマークコメント

ぼけ〜っと話をしていて、安全なアプリケーションを作るには、セキュアコーディングというTIPS的な方法では無くて、セキュアデベロップメントとも言うべき、要件定義から、テストまで含めた開発手法が必要なんじゃないかなぁと思った。

どうも、セキュアコーディングとなると、コーディング規約として、出力時にはサニタイズしろ(あえて言ってみるw)とか、DB操作するときにはバインメカニズム使えとかそういったTIPS的な話になってしまう気がして、なんだかなぁと思っちゃうんだよねぇ。コーディングにしか目に行かなくて他の部分がおなざりになりそうで、ちょっとイヤンな感じなんだよなぁ。

もっと、前段階の機能や、取り扱う情報リスク分析をした上で、どうしよう?という話とか、テスト計画とかの話もしないといけないんじゃないのかなぁ。

というわけで、セキュアデベロップメントという言葉を提言してみるテストw

(修正)

ちと語呂が悪い気がしたので、デベロップメントに修正してみた。

sen-usen-u 2007/06/26 22:49 今度のまっちゃでそういう話しをする予定ですー。TIPS的な理想論は一定レベル以上にしか効果がないので。

ikepyonikepyon 2007/06/27 10:51 TIPSはTIPSでしかないので、特殊な場合や新たな手法が発見、開発されたら対応できなくなるんですよねぇ。
次回まっちゃ楽しみです。

hasegawayosukehasegawayosuke 2007/06/27 10:53 TIPSを否定するTIPさん…(寒っ

ya_taya_ta 2007/06/27 11:37 >はっぱさめ
TIPタソは「俺はユニークであって複数存在しない!」からTIPSを否定してるんですよ
#無理矢理「非スルー力」発動

sen-usen-u 2007/06/27 18:23 TIPは一人で十分だ。w

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

2007-06-20 だるだる

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

って、きちんとまとめた方がいいのかなぁ?

某所からたまにどうやって検査するのか聞かれるんだよねぇ。

基本は異常系のテストなので、それさえしっかりやればセキュリティに特化したテストって不要なはずなんだけど。

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

http://www.jipdec.jp/camp/

どうやら、講師と講座内容が公開されたらしい。

毎年思うんですが、参加したいなぁ。この内容で一般向け講座開いてもらえないかなぁw

yamagata21yamagata21 2007/06/20 19:39 講師として参加するという手が?!w

ikepyonikepyon 2007/06/20 22:43 なるほど、それはいい手ですw
って、人様に教えられるほどの技術はありませんからw

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

2007-06-15 あと1日

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

http://sourceforge.net/projects/securityscanner/

どうもPHPコード検査するツールらしい。

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

2007-06-14 辛いもの分、甘いもの分が足りない

[]Webアプリケーションを作る前に知るべき10の脆弱性(from また上野宣かさんとこ) Webアプリケーションを作る前に知るべき10の脆弱性(from また上野宣かさんとこ)を含むブックマーク Webアプリケーションを作る前に知るべき10の脆弱性(from また上野宣かさんとこ)のブックマークコメント

http://www.atmarkit.co.jp/fsecurity/column/ueno/47.html

設計段階というか、要件定義の段階からセキュリティを考慮しておけば、後々楽なんだけどねぇ。

でも、何をやればいいのか具体的に分からないというのが多くの人の意見なんかなぁと思う。

やはり、具体的にやるべきことを書いた文書を作るしかないか?

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

2007-06-13 辛いもの食いたい

[]w3af - Web Application Attack and Audit Framework w3af - Web Application Attack and Audit Frameworkを含むブックマーク w3af - Web Application Attack and Audit Frameworkのブックマークコメント

http://w3af.sourceforge.net/

とりあえず、チェック

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

2007-06-08 これからのことを考えると・・・

なんか、月末は非常に忙しくなりそな予感orz

[]文字コードセキュリティ 文字コードとセキュリティを含むブックマーク 文字コードとセキュリティのブックマークコメント

ふと思ったんだけど、日本語以外のマルチバイトコードセキュリティってどうなんだろう?

考え方は変わらないんだろうけどねぇ。

日本語サイト中国語を食わせてみるとか、影響はないのかなぁと思った金曜日の昼前

[]JSONセキュリティそにょに JSONとセキュリティそにょにを含むブックマーク JSONとセキュリティそにょにのブックマークコメント

JSONで動的にデータをやり取りするのって、Javascriptを動的に生成するのとほぼ同じなんだよなぁ。

だから、JSONデータを生成するときは、ちゃんとしたエスケープ処理(何かはともかくw)が必要となるんだけど、そういったこと考慮して、みんなJSON使ってるのかなぁ?と思った金曜の夕方

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

2007-06-07 なんと

[]WatchfireがIBMに買収されたっぽい WatchfireがIBMに買収されたっぽいを含むブックマーク WatchfireがIBMに買収されたっぽいのブックマークコメント

http://www-306.ibm.com/software/rational/welcome/watchfire/

にゃんと。この間ISSを買ったと思ったらWatchfireもか

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

2007-06-06 くらくら

朝起きたら、クラクラしたので、午前中は寝てました。でも、未だ復活して無い感じorz

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

http://tools.ietf.org/html/rfc4627

Security considerations:

Generally there are security issues with scripting languages. JSON

is a subset of JavaScript, but it is a safe subset that excludes

assignment and invocation.

A JSON text can be safely passed into JavaScript's eval() function

(which compiles and executes a string) if all the characters not

enclosed in strings are in the set of characters that form JSON

tokens. This can be quickly determined in JavaScript with two

regular expressions and calls to the test and replace methods.

var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(

text.replace(/"(\\.|[^"\\])*"/g, ''))) &&

eval('(' + text + ')');

これを見ると、しっかりセキュリティの事書いてあるね。まあ、普通に考えれば、当たり前か。

一応、サンプルコードで何とかなりそうな気もしないでもないけど、文字コードがらみで抜け道ありそうだなぁ。

はせがわはせがわ 2007/06/07 11:42 そもそもapplication/jsonやtext/javascriptはIEが認識しないので、適当なPATH_INFOをつけることでHTMLと認識させてのXSSが可能になります。http://d.hatena.ne.jp/hasegawayosuke/20070404/p1

ikepyonikepyon 2007/06/07 11:59 JSONの場合、JavaScriptで受け取ったデータを扱うために、受け取ったデータをeval関数に食わせるようです。
このため、JSONの中にJavaScriptのコードが含まれていたらそのコードが実行できてしまうという結構怖い自体に^^;
なので、チェック部分とeval関数での文字コードの取り扱いが違うとまずいかなぁということなんです。

はせがわはせがわ 2007/06/07 13:01 JSONデータの提供側と利用側が別の場合、当然JSONデータのcharsetについても合意しているはずで、その場合 JSONデータ提供側は、受け取った側が正しくJSONデータを扱えるようcharset指定をつけてHTTPレスポンスヘッダを返す等の対応をしていると思います。にも関わらず、受け取った側がそれとは異なるcharsetであると解釈するための方法が存在するのでしょうか?

ikepyonikepyon 2007/06/07 14:06 そのあたりが分からないので、確認しようかと思っています。
意図的に、JSONのデータに受け取り側が想定していない文字コードのデータが含まれたとき問題が発生しないかどうかがわからないので・・・
内部で変に変換してしまって問題が発生しないかなぁと。

ockeghemockeghem 2007/06/07 23:41 RFC4627では、JSONの文字エンコーディングはUNICODEと規定されていてデフォルトではUTF-8です。

3. Encoding
JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.
Since the first two characters of a JSON text will always be ASCII characters [RFC0020], it is possible to determine whether an octet stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking at the pattern of nulls in the first four octets.
00 00 00 xx UTF-32BE
00 xx 00 xx UTF-16BE
xx 00 00 00 UTF-32LE
xx 00 xx 00 UTF-16LE
xx xx xx xx UTF-8
一応、シフトJISとかが入ることは想定されてないようですが・・・そういう問題ではないのかな?

ikepyonikepyon 2007/06/08 00:05 そのあたりは一応読んでいて、Unicodeが規定されているにもかかわらず、Shift JISなどが入ってきた場合どうなるか?というところに興味があります。

ockeghemockeghem 2007/06/08 08:47 了解ですが、通常は、はせがわさんの言われるようにサーバーとクライアントで合意しているはずのもので、どのような(悪い)状況を想定してのことかをはっきりさせないといけませんね。あるいは、どのような悪い状況が想定しうるかという議論でしょうか?

ikepyonikepyon 2007/06/08 10:34 どういった時に、問題が発生するのか?(具体的にコードが実行できてしまうのか?)ということを調べないとと思っています。
UTF-8でも、ブラウザによってはこういうこともあるみたいですし・・・
http://iandeth.dyndns.org/mt/ian/archives/000621.html

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

2007-06-05 眠すぎる

[]XMLHttpRequestの利用方法w XMLHttpRequestの利用方法wを含むブックマーク XMLHttpRequestの利用方法wのブックマークコメント

XMLHttpRequestを使えば、自由に改行が操作できるみたい。

例えば、こんなScriptがあったとすると。

 <html>
 <body>
 <script>
  function createHttpRequest(){

    if(window.ActiveXObject){
        try {
            return new ActiveXObject("Msxml2.XMLHTTP")
        } catch (e) {
            try {
                return new ActiveXObject("Microsoft.XMLHTTP")
            } catch (e2) {
                return null
            }
         }
    } else if(window.XMLHttpRequest){
        return new XMLHttpRequest()
    } else {
        return null
    }
  }

  function requestFile( data , method , fileName , async )
  {
    var httpoj = createHttpRequest()
    
    httpoj.open( method , fileName , async )

    httpoj.send( data )
  }
    
 </script>
 <form>
  <input type="button"
   onclick="requestFile( 'user test\npass testtest\n' , 'POST',  'http://hogehoge:8010/test.txt’ , true )">
</form> </body> </html>

XMLHttpRequestリクエストとして、こういったものを投げる。(IE7で検証)

POST /test.txt HTTP/1.1
Accept: */*
Accept-Language: ja
Referer: http://hogehoge/test.htm
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 1.0.3705; .NET CLR 2.0.50727)
Host: hogehoge:8010
Content-Length: 24
Connection: Keep-Alive
Cache-Control: no-cache

user test
pass testtest

改行コードがそのまま投げられているのが分かるかと・・・

当たり前といえば、当たり前の気もするけど、これを使えばFTPとか、TelnetとかのブルートフォースツールをJavascriptで作ることもできますな。

コードさえうまく作ればBoFツールもできそうな予感orz

まあ、こんな手間かけるのであれば、直接攻撃した方が楽だけど、自分の手を汚したくないときなんかに使えそうですな・・・

まあ、XSSを使った悪用方法としてはこんなものもあるということで・・・


追記:

どうやら、URLエンコードされていないデータが送られているようなので、decodeURIComponent使えば、結構楽にShellコードも作成できそうorz

この攻撃の怖いところは、XSS脆弱性のあるサイトで動いているTCPポートに対して、普通の人が知らないうちに攻撃を仕掛けてしまう点だったり。被害者であるはずが、加害者になってしまうので怖いなぁと思う。

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

JSONって、受け取ったデータをeval関数引数として使うのね。これって、データコードの区別がつけられないから、非常に危険だと思うんですが・・・

受け取ったデータコードらしきものが含まれていたら、意図しないコードが実行されて非常に危険なんだけどなぁ。

まあ、その為にjson.jsJSON parserがあるようだけど、これを使ってる人ってどの程度いるんかなぁ?

http://allabout.co.jp/internet/javascript/closeup/CU20050515A/

http://jsgt.org/ajax/ref/test/json/test1.htm

とかそういったことについて、全く記述してないのが怖いんですが・・・

JSON使うときは、ここを参照すべきですな。

http://www.json.org/

[]JSON文字コード JSONと文字コードを含むブックマーク JSONと文字コードのブックマークコメント

JSON文字コードってどういう扱いになるんだ?扱っている文字コードの違いでXSSが発生しないのかなぁ?

金床金床 2007/06/05 20:23 XHRで21番ポートとかって接続できました?

あと、IEではmethod部分にいきなり改行入れられたりします。
#IE7では直ってるのかもしれません

teraccteracc 2007/06/05 21:06 ポートが違うとSame Origin Policyに反するのでダメかなと。

余談:私はこれが結構好きです。
http://ha.ckers.org/blog/20070325/javascript-spam/

ikepyonikepyon 2007/06/05 22:09 22,23は接続できました(IE6)
25,21はだめでしたけど。どういう基準かいまいちわかりません

ikepyonikepyon 2007/06/05 22:14 あれは以前できることを確認してて、その後、試したら直ってた気がしたんですが、直ってないんですね>teraccさん

ikepyonikepyon 2007/06/05 23:03 Firefoxはうまく動かないですねぇ>XHR
どうも、IEはSame Origin Policyはポートまで見てないようです。

teraccteracc 2007/06/06 00:02 >IEはSame Origin Policyはポートまで見てないようです。

うー、失礼しました。IE6で試したら、その通りでした。

ikepyonikepyon 2007/06/06 00:59 いえいえ>teraccさん
Firefoxは問題ないんですがIEだとTCP22番ポートに接続できるのは困った気がします。
SSHがあいているWebサーバって結構ありそうですし・・・

金床金床 2007/06/06 01:35 22番がイケルとはw
例によってブラックリスト方式で25とか21は禁止してるんでしょうね。
で22が漏れてる、と。

ikepyonikepyon 2007/06/06 13:46 でしょうねぇ。
どのポートがOKでどのポートがダメと言うのを調べるのは面倒なのでやりませんけど、Firefoxみたいに同じポートでなきゃダメとしちゃえばいいと思うんですけどねぇ。

金床金床 2007/06/06 17:39 このへんを実装してるのはどのDLLなのかなぁ…
リバースエンジニアリングで調べてみたいような気もします。

Firefoxは同じポートのみokなのですね、なるほど。

ikepyonikepyon 2007/06/06 17:48 Operaも同じポートのみOKのようです。
どう考えてもIEの仕様がおかしい気がしてきました。

金床金床 2007/06/07 10:57 IEの禁止ポートは以下のようです
21
25
110
119
143

ikepyonikepyon 2007/06/07 13:00 ありがとうございます>金床さん

2007-06-04 ねむい

やっぱり、土曜日バイト疲れが・・・

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

ガクブルしながら、サニタイズ済みwの某所にて開催されたXSS祭り普通の人として参加してきました。

やっぱり、関西の人はすごいです。

しかし、汎用的なXSS対策モジュールみたいなのって、作れないもんですかねぇ?各言語毎に対策モジュールがあれば、すごく便利だと思うんですけど・・・

[] Anurag Agarwal - Application Security Evangelist  Anurag Agarwal - Application Security Evangelistを含むブックマーク  Anurag Agarwal - Application Security Evangelistのブックマークコメント

http://myappsecurity.blogspot.com/

なんかよく分からんがw アプリケーションセキュリティエバンジェリストブログらしい。

人に教えてもらったのでw

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

2007-06-01 6がつ〜

[]How To Write Unmaintainable Code How To Write Unmaintainable Codeを含むブックマーク How To Write Unmaintainable Codeのブックマークコメント

http://www.strauss.za.com/sla/code_std.html

後で読む

多分かなり、当てはまってるよなぁorz

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

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