2006-09-13

今日は、ちょっと小ネタチックなものをたっぷりの接着剤でつなげてお送りしていくわ。よろしくってかしら？

一片目のくず肉。まずはこちらからよ？
株式会社ディノ ( http://www.dino.co.jp/ ) さまっていう会社さんがあるの。こちらのTop Pageにもあるんですけれども、PHPコード監査サービスっていうとっても素敵なサービスをやってらっしゃるらしいの。

http://www.dino.co.jp/business/solution/inspection.php より
PHPコード監査サービス
インターネットの普及により日々たくさんのウェブシステムが構築されています。中でもPHP言語はその習得の簡単さや生産性の高さから、ウェブシステム開発で広く利用されております。しかし、PHPは習得が簡単である反面、プログラマの技術力がまちまちになり、ウェブブラウザからのチェックでは発見が困難な様々な脅威を含んだままシステムが利用されるケースが多く見られます。
株式会社ディノではPHP ソースコード監査を個別見積りにより受注しておりましたが、このたび監査サービスをパッケージ化し、ソースコードの抜き取り監査を固定価格「1回98000円（税込）」という今までにない価格にて提供させていただくことになりました。

ですって。これってとっても素敵に画期的なことじゃなくってかしら？
あたくしとしても、やっぱり色々と気になることは少なからずあるの…っていうか、これチクってきた子が散々っぱら気にしてるのよ*1。
というわけで早速に伺ってみたの。そのサイト ( https://inspection.dino.co.jp/ ) に。

https://inspection.dino.co.jp/ より
「dinspection」9つの特長
* 業界トップクラスの技術者が監査
* 短納期：5営業日で監査完了
* 低価格：\98,000 固定
* テストではなく、コードを監査
* 「安全性」「保守性」「性能」「バグ」
* 公平・中立な監査結果
* プロジェクトの進捗を邪魔しません
* 早期発見：未完成でも監査できます
* PHPに特化

あらあらまぁまぁあらまぁまぁ。なんて素敵な取り揃えなんでしょ？業界トップクラス*2の技術者が安全性などについてしっかりと監査してくださるのね？
なんとも心表れるお話じゃなくってかしら？お値段は…ソースの量にも拠るんでしょうけれども、基本的には「リーズナブル」な感じだと思いますわ？
で…ちょっと「ログイン」ってPageを見つけたの。何かしら何かしらって思って伺って、もちろんそのまま何の気なしにHTMLを拝見いたしましたの。

…あらあら。あたくしの目の錯覚かしら？
＜input type="hidden" name="referer" id="referer" value="https://inspection.dino.co.jp/" /＞

ってなにかしら？
あたくしには…

ログイン後の遷移画面
ログイン失敗時の遷移画面

のいずれかに見えて仕方がないのよね？
不思議だわぁ「業界トップクラスの技術者が監査」している「「安全性」「保守性」「性能」「バグ」を見つけてくださる」「PHPに特化」した会社さんの、これがHTMLなのかしら？設計なのかしら？実装なのかしら？
ほら、こちらを是非ご覧になって頂戴？

https://inspection.dino.co.jp/necessity より
第三者によるコード監査の必要性
情報セキュリティにまつわる事件・事故が増加しています
ここ数年、情報セキュリティにまつわる事件・事故が、ニュースや誌面をにぎわせています。ある大手通信会社は、400万件を超える個人情報を漏洩したとされ、お詫びの金券で総額数十億円の費用を支払ったと報じられています。
代償は金銭的な損失だけではありません。長期間かけて築いてきた、企業ブランドやサービスの信頼性を失うことも考えられます。
従来の個人情報漏洩は、名簿の紛失・盗難によるものが中心でした。近年は、個人情報の電子化に伴いPCや記録媒体の紛失・盗難による漏洩が増え、そしてインターネット上で個人情報を扱うウェブアプリケーションの増加に伴いウェブアプリケーションへの不正アクセス等による漏洩が増えています。ウェブアプリケーションを提供する運営者や開発者にとって、その安全性の確保は必須となっています。
ウェブアプリケーションの安全性はまちまち
ところが現実には、実運用されているウェブアプリケーションの安全性はまちまちです。ひとつには開発言語の問題があります。PHPは習得しやすく生産性が高いためウェブアプリケーション開発言語のスタンダードの一つとなっていますが、他方でプログラマーの力量に個人差がでやすい傾向があります。結果として様々な「脅威」を含んだままの低品質なPHPアプリケーションが実運用されてしまうことがあります。
そうした低品質なPHPアプリケーションは、次のようなセキュリティリスクを内在している可能性があります。

https://inspection.dino.co.jp/necessity より
PHPコード監査サービス「dinspection」の登場です
株式会社ディノは、PHPアプリケーション開発のプロフェッショナル集団です。株式会社ディノは、これまでの実績と技術的蓄積を生かし、第三者機関としてプログラムの品質を定額で監査するサービス「dinspection」をスタートいたしました。お客様からソースコードをお預かりし、オリジナルのチェックツールを併用しながら、技術者が「安全性」「保守性」「性能」「バグ」の4つの視点でソースコードの抜き取り監査を行います。

https://inspection.dino.co.jp/features より
1.業界トップクラスの技術者が監査
株式会社ディノはPHP ウェブアプリケーション開発に特化した技術会社です。大型案件を開発してきた実績と、スタッフのハイレベルな技術の蓄積が自慢です。
- 中略 -
4.テストではなく、コードを監査
要求通りに動くことを確かめるのにテストは向いていますが、セキュリティホールが無いことを確認するテストは容易ではありません。「dinspection」では、高い技術レベルの技術者がソースコードの監査を人手で行います。

きっと、それはそれは素晴らしく技術力の高い方々がなさっているものだと思いますの。思わずにはいられませんわ？きっとこれをお読みの皆様もそうお感じになられるはずよね？
だのに…いったいこれはどういうことかしら？

あたくしはそう思って。2006年09月08日の夕刻に、ご連絡を差し上げましたの。hiddenは如何なものなのかしら？って。
そうして…翌日。「サイトのHTMLからhiddenが削除され」「あたくしには連絡がない」という、素敵なダブルパンチを頂戴いたしましたの。
これってちょっとどうなのかしら…って思ってご連絡を差し上げたあたりから…素敵な返信が舞い込んできておりますわ。
あたくしが二通目を書いたのは2006年09月11日 18:42:22 頃ですの。そうしたら、いきなり2006年09月11日 20:20:11にお返事がもどってきましたの。
端的に書くと、要点はこんな感じかしら？

実際の攻撃可能性の調査後に行うつもりだった
予想以上に調査に時間がかかって、結果として連絡が遅れた(謝罪)
指摘は「ヘッダインジェクションの危険性があるのではないか」という内容だと認識した
ヘッダインジェクションの危険性に関しては「PHP5.1.2以降のPHP自体の仕様によるもの」のために、テストした範囲では攻撃は不可能であるように考えている
万全を期すためPHPのCソースコードを追っている

こんな感じかしら？
一見誠実なようでいて…かなりピントとか的とかをはずしまくってるのよね？

で、あたくしはこんな風にお返事を返しましたの。

とりあえず連絡は出来なかったのかしら？
「PHPのバージョン依存の仕様による」安全性を基準にお話をされているのって如何なものなのかしら？

これに関しては、こんな御丁寧なお返事を頂戴いたしましたわ。

マニュアルに明記されている実装によって「ヘッダインジェクション」が不可能なようになっていることを確認した

という趣旨かしら？

そうねぇ。あたくしも、必ずしも異論だらけ、ってわけじゃないの。でも、ちょっとこのあたりをご覧になってみていただきたいの。

http://jp2.php.net/manual/ja/function.header.php より
header() 関数は、HTML ファイルの送信に先立って、生の HTTP ヘッダ文字列を送信するために使用します。HTTP ヘッダの詳細は、 HTTP 1.1 Specification を参照してください。
注意: PHP 4.4.2 および PHP 5.1.2 以降、この関数は一度に複数のヘッダを送信できないようになりました。これは、ヘッダインジェクション攻撃への対策です。

この仕様に「拠る」セキュリティ対策をなさっていてそれがコレクトだと主張するその手法って、本当にそれは「万全なもの」なのかしら？
というかそも「なんでhiddenにモノ書かなきゃいけないのかしら？」＆「じゃぁなんであわててhiddenを出力しないように修正なさったのかしら？」
それとも「ヘッダインジェクション以外にも色々とこの脆弱性って使えたわよねぇ」って突っ込みを入れて差し上げたほうがよろしいのかしら？*3
そうしてこの先を考えると「本当にほかの部分は大丈夫なのかしら？」とか「サービスしているソースコードチェックの品質って如何なものなのかしら？」とか色々な延長線上のあんなこんなそんなな幻影が見え隠れしてしまいますわ？

ええきっと「業界トップクラスの技術者」ですもの、なにかきっと深謀遠慮があるんだと思って差し上げてもよろしくってよ、とっても好意的な見方をするとして。
でも、そんな深いところを考える前に、もうちょっと手前の浅瀬で、真摯に考えたほうがいいところがたっぷりとあるんじゃなくってかしら？

二片目のくず肉はこちら。
テクノブレーン株式会社 ( http://www.techno-brain.co.jp/ )っていう会社さんが運営なさっている、JYOTATSU ( http://jyotatsu.jp/ )っていうSNSがありますの。
「情報処理 SNS」「ITエンジニアのためのコミュニティ」っていううたい文句がとても素敵よね？
で。あたくしの知り合いが早速入会して *4 …びっくりしたらしいの。そのびっくりしたブツを、まずはご覧遊ばせ？

＜form action="./" method="post"＞
＜input type="hidden" name="m" value="pc"＞
＜input type="hidden" name="a" value="do_o_regist_prof"＞
＜input type="hidden" name="mode" value="register"＞
＜input type="hidden" name="sid" value="42c8040208e6d----------94f9f1e6f"＞
＜input type="hidden" name="nickname" value="はんどるめい"＞
＜input type="hidden" name="birth_year" value="生年(ちゃんと数字よ)"＞
＜input type="hidden" name="birth_month" value="生月(ちゃんと数字よ)"＞
＜input type="hidden" name="birth_day" value="生日(ちゃんと数字よ)"＞
＜input type="hidden" name="public_flag_birth_year" value="public"＞
＜input type="hidden" name="password" value="*****"＞
＜input type="hidden" name="password2" value="*****"＞
＜input type="hidden" name="c_password_query_id" value="1"＞
＜input type="hidden" name="c_password_query_answer" value="リマインダ使うな"＞
＜input type="hidden" name="profile[namae]" value=""＞＜input type="hidden" name="public_flag[namae]" value="public"＞＜input type="hidden" name="profile[shokugyo]" value="エンジニア"＞＜input type="hidden" name="public_flag[shokugyo]" value="public"＞＜input type="hidden" name="profile[shoyusikaku][]" value="128"＞＜input type="hidden" name="public_flag[shoyusikaku]" value="public"＞
＜td＞＜input type="submit" value="　登　録　"＞＜/td＞
＜/form＞

すごいわねぇ素敵だわねぇ。なんていうか…正気かしら？
ついでに。当然のごとく新規登録で登録した後にもう一度同一のメールアドレスを入力すると

そのアドレスは既に登録されています

ってかえってきたらしいわ？
これもまたベーシックなミスよねぇ。
で、管理人にメールしたらしいの。始めは

開発側の会社に知らせるから詳細を教えれくれ

って事で、詳細を知らせたらしいの。で…それはそれは素晴らしく感動的な返答がかえってきたらしいわ？

このSNSはオープンソースであるOpenPNEを使っている
アドレスの総当り攻撃に関しては「文言を変更する」「招待メール内に登録済みと書く」「メールアドレスに加えて歪んだ数字を手動で打たせる」が対応策候補として上がっているがどのように対応すればいいか悩ましい
パスワードについてはhiddenに書かないようにする
パスワード以外の項目については脆弱性と言うには疑問
セッションを使っているから安全、使っていないから危険、というのは議論の分かれるところ
サニタイズ周りに関しては問題ないはず

ですって。
なんていうか…すごいわねぇ。大体「開発側の会社」って話から「手直しすらもせずにそのままオープンソース使いっぱなし」ってどうなのかしら？
どうみても修正する気配もなければ必要性も感じてらっしゃらないみたいですし。
「エンジニアのキャリア形成について一緒に考え」てくれる「幸せなエンジニアの転職を実現させるため、あなたのキャリアを分析し」てくれる「企業様が必要とされる優秀な即戦力の人材をご紹介」してくれる「エンジニアスカウト会社のディファクトスタンダードを自負して」いるテクノブレーン株式会社様が運営なさっている「ITエンジニアのためのコミュニティ」だけのことはありましてよ？
よろしかったら、皆様も是非このSNSにご参加なさってみては如何かしら？きっと何かしら学べることも多いと思うわ？*5 *6

三片目のくず肉は…こんな素晴らしいお話を頂戴いたしましたの。
まず、ココログ ( http://www.cocolog-nifty.com/ ) てぇものがございますの。それはこんな風なものですわ。

http://www.cocolog-nifty.com/about/index.htm より
無料で楽しめる「ココログ」は
「安心・簡単・魅力的」な
ブログサービス！！

まぁなんとも陳腐でひねりの欠片もない、心笑われる素敵な売り文句ですわ？
運営会社さまは、かの有名なるNiftyさま ( http://www.nifty.com/ ) よ？
このウリ文句と運営会社さまの事を考えるだけで…なにか心が躍るようだわ。ところが、これに関して、ちょっと気になるお話が出ているらしいの。
ネタ元は水無月ばけら様の「水無月ばけらのえび日記 ( http://bakera.jp/hatomaru.aspx/ebi ) 」からですわ？

http://bakera.jp/hatomaru.aspx/ebi/topic/2148 より
「[connect24h:8297] Re: 銀行のサーバが攻撃されていました。 (www.st.ryukoku.ac.jp) ( http://www.st.ryukoku.ac.jp/%7Ekjm/security/ml-archive/connect24h/2005.01/msg00112.html )」を読んで知ったのですが、ココログをビジネスで使用している企業というのがあるそうですね。
ココログに関しては、所詮個人の趣味の blog だろうし、セキュリティに関しては多少のことは気にしなくて良いだろうという判断をしていました。しかしビジネスユースがあるとなると……。
※2005-02-23 追記: ココログの脆弱性として 2件ほど届け出ましたが、1件は修正、1件は脆弱性ではないとして取扱い終了となりました。ココログの SSI インジェクション ( http://bakera.jp/hatomaru.aspx/ebi/topic/2181 ) 参照。

…あらあらなにやら香ばしくもきな臭い香りがしてきますわ？大体「SSIインジェクション可能」ってどういうことかしら？

http://bakera.jp/hatomaru.aspx/ebi/topic/2181 より
ココログは SSI インジェクション可能
ココログにはビジネスユースもあるということで 2件の脆弱性を届け出ていたのですが、2件とも取扱い終了となりました。
そのうちの 1件は SSI インジェクションの事例なのですが、ウェブサイト運営者はこれを脆弱性ではないと主張したようで、修正されないまま取扱い終了となっています。exec cmd は使えないようですので、大きな問題は無いといえば無いのかもしれませんが……ちょっとひっかかる感じがしますね。
まあ、ウェブサイト運営者が脆弱性でないと言うからにはテストしても問題ないでしょうし、情報を公開しても問題ないでしょう。近いうちに、どのようにしてココログに SSI がインジェクションできるのか、それで何ができるのかをまとめて書こうかなと思っています。
※なお、もう 1件の方は確かに修正されていることを確認しました。今のところニフティからのアナウンスはないみたいですが……まあ、一生アナウンスされない可能性が高いですね。
※2005-03-12 追記: 「近いうちに」と書きましたが、しばらく情報の公開を見送ります。先送りの理由は述べられませんが、お察しください。
※2005-04-07 追記: ココログには任意のファイルが置けるようになりました。SSI を含む HTML をそのまんま置けますので、もはや技も何も必要なくなっています。

メインの本文もさることながら…追記が豪勢ですわね。特に4/7の追記に関しては何をかいわんや、といったところかしら？
それに関しては、その日のブログで詳しくお書きになられてますわ？

http://bakera.jp/hatomaru.aspx/ebi/topic/2247 より
ココログに任意ファイルを置けるように
ココログが大幅にバージョンアップしたようですね。詳細は「ココログバージョンアップ(2005/4/7)での主要変更箇所について (help.cocolog-nifty.com) 」で公開されていますが、正直凄いです。何が凄いって、任意のファイルが置けるようになったということです。
昔 (というほど昔でもありませんが) ココログに SSI をインジェクションする技というのがありましたが、こうなるともう技も何も必要ありません。SSI の記述を含む HTML ファイルを置けば、それだけで見事に動作します。#exec cmd は使えないようですので直接的な脅威は無いと思いますが、#include file や #echo var などは使えますので、いろいろ面白いことはできそうです。ただ、負荷の高い SSI を使いすぎるとココログのサーバがピンチかもしれませんが……。

素敵ですわねぇ。そういえば昔もNiftyの一角って黒々とした闇が広がっていた…なんて闇歴史、あたくしはとんと存じ上げませんわ？ええ本当よ？
まぁ、水無月ばけら様のところでほかにも色々と、黒々とした闇々とした鬱々とした事が色々かかれておりますの。

さて…本日のステーキメニューには全てに共通点があるのがお分かりになるかしら？
そうねぇ…ヒントとして、もう一つ二つ、こちらのURLを参考として載せてみるわ？
サイボウズが再び「闇改修」をしたので電話で抗議したが無駄骨だった ( http://takagi-hiromitsu.jp/diary/20060830.html#p01 )
サイボウズ「闇改修」の件のその後 ( http://takagi-hiromitsu.jp/diary/20060901.html#p01 )

人間はある程度ミスをしてしまう生き物ですの。だからこそ「ミスをした時点でNG」ってのは、よっぽど厳しい競争じゃないかぎり、まずありえないわ？*7
だからこそ、セキュリティホールとかそれに類するものを見つけたときに「どんな風に対応するか」ってのが、とても重要になるものなの。
実際、あたしが指摘して「速やかに直した」会社さんも数多くあるわ？あたくしは、そんな会社さんに一定の敬意を払うことはあっても、侮蔑的な感情を持つことなんてのはありえないことなの。
でも、今日ご紹介した方々はいったいどんな対応をなさっているのかしら？
あたくしは「口先だけの安全」とか「幻想の上に成り立つセキュリティ」とかにはとんと興味がございませんの。そんなもの「ルーシーが空の中でダイヤモンドと一緒に」戯れていればいいことですわ？

どこぞのニュースで言ってたわねぇ「フォルクスのようなまねはせず、ちゃんと明示した上で売って欲しい。それなりの品質は確保しているつもりなのだから」って。お肉をあつかってらっしゃる社長様が。
あなたはそのあたりのけじめがちゃんとつけられる、素敵な殿方になるのかしら？
それとも欲と虚飾と堕落にまみれた見るに耐えない下衆に成り下がるのかしら？

*1:あんた最近PHP多いみたいですしねぇ。…ほんっとＭよねぇ、あんた。

*2:どの業界で「どんな視点から」Topなのか銘記されてないあたりが最高よね？

*3:これだと「ヘッダインジェクションの話で濁そうとしてたのかしら？それともそれ以外考え付かないほどに無能に過ぎるのかしら？」っていうコンボが発生するのよねぇ。

*4:…それにしてもあんたも地雷踏むの好きよねぇ。

*5:反面教師って大切よねぇ

*6:そういえば。コミュニティの一つで「教える人のためのコミュニティ」ってのがあったらしくて。知り合いが「教えること"も"やってるから入りたい」って要請したら「教えていること"を"仕事にしてからきてください」って突っぱねられたらしいのよねぇ。色々と、教師って呼ばれてる連中の発想とかなんとかってのが垣間見えて面白い小ネタだったわ。

*7:あたしの獲得競争なら無論「ミスは厳禁」よ？それくらいは当然よね？

Lucrezia Borgia の Room Cantarella

■

韃靼とハンブルグと合成って似てるようで色々と違うものなのよね？

ちょっとしたスパイス、かしら？