Lucrezia Borgia の Room Cantarella

はぁい。はじめまして。ルクレツィア ボルジアのカンタレラ部屋へようこそ。
主人のルクレツィアです。
簡単に、この部屋の主旨を。
この部屋は、コンピュータ技術関係のお話をするところなの。っていうかあたしの雑感を書いてるってほうが正確かしら?
あたしの主観で書いてるから、内容には要注意よ。原典と自分の意見くらい、きちんと自分で処理してね。あたしが処理して上げられるのはがちむちイケメンの殿方の下半身くらいのものよ。
カンタレラ、ってのはとっても素敵なお薬のこと。興味があったらGoogleにでもいって調べてみて頂戴。か弱い女に頼りっぱなしじゃだめよ。
名前のとおり、この部屋に書く内容にはたっぷり毒をまぶす予定だわ。即効性も遅効性も含めて。あま〜〜い、毒をね。

最近の見出し

2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 05 | 06 | 07 | 08 | 09 | 10 | 11 |
2007 | 05 |
2008 | 01 | 11 |
<< 2006/09 >>
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
プロフィール

Lucrezia

あら? あたしの事をそんなに知りたいのかしら?

 | 

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>

すごいわねぇ素敵だわねぇ。なんていうか…正気かしら?

ついでに。当然のごとく新規登録で登録した後にもう一度同一のメールアドレスを入力すると

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

ってかえってきたらしいわ?

これもまたベーシックなミスよねぇ。

で、管理人メールしたらしいの。始めは

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

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


ですって。

なんていうか…すごいわねぇ。大体「開発側の会社」って話から「手直しすらもせずにそのままオープンソース使いっぱなし」ってどうなのかしら?

どうみても修正する気配もなければ必要性も感じてらっしゃらないみたいですし。

エンジニアキャリア形成について一緒に考え」てくれる「幸せエンジニア転職を実現させるため、あなたのキャリアを分析し」てくれる「企業様が必要とされる優秀な即戦力の人材をご紹介」してくれる「エンジニアスカウト会社のディファクトスタンダードを自負して」いるテクノブレーン株式会社様が運営なさっている「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

だからこそ、セキュリティホールとかそれに類するものを見つけたときに「どんな風に対応するか」ってのが、とても重要になるものなの。

実際、あたしが指摘して「速やかに直した」会社さんも数多くあるわ? あたくしは、そんな会社さんに一定の敬意を払うことはあっても、侮蔑的な感情を持つことなんてのはありえないことなの。

でも、今日ご紹介した方々はいったいどんな対応をなさっているのかしら?

あたくしは「口先だけの安全」とか「幻想の上に成り立つセキュリティ」とかにはとんと興味がございませんの。そんなもの「ルーシーが空の中でダイヤモンドと一緒に」戯れていればいいことですわ?


どこぞのニュースで言ってたわねぇ「フォルクスのようなまねはせず、ちゃんと明示した上で売って欲しい。それなりの品質は確保しているつもりなのだから」って。お肉をあつかってらっしゃる社長様が。

あなたはそのあたりのけじめがちゃんとつけられる、素敵な殿方になるのかしら?

それとも欲と虚飾と堕落にまみれた見るに耐えない下衆に成り下がるのかしら?

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

ちょっと追記よ。

