「個人情報保護ガイドライン」を含む日記 RSS

はてなキーワード: 個人情報保護ガイドラインとは

2008-07-27

Webアプリ脆弱性オタがふつーのSE彼女脆弱性世界を軽く紹介(ry

まあ、どのくらいの数の脆弱性オタがそういう彼女をゲットできるかは別にして、

「オタではまったくないんだが、しか自分のオタ趣味を肯定的に黙認してくれて、

 その上で全く知らない脆弱性世界とはなんなのか、ちょっとだけ好奇心持ってる」

ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、Webアプリ脆弱性のことを紹介するために

説明するべき10パターンを選んでみたいのだけれど。

(要は「脱オタクファッションガイド」の正反対版だな。彼女脆弱性布教するのではなく

 相互のコミュニケーションの入口として)

あくまで「入口」なので、時間的に過大な負担を伴うような図解などは避けたい。

できれば、秋葉原とか筑波とかから突っ込みはいるような微妙な奴も避けたいのだけれど、つい選んでしまうかもしれない。

あと、いくら脆弱性的に基礎といっても古びを感じすぎるものは避けたい。

プログラム言語オタがCOBOLは外せないと言っても(いましたね)、それはちょっとさすがになあ、と思う。

そういう感じ。

彼女の設定は

セキュリティは専門でもなんでもないが、クロスサイトなんちゃらとか、SQLなんとかくらいは聞いたことがある。

ひろみちゅとか、はまちちゃんてなんだろうという好奇心もある

サブカル度も低いが、頭はけっこう良い

という条件で。

まずは俺的に。出した順番は実質的には意味がない。

XSS

まあ、なんで一番がSQLインジェクションじゃないんだよとも思うけれど、たいていのWebアプリに必ずあるという普遍性(日本語変か?)とか、文字コードネタバリエーションとか、DOMが絡んでわくわくするとか、Same Origin Polic何じゃそりゃという点では外せないんだよなあ。長さも3文字だし。

ただ、ここでオタトーク全開にしてしまうと、彼女との関係が崩れるかも。

この情報過多な脆弱性について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の情報彼女

伝えられるかということは、オタ側の「真のコミュニケーション能力」試験としてはいタスクだろうと思う。

MITM, DNS Rebinding

アレって典型的な「オタクが考える一般人に受け入れられそうな脆弱性(そうオタクが思い込んでいるだけ。実際は全然受け入れられない)」そのもの

という意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには

一番よさそうな素材なんじゃないのかな。

Webアプリ専門家からいえば、この二つはアプリネタじゃないと思うんだけど、率直に言ってどう?」って。

パストラバーサル

侵入先のファイルが見えてしまうというハッカー的なものへの憧憬と、これによる逮捕者がいるという法的な考証へのこだわりを

彼女に紹介するという意味はいいなと思うのと、それに加えていかにもマニアック

「よく眼にするけどあまり実害の思いつかない」/etc/passwd

「滅多に見られないけど、見つけたらゾクゾクする」/etc/shadow

の2ファイルをはじめてとして、オタ好きのするファイル世界に公開(流出?うわ、日本語間違いが怖い)しているのが、紹介してみたい理由。

CSRF

たぶん秋のDK収穫祭を見た彼女は「これCSRFだよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。

そして、われらがアイドルはまちちゃんの紹介のおかげで、この脆弱性日本で大人気になったこと、

ひろみちゅがはまちを焦がしたのは事故か、わざとか?

なんかを非オタ彼女と話してみたいかな、という妄想的願望。

メールヘッダインジェクション

「やっぱりWebアプリ脆弱性個人情報DBなんかがあるサイトものだよね」という話になったときに、そこで選ぶのは「SSIインジェクション」

でもいいのだけれど、そこでこっちを選んだのは、この脆弱性がふつーのホームページなどでも本当によく見つかるくせに、意外に問題視されていないレアっぽさが好きだから

断腸の思いでJavaMailのAPIがTo欄やFrom欄に改行チェックいれているのに、なぜかSubject欄だけチェックがされてなくて脆弱性の原因になるかもって中途半端さが、どうしても俺の心をつかんでしまうのは、

その「チェックする」ということへの躊躇がいかにもオタ的だなあと思えてしまから

ほかのメールAPIでもチェックが不十分なものはあるし、そもそもsendmail呼び出すときはチェックはアプリ側でやるしかないとは思うけれど、一方でこれが

Microsoftだったら意外にきっちりセキュアに仕上げてしまうだろうとも思う。

なのに、安全APIを使わずに(知らずに?)脆弱性を混入してしまうというあたり、どうしても

自分過去から知っている書き方でないと書けないプログラマ」としては、たとえ脆弱性混入した奴がそういうキャラでなかったとしても、

親近感を禁じ得ない。脆弱性の高危険度と合わせて、そんなことを彼女に話してみたい。

ディレクトリリスティング

今の若年層でディレクトリリスティングによる個人情報漏洩事件をリアルタイムで見聞きしている人はそんなにいないと思うのだけれど、だから紹介してみたい。

SQLインジェクションよりも前の段階で、個人情報漏洩規模とかはこの脆弱性で頂点に達していたとも言えて、

こういう危険の高さが経産省あたりの個人情報保護ガイドラインにのっていたり、というのは、

別に俺自身がなんらそこに貢献してなくとも、なんとなく脆弱性好きとしては不思議に誇らしいし、

いわゆるインジェクション系でしか脆弱性を知らない彼女には見せてあげたいなと思う。

OSコマンドインジェクション

UNIXシェルの「セミコロン」あるいは「バッククォート」をオタとして教えたい、というお節介焼きから見せる、ということではなくて。

ホワイトリストで対策すると安全なんだけど敢えてエスケープを究めたいマニア」的な感覚がオタには共通してあるのかなということを感じていて、

からこそ佐名木版『セキュアWebプログラミングTips集』は20ページ以上もかけてOSコマンドインジェクション対策の説明しているのは、エスケープ手法以外ではあり得なかったとも思う。

「侵入先のコンピュータコードが動いてこそなんぼ」というクラッカー感覚今日さらに強まっているとするなら、その「クラッカーの気分」の

源はOSコマンドインジェクションにあったんじゃないか、という、そんな理屈はかけらも口にせずに、

単純に楽しんでもらえるかどうかを見てみたい。

Hiddenフィールド改ざん

これは地雷だよなあ。昔だったら筑波方面、今だったら秋葉原方面から火のような「hiddenは危険脳」ブクマがつくか否か、そこのスリルを味わってみたいなあ。

こういう昔のIPA風味の解説をこういうかたちでブログ化して、それが非オタに受け入れられるか

突っ込みを誘発するか、というのを見てみたい。

SQLインジェクション

9本まではあっさり決まったんだけど10本目は空白でもいいかな、などと思いつつ、便宜的にSQLインジェクションを選んだ。

XSSから始まってSQLインジェクションで終わるのもそれなりに収まりはいいだろうし、カカクコム以降のWebアプリ脆弱性時代の原動力と

なった脆弱性でもあるし、紹介する価値はあるのだろうけど、もっと他にいい脆弱性パターンがありそうな気もする。

というわけで、俺のこういう意図にそって、もっといい10パターン目はこんなのどうよ、というのがあったら

教えてください。


「駄目だこの増田は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。

こういう試みそのものに関する意見も聞けたら嬉しい。


Inspired by アニオタが非オタの彼女にアニメ世界を軽く紹介するための10本

 
ログイン ユーザー登録
ようこそ ゲスト さん