上に書いたOpenPNEって、株式会社手嶋屋 ( http://www.tejimaya.com/ ) って会社さんがおつくりになってらっしゃるらしいの。

実績 ( http://www.tejimaya.com/clients.html ) のPageを拝見しても

http://www.tejimaya.com/clients.html より

OpenPNE

内容:オープンソース開発SNS

OpenPNE】は手嶋屋がオープンソース方式で

開発を行っているオリジナルSNSです。

って書いてあるから事実なんだと思うわ?

で…こちらをご覧になってみていただきたいの。

http://d.hatena.ne.jp/openpne/20060913/1158168592 より

http://trac.openpne.jp/wiki/%E8%A8%AD%E8%A8%88%E3%83%BB%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%AB

なわけでっす〜www

OpenPNEを開発する際の基本理念として、

「エンドユーザが最も喜ぶように」

というのがあるので、技術的な先進性はプライオリティが下がってしまうというわけでっす〜www

ただ技術的に遅れていくと、

「エンドユーザが最も喜ぶ」

ものが作れなくなっちゃいそうなのでバランスとって追いかけていきまっす〜www

「エンドユーザが最も喜ぶ」

って良いよね。

どすか?

えらいわぁ。「常にユーザの事を考える」事って、なかなかそうは出来ないことですもの。

つい「先進性のある技術」にのみ目がいってしまって「ユーザを軽視する」技術者の集団にあって、なかなかいえることじゃぁないわね。

せっかくですから。上述のURLにも伺ってみましょ?

http://trac.openpne.jp/wiki/%E8%A8%AD%E8%A8%88%E3%83%BB%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%AB より

設計ルール

新規・高度なプログラミング手法は極力利用しない

えらいわぁ。ここでもちゃんとこのあたりの理念を間違えずに踏んでいてよ?

http://trac.openpne.jp/wiki/%E8%A8%AD%E8%A8%88%E3%83%BB%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%AB より

オブジェクト指向は、

* PHP4 PHP5間での違いが激しすぎる

* PHP5でのオブジェクト指向中途半端

* コミッター全員が使いこなせない

* PHP用のエディタでうまく管理出来るものが見つからなかった

という理由で極力利用していません。

あらあらまぁまぁあらまぁまぁ………そうなのねぇ「オブジェクト指向って新規で高度なプログラミング手法」なのねぇおねぇさん知らなかったわぁ。

でも。確かにPHP4とPHP5では差異が結構ありますし、PHP5ですら、中途半端なのは事実ですわ?*8

コミッター全員*9が使いこなせないってのも問題でしょうし、よいエディタが見つからないってのもやっぱり重要ポイントだと思いますの*10

http://trac.openpne.jp/wiki/%E8%A8%AD%E8%A8%88%E3%83%BB%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%AB より

現状のプログラムレベルでは

* 命名規則を徹底すれば何とかなる

* コミッターががんばってたくさんコードを読む

* プログラムの習熟度がある程度低くても、とりあえずコードが書ける

* オブジェクト指向ではある程度の、モデル化が必要だが 変化の激しいSNSモデル化は、現時点で出来そうもない

これも素敵だわぁ。

あたくしの不慣れなスキルでは「命名規則を徹底したら何が何とかなるのか」が全然わからないですし*11。まぁ「沢山のソースコード」を読むことが不必要だとは思わないんですけれども…それも読み方次第よねぇ? としか思えないわ。

「習熟度の低い」人間が「とりあえず書いたコード」なんて、あたしなら真っ平ゴメンなんですけれども…きっと何か色々と手法をお持ちでいらっしゃるのね?

変化が激しいために「OOに不向き」とか「モデル化が出来ない」ってのは…あたしが実践し、耳にしているオブジェクト指向とは、もしかしたら随分とかけ離れているものなのかもしれないわ?


理念がしっかりしていることっていうのは、とても素晴らしいことだと思いますの。オールドスタイルや周囲の平均を基準に考えることも悪いとは申しませんわ?

でも。結局のところこれって「エンドユーザの名の下に自分たちが努力を怠る理由をこねくり回している」ようにしか見えないのは気のせいかしら? 或いは「手を動かす努力はしても進歩する努力はしない」主義なのかしら?

「長くていいから、変数をしっかり書く」とか「全コードをもう一度書き直すモチベーションを維持する 」ってあたりにも、なんか色々と青いものが見え隠れしてしまいましてよ?

そうねぇ…どうかしら? いっそ、水色をベースに、襟をネイビーブルーにしたシャツでも制服としてお召しになってみては如何かしら?

きっと色々な意味でお似合いになるんじゃなくってかしら?


あたしは、もうちょっと知的な白か、いっそ恥的な赤いお召し物のほうが好きではあるんですけれども。


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

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

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

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

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

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

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

*8:どの変がどんな風に中途半端なのかなんて全然想像が付かないんですけれども。あたくしの知り合いは「C言語」でOOPが出来ましてよ?

*9:それって、前述を見ている限りですと少なくともメインは手嶋屋の面々なのよねぇ?

*10viでも開発なんてできるでしょうし、大体IDEがないと…って連中はIDEがあったってやっぱりロクなコード書かないのよねぇ。そうねぇ…よいIDEが見つかったとして「次は何を言い訳にするのかしら?」

*11名前空間関連のお話でもしたいのかしら?

なまええなまええ 2006/09/15 02:02 hidden はべつに脆弱性じゃないですよ。

LucreziaLucrezia 2006/09/15 11:16 To なまええ。当たり前よ? hidden「そのもの」はただの「INPUTエレメントのtypeアトリビュートの値」よ? 何を勘違いしているのかしら?
大切なのは「hiddenにおくべきデータとおいてはいけないデータがある」事なの。お分かりかしら?
その程度のことすらわからないんなら、もうちょっと、セキュリティの初歩の初歩からお勉強しなおしてらっしゃい。

寧 2006/09/15 15:58 カカクメソッド業界のトップクラス・・・?

なまええなまええ 2006/09/15 22:17 で、何を置くと問題で、
何は置いても大丈夫なの?

ほげほげ 2006/09/16 00:05 何度考えても分からないんですが、
「ヘッダインジェクション以外にも色々とこの脆弱性って使えたわよねぇ」
の答えって何でしょう。何か見落としてるのかな。

なまええなまええ 2006/09/16 04:30 <input type=”hidden” name=”referer” id=”referer” value=”https://inspection.dino.co.jp/” />
のいったい何が問題ですか?(「<」と「>」が全角だから?」
header() との関係も全然ないようですが?

LucreziaLucrezia 2006/09/16 11:10
To 寧。まぁそれなら意味がつながるわねぇ。…自分で言ってて震えが止まらないほどに怖すぎるんですけれども。
To なまええ。そうねぇ…いいからお失せなさいな?
無知で無考察な上に人に話を聞く態度も出来ちゃないようなケツの青いガキに付き合うつもりなんてさらっさらなくってよ?
To ほげ。そうねぇ…ダイレクトに書くのは憚れるので、万が一露見しても「比較的まだ甘めな」ところをひとつだけ。
当のサイト様「以外」の方が、ある特定の意図とパラメタを以って以下略。
日本には「チラリズム萌え」の文化もあるところですし。これくらいで少し想像つけてみてもらえないかしら?

寧 2006/09/16 15:24 むしろ恐ろしいのは、この会社自体のセキュリティが怪しいこと自体というより、この会社に何か頼んだ会社が出ることじゃないかしら。
脆弱性を探す会社ってことは、見つけた脆弱性の宝庫ってことだし、たとえ修正されたとしても色々と仕様の宝庫、ってことになるわよね。

チラリズムなんてかわいいものならいいけど、この会社を中心にヌーディスト村にならないかが心配かも。

ほげほげ 2006/09/17 01:13 ども。返事ありがとうございます。
「ダイレクトに書くのは憚れる」
ということですが、件のhiddenタグはもう消されてるんですよね?
だったら脆弱性の詳細を書いても何の問題も無いんじゃないでしょうか?

LucreziaLucrezia 2006/09/18 19:37 ちょっと順番が前後することを先にお断りしておくわ。
To ほげ。あたくしからの回答は概ね2つだわね。ひとつは「そういった脆弱性が、設計次第では発生しうる」というお話し。もうひとつは寧さんがお書きになっているから省略するわ?
To 寧。まず一番初めに。ごめんなさい。直接あなたのコメントは問題ないんですけれども、問題人の発言の削除に伴って、ひとつだけコメントを削除させていただくわ。
で…ヌーディスト村ねぇ…怖いわ。あえてコメントを付け加えるなら「そもそもちゃんと服着てるようなサイトがいったいどれくらいあるのかしら?」っていう、よりお寒い現実くらいかしらね?

ほげほげ 2006/09/18 20:31 え?
「そういった脆弱性が、設計次第では発生しうる」
というのは、すなわち可能性の話であって、脆弱性を見つけたわけじゃない、ってことですか?
寧さんの過去のコメントも見てみたんですが、仮定とか推測以外見付けられてないんですが…。

てっきり、件の会社のwebサイトに脆弱性を見つけたのに
指摘をしたら頓珍漢な返事をされた、って話なのかと思ってたもので。
そもそもそういう話ではないのでしたらあまり興味はないです。
色々お返事いただきましてありがとうございました。

LucreziaLucrezia 2006/09/19 12:35 To ほげ。そうねぇ…一つだけ答えておくわ。「もし」hiddenが脆弱性で無いとしたら。彼らはなぜそれを消したのかしら?
或いは。「hiddenを消した」という行為から透けて見れる「彼らが抱いたhiddenに対する問題性」ってどの辺りにあるのかしら?

寧 2006/09/19 19:20 >仮定と推測以外
Lucreziaさんみたいな方にしろ、悪質なクラッカーにしろ、セキュリティの穴を見つけるにはまずは仮定から入ることが多いと思います。hiddenにどんな情報があるか見るだけなら相手サイトに感づかれることなくチェックできますし。
で、そこに「脆弱性かもしれない」ものがあったとして、じゃあ本当に脆弱性なのか、と個人が試してみるわけにはいかないでしょう?どんな大義名分をつけようと、そんなことやっちゃったら立派な不正アクセスになっちゃうんだから。
で、ある以上、脆弱性のあるサイトにありがちな兆候が見られたらつっこんでみる、というのが一般人のとれる唯一の確認方法だと思うのだけれども。

あと、hiddenにrefererなんて名前でURLいれてたら、使い道はだいたい想像つくしね。(しかもその「使い道」が宜しくないことに使われる可能性はおしなべて高いし。)

通りすがり通りすがり 2006/09/19 22:22 hiddenにrefererはログ用ではないですか?
「だいたい想像つく」というのはrefererが正しいかチェックすることでしょうか。
そうだとして、脆弱性が思いつきません。CSRFではないですし。

LucreziaLucrezia 2006/09/19 23:21 To 通りすがり。たしか以前にも拝見したHNだわねぇ。同一人物かどうかもう一つ断定しにくいHNではあるんですけれども(笑
で。「hiddenにrefererはログ用ではないですか?」については…どういう挙動を想定しているのかしら? ちょっと想像しにくいわ?
あたしが予想したのは、本文の通り。ちなみに、修正されたから書いちゃうんですけれども、実際の挙動は「ログインで失敗した際の遷移先」だったわ。refererのvalueを書き換えた状態で実験したらちゃんとその通りに -検閲削除-。
で、hidden周りに「なんで書いちゃいけないのか」は、親切なことに、寧さんが丁寧に噛み砕いてくださっているわ?
もう一度、じっくりと丁寧に読んでみて頂戴。

別の通りすがり別の通りすがり 2006/09/20 10:40 私も被害が生じるような脆弱性が思いつきませんでした。「個人が試すわけにいかない」かつ「立派な不正アクセスになる」脆弱性ということは、直接的な攻撃方法がある(あくまで可能性として)ということでしょうか。

なまええなまええ 2006/09/20 11:23 どう見ても 寧=Lucrezia です。ありがとうございました。

LucreziaLucrezia 2006/09/20 12:45 To 別の通りすがり。直接的な攻撃方法がある可能性、についてはYesだわ。或いは。少なくとも「不要なデータを外側で操作可能な状態にしておく(hiddenの事よ?)」事がNGであるっていうのは、そんなに熟考しなくてもわかると思うんですけれども、そのあたりどうかしら?
To なまええ。あんまりにも愉快に過ぎるから、この戯言だけは削除せずにおいといてさしあげてもよろしくってよ?
文章書きなら、あたしと寧さんとで、微妙な、だけど結構決定的な「文章上の癖の違い」がわかると思うんですけれども。
まぁあんたみたいな、自分が認識できないものを「べつにたいした問題じゃないのでは?」とか「そのときはどうせ駄目でしょ?」とか、色眼鏡でしかモノを見れない人間には何を言っても無駄なんですけれどもね。
大体台詞は想像が付くわ。「同一人物だからわざとその辺の癖を変えているんだろう」ってあたりね。…陳腐だわぁ。

別の通りすがり別の通りすがり 2006/09/20 13:59 直接攻撃が前提なのであれば、登場人物は攻撃者のブラウザとWebサーバの2つしかないように思います。攻撃者のブラウザが攻撃者が変更したとおりのURL(hidden値)にジャンプするのが問題だということでしょうか?それとも、サーバに何か害を与えられるのでしょうか?

ほげほげ 2006/09/21 00:48 また来てしまいました。すみません。
「少なくとも「不要なデータを外側で操作可能な状態にしておく(hiddenの事よ?)」事がNGであるっていうのは、そんなに熟考しなくてもわかると思うんですけれども、そのあたりどうかしら?」ってことですけど、この発言、
「大切なのは「hiddenにおくべきデータとおいてはいけないデータがある」事なの。お分かりかしら?」
と矛盾してません?
「外側で操作可能」でないhiddenなんて原理的に有り得ないはずなので。

dinodino 2006/09/21 09:48 誰ですか、勝手に僕もHNを使うのは・・・orz
リアルでもセキュリティ関係(得意分野は暗号関係(学生の研究テーマからの付き合い)ですが、仕事はもっぱらマネジメント系が多いです)やってますが無関係でございます。

LucreziaLucrezia 2006/09/21 13:15 To 別の通りすがり。
わかりやすくて素敵な論旨の整理だわね。あたしの見解としてはあなたと概ね同一だわ? あとは…そうねぇ。あたしは「直接攻撃のみを前提にした」事は一度もなくってよ?
To ほげ。
いいえ。きちんとしたお話が出来るならいつでも歓迎よ?
それで。矛盾については概ねその通りよ。本質的には「1bitたりとてデータなんてhidden(Cookieとかも含めるわ)におきたくない」ものですの。だって危ないでしょ?
でもそれをいったらそもそも「紙芝居なHTTPでセッションなんて概念を持ち出している時点でNG」なんですの。あんなプツプツきれる通信でセッションの完全性なんて、おへそでロイヤルミルクティを沸かせてしまってよ?
それでも。もう一方の現実として「クライアントからの要求」という鉄の事実が存在してしまっているの。
だからこそ。あたしは、最低限の情報だけをhidden(もしくはCookie)に書き、それでもなおその情報は「操作されている可能性がある」事を前提に、とても慎重に扱うべきだ、って言うの。
矛盾を「矛盾するから実装しない」っていうのは一つの方法よ? でもそこで「この盾以外なら貫ける矛とこの矛以外では貫けない盾」っていう落としどころを探してみるのもまた一つなんじゃなくってかしら?
To dion。
うふ。あたしもちょっと「あれ?」とは思ってたのよねぇ。

dinodino 2006/09/21 17:08 でも、最近dinoって結構人気のある名前なのかな?って思います。
まぁ、僕は某ネットゲー(Lucrezia様はご存知でしょうが)でこのHNでプレイしていて、気に入っているからはてなでこのHNとったのですが、フリーのメアドとかそのほか(たとえばSNSとか)でもHNでは結構このHNはすでに取られていました。

このはてなでも、最初の文字が大文字のDinoさんという方もおりますね。もちろんまったくの別人およびつながりもないです。

ほげほげ 2006/09/22 00:34 ご説明ありがとうございます。
いままでの話を要約すると、
「件の会社は、本来不要と思われる情報をhiddenに入れるのはかっこ悪い」
ということでいいですか?

ところで、「あとは…そうねぇ。あたしは「直接攻撃のみを前提にした」事は一度もなくってよ?」と書かれていますが、
私も直接攻撃のみを前提としていると理解していました。
その理由は、(2006/09/20 12:45)にて、あなたが想定している「脆弱性」は「不正アクセス禁止法に違反する可能性があるから試せない」と認めているからです。
サーバーへの直接攻撃以外で、試しただけで不正アクセス禁止法に違反する可能性のある攻撃は存在しないことは御存知ですよね。

LucreziaLucrezia 2006/09/22 11:04 To ほげ。
> 「件の会社は、本来不要と思われる情報をhiddenに入れるのはかっこ悪い」
については。「かっこ悪い」の中身が「危険だからダメ」なのか「問題があるわけではないけど見た目がよろしくない」のか、ニュアンスが取れないからどちらとも言えなくてよ?
もう一つの件については。「想定している脆弱性」についてはその通りよ? これが「(特に法的観点から)正しい」かは不明ですけれども。あたしも、「サーバに影響が出なければ」不正アクセス禁止法に違反する可能性のある攻撃はとりあえず現時点においては「ないだろう」と考えておりますの。
で…それが「直接攻撃のみを前提としていると理解」につながるあたりがちょっと短絡的に過ぎてよ?
そうねぇ…ヒントだけ。「”想定している”脆弱性」についてはその通りよ?
コレでわかんなきゃ、適当に自分ひとりで処理して頂戴。

別の通りすがり別の通りすがり 2006/09/22 13:07 hiddenにできるだけデータを置きたくない、というのは正しい内容だと思いますし、いい文章だと思います。ただ、脆弱性のあるなしにかかわらずhiddenに不要な値を置いてはならない、という主張は成り立ちません。「hiddenに関する脆弱性発見→hiddenに値を入れなければ問題は起きないよね」が進めたい議論の方向なのではないのですか?結論を一言で言い切っているのに比べると、前提となる脆弱性についての歯切れの悪さが余計に目立って感じられます。仮定が曖昧であればそこから導かれる結論はありません。結論が合っているからといって仮定をないがしろにしていいわけもありません。

あなたが尊敬する高木先生もその点を外した議論をすることは無いと思いますが、いかがでしょうか。

ほげほげ 2006/09/23 02:50 うーん、
「そうねぇ…ヒントだけ。「”想定している”脆弱性」についてはその通りよ?」
この「その通り」というのは、Lucrezia氏が、想定している脆弱性は、サーバーへの直接攻撃に対する脆弱性である、ということで間違いないですか?
なので、不正アクセス禁止法にひっかかる恐れがあるので、脆弱性を確認することができなかったと。

あと、「かっこ悪い」の意味ですが、もちろん後者の意味で使いました。けど、いただいた回答から察するに前者の意味だということですね。

ほげほげ 2006/09/23 02:56 あ、昔いただいたコメントで、返事してなかったのがあったので、一応書いておきますね。

「「もし」hiddenが脆弱性で無いとしたら。彼らはなぜそれを消したのかしら?
或いは。「hiddenを消した」という行為から透けて見れる「彼らが抱いたhiddenに対する問題性」ってどの辺りにあるのかしら?」

これについて、件のhiddenタグを中の人が消した理由が「脆弱性がみつかったから」とは限らないと思ってます。
ふつーの人だったら、脆弱性があると指摘されれば、とりあえず消してから本当に脆弱性があるかどうか調査するでしょう。
で、調査の結果みつからなかったけど、もうhiddenの無い状態で稼働するように修正してしまったら、わざわざhiddenのある状態に戻したりしませんよね。

ですので「hiddenを勝手に消した→脆弱性があった」という論理展開はものすごく無理があると思っています。

LucreziaLucrezia 2006/09/24 01:15 先に言っておくわ。このコメントって場で議論するつもりは基本的にないの。きちんと議論して突き詰めたければ、最低限、自分でBlogなりなんなり立ち上げてそこで展開して頂戴。その上でトラックバックされての議論なら、相当なところまでお付き合いいたしますわ?
まぁせっかく頂戴しているお話しですしこれも縁かしら…と思ってしばらくやり取りしてみたんですけれども。…そのあたりの礼儀を弁えている殿方もいらっしゃらないみたいですしねぇ。軽く幻滅だわ?
いつまでか弱い女の軒下に居座るおつもりかしら? ある程度「意見の相違」があってそれに対して質問なり自論展開をするなりするのであれば。自分の軒下を作って招待する、くらいのことをやってもバチはあたらなくてよ?

次。あたしは別に研究を生業にしているわけじゃないの。だから「きちんとした証明をすること」を、必ずしも必須にしているわけじゃないの。…って書くと騒ぐガキがいるのが目に浮かぶわねぇ。ま、好きにわめいていて頂戴?
言葉の真意とかその根っこにある意味とかを理解できないようなガキと会話するつもりも理解を求めるつもりもありませんし。

次。そうねぇ…hiddenに余計なデータを入れたときに。状況として発生する可能性があるのは「問題がない」か「セキュリティホールがある若しくは後日見つかる」だわ。hiddenに余計なデータがなければ「問題がない」だけよ?
「脆弱性の可能性があり(hiddenに不要データを書く)、それを回避する簡単な方法がある(書かない)」。
どちらを選択すべきかなんて、自明の理よね? そんな簡単なことをまず指摘しなきゃいけないのかしら? それとも「証明できないから大丈夫かもしれないから危険かもしれないけどメリットもないけどとりあえず選択する」のかしら? …愚の骨頂だわねぇ。

後は個別に。

To 別の通りすがり
> 前提となる脆弱性についての歯切れの悪さが余計に目立って感じられます。
以前に言ったとおり。詳細について語るつもりはないわ。
To ほげ。
「”想定している”脆弱性」についてはその通りよ?」
…仕方がないわねぇ。もう一度だけ、もうちょっとだけ、噛み砕いて差し上げてもよろしくってよ?
「”想定している”脆弱性」っていうのは「サーバへの直接攻撃の可能性があるから法的な観点から試せなかった(って事にしておいてね)」脆弱性、のことよ?
つまり、試せなかったから「想定している」の。
一方で。「CGIを通してクライアントPCに対して攻撃できる」類の脆弱性は、少なくとも対象を「自分のマシン」にすれば、別に不正アクセス…である可能性は否定できないんですけれども、少なくとも「訴えられるリスク」は限りなく0よね?
あと「hiddenを消した理由」については。素敵に甘くてバニラな見解ありがとうだわ。その辺は…見ている汚いものの量と質の差かしら?
「とりあえず消してみてなんとなくどっちでもいいっぽいから消したまま」と「言われて気づいてあわてて消した」と、どちらが無理のある理論展開かは…議論するつもりもないわねぇ。
それとも「とりあえず消せるようなものをHTMLにおいてある」「セキュリティをソースコードレベルでチェックする会社」の存在意義でも、改めて問うたほうがよろしいのかしら?

ほげほげ 2006/09/24 02:05 ども。丁寧なごせつめい ありがとうございます。
だいたいお立場は分かりました。そういう前提であれば、お書きになっている内容については理解できます。
ただ、そのお立場の場合、脆弱性ではないかも知れないものを差した上で、

> それとも「ヘッダインジェクション以外にも色々とこの脆弱性って使えたわよねぇ」って突っ込みを入れて差し上げたほうがよろしいのかしら?

と、脆弱性があることを断定する記述をするのは事実として誤りですよね。
そのようなお立場なら、上記のようなことを書かなくても、まさに、

> それとも「とりあえず消せるようなものをHTMLにおいてある」「セキュリティをソースコードレベルでチェックする会社」の存在意義でも、改めて問うたほうがよろしいのかしら?

こういう方向で件の会社を非難された方がよろしいのでは?

あと、不正アクセス禁止法の件ですけど、対象を自分のマシンにした時点で、訴えられるリスクもなにも、当該法の構成要件は満たされない(攻撃対象の許可がある場合の除外規定がある)ので大丈夫ですよ。安心してお試しくださいませ:-)

ではでは。あまり歓迎されてないみたいなので退散します。

別の通りすがり別の通りすがり 2006/09/24 03:45 考えられる脆弱性について具体的な想像・指摘をする必要性を感じないけれども、hiddenに書くのと書かないのとどちらが好ましいかという議論をしたかった、ということですかね。そういう立場もありうるとは思います。

そういう立場だとすれば日記本文の論調と違うと感じていたので反応していたのですが、基本的には納得です。

お付き合い頂きありがとうございました。万一次があればhatenaアカウントでも取ろうと思います。

   2007/02/24 13:12 尊敬する高木先生からは「ニセ脆弱性」「hiddenは危険脳」扱いですね
http://b.hatena.ne.jp/HiromitsuTakagi/?url=http%3A%2F%2Fd.hatena.ne.jp%2Fsumii%2F

? 2007/04/01 00:10 ひさしぶりにどうなったか見てみたら、高木先生から「ニセ脆弱性」「hiddenは危険脳」判定されてたんですね。
まあ、ここまでのやりとりを見れば、どちらが劣勢なのかは自明でしたが:-)

 | 

楽しんでいただけたかしら?
いつか、あたしの事も楽しませてね

そうそう。最後に一つ。このPage、どうもIEで見るとインデントがおかしくなるみたいなのよねぇ。でも、あたしはOperaとFirefoxの人間ですし、そもこのテンプレートもはてなさんが用意してくださってるものなの。
インデントが汚いってかたは、ぜひあなたのその「汚いブラウザ」を乗り換えなさい。そうすれば見易くなってよ